Transcript
Thank you for being here.
We're going to talk about leading a self-organizing team, trying to dispel the myth that project managers, scrum masters,
and such with self organizing teams do nothing more than buy pizza and get out of the way.
There's definitely more to do on a Self-Organizing Team.
My name is Mike Cohn.
Hope to get a chance to talking with you more through the rest of NDC.
Here's our agenda, we're gonna talk about self-organization and something called subtle control.
We're going to talk something about called containers, differences, and exchanges, how those can be used to influence self organization.
And then we'll talk influencing how the team evolves.
Teams are not static things that stay in one place, they evolve.
So we will talk how to how influence that evolution.
Let's start out with what self organisation is.
In my mind, self organisation is a response to a challenge.
Someone external to the team throws a challenge out to them and they respond to that challenge.
Self-organization does not mean that the teams get to pick that.
They don't choose the goal they're going to pursue.
The team is given that goal.
A question posed to a list of scrum trainers a little bit ago that kind of bothered me because most of the scrumm trainers got it wrong.
The question was, does a product owner have the right to tell a team what the product needs and when?
And over half the scrum trainers who responded said no.
The product owner, that chief stakeholder, gets to tell the team one of the three things, what I want, when I wanted, how much it's going to cost,
something like that.
They don't get to specify multiple things.
So a product owners does not get say, I need this, by that date.
And that answer was wrong.
A product on a Scrum team or a key stakeholder on an Agile project does get the tell team more than that, I don't have any doubt about this.
I know this, because one of the very first Scrum projects ever was a project done at Fuji Xerox in the early 80s.
And this project, the product owner on the project went to the team and said, I need a new photocopier.
Fuji made photocoopiers.
Said, i need to new photo copier that works at today's state of art, sells for half the price of current model, and is available in two years.
And the article on this describes the team as kind of grumbling and moaning about this, saying, can't be done.
No way, no way.
And then eventually, they said, what if we tried this?
What if did this.
Yeah, yeah, if you did that, that would work.
We've used this new toner that's coming out.
Oh no, now that won't work, OK, but what we did with this And article talks about it and says, at that point, the product owner essentially had won.
The team had come to own the problem.
So self-organization is a response to a problem, right?
We self-organized already today.
You guys have already self organized at least once.
One thing you did is you self organizing into this room.
Our host here at NDC set up a challenge for you, where to sit.
And we had to self organize.
They could have done it differently.
It would have been nice if they'd given us kind of round tables, but then they can't fit as many people in here.
But that would've been a different self organization challenge.
The gave us a little bit of a weird challenge that they've got these nice seats in the middle but no screen.
So we have to optimize on whether you wanted to look at me or whether you want to look at the slides.
So we had a self-organization problem.
Not much of a problem, but we did have one this morning.
Self-Organization, a response to a challenge.
Managers, product owners, scrum masters, leaders in the organization help influence, determine what that challenge is going to be.
Now when we think about a team, teams are absolutely what are called a complex adaptive system, or CAS, a Complex Adaptive System.
And if we look at a definition for a Complex Adaptative System, it's a dynamic network of many agents.
acting in parallel and acting and reacting to each other.
Hopefully, that sounds like a typical team.
If we think about a seven-person team, it's a dynamic network of agents.
They're acting, reacting, to one another.
On a complex adaptive system, control is dispersed and decentralized.
We don't have all decisions being made by the one big brain.
All right, that type of decision making is dispersed.
So when we look at some examples of complex adaptive systems, we'd see some of these.
We'd things like ant hives and bee colonies.
Actually, I got those the other way around.
Ant colonies and beehives.
Right, would look those.
I think of Complex Adaptive Systems, something like a group queuing up to go into a concert or a theater.
Remember I was at a Jimmy Buffett concert last year.
Some of you probably know Jimmy Buffett, Margaritaville Singer.
And there were two distinct clumps of people.
There were some of us who were lined up to get in to good seats.
It was all open seating.
So some us were line up in good seating, the others were aligned up at the tequila bar.
Complex adaptive system, right?
And it was just kind of a structuring of ourselves.
No organization to it other than what you preferred.
Teams are definitely complex adaptive systems, especially agile teams, where we have very little high-level leadership.
The team is given a challenge.
They don't have a hierarchy of leaders.
Now, when we a project like this, one of the things I want to think about is that control, exerting control or influence over such a group is not evil.
Right?
Control is not evil.
Our hosts at NDC today, I do not think they were evil by putting the chairs in here this way.
They thought about how many people they had signed up, they thought the room, the best way, and they structured the tables in the chair in best combination
of ways.
If only 18 people signed up for NDC, we might have had big comfy recliners and tables, round tables.
But they look at it and they did their best to influence us in a good way.
So exerting influence or control over a group is not an evil thing.
When I get on the highway and drive, I have to stay on a particular side of the road.
I don't find that evil.
I find it somewhat helpful for keeping alive.
So control is not bad.
We often kind of rebel against it, and we think it is, but it's not.
It's okay to have rules and incentives added by managers, leaders, product owners.
project managers, whatever you want to think about.
It's okay for these individuals to add influence onto us in the rules or such that they place.
We do have to be careful as leaders in an organization that we don't go too far.
Now, sometimes I feel a little bit alone in this thinking, so I want to share a couple of thoughts to show that I'm not alone with this thing.
This is a great book called The Biology of Business.
It's a collection of essays, one of the essays by a guy named Philip Anderson.
Here's what he had to say.
He said, self-organization does not mean that workers, instead of managers, engineer an organization design.
it does NOT mean letting people do whatever they want do.
Says instead it means that management commits to guiding the evolution of behaviors.
Think about that, evolution behaviors that emerges from interaction of independent agents instead of specifying in advance what effective behavior is.
So management here somewhat leaves the team to figure out what affective behavior.
They set up the goals and they leave the teams to find out the best way to achieve those goals.
Let me look at one other quote, actually two other quotes here.
This next one I want to share with you is from the very first article on Scrum.
First article in Scum, one of the leading Agile processes, about 70% of people doing Agiles do Sc rum.
Here's a quote from their very article article that, and the authors here wrote, although project teams are largely on their own,
they are not uncontrolled.
Said management establishes enough checkpoints to prevent instability, ambiguity, intention from turning into chaos.
Ken Schwaber, who's kind of the godfather of Scrum, has talked about Scum as being kind the act of controlling chaos, right?
You're just on the edge of crossing over and do chaotic activity.
So at the same time, management avoids the kind rigid control that impairs creativity and spontaneity.
We want to have just enough control, that we don't go into either direction.
we dont get too rigid, too much control.
It's from an early Agile book, book in 1990. They wrote, to be sure, control is still exercised, but it is subtle and much of it indirect.
So agile teams, self-organizing teams are still under control.
They're under influence.
But it's subtle and indirect.
It's not us forcing them to do things.
You must do this.
I say this, you have to this this So it subtle an indirect control, subtle, and direct influence So what we're not talking about here is being deceptive
or sneaky.
This thing is driving me crazy.
Its staying on one ear and not on the other.
So we're not talking about being deceptive or misleading to the team.
We're talking not about lying to them.
It was no lie to you that our host from NDC set the chairs up in here, right?
We know they did it for our benefit.
So the control that we are going to exert is maybe not something that were going too to broadcast.
But we aren't going necessarily to hide from a team that some of it may be going on.
That all sounds philosophical.
Here's what I mean about this.
I may have a team that I do not think is working well together, and I put another person on that team because they bring a different decision-making style
to that.
I think that's going to help the team.
If the other team comes to me and says, hey, why did you put this other person?
I don't necessarily want to tell them, oh, because I like your decision-making style, and they have a different one.
Because that's going to undermine the impact that person is going have.
So I may not broadcast why all of the interventions I take with the team are there.
Oh, I'm putting them there to change your You will not.
That'll just reinforce their behavior, and they'll fight me on that.
So I may not broadcast why I do those things, but I don't feel like I'm being sneaky or deceptive.
And what I mean by that is three years later, they come to me and say, hey, why'd you put that person on our team?
Oh, you had a different decision-making style than I thought was helpful.
You guys were very quick to decide.
I wanted to add somebody who was a little bit more deliberate in their decision making style, so I added whoever to your team.
I'll be happy to tell them a couple years later.
But I'm not just going to broadcast it.
If I broadcast, it's going kind of defeat the purpose, in some cases.
So I am not talking about being sneaky or deceptive here.
I don't ever want to feel like I've lied to my team or sneaking around behind their backs.
And doing things, I intervene with the team for their own good.
but I may not broadcast the reasons in advance.
We'll talk about this idea of containers, differences, and exchanges.
The idea here is that for self-organization to occur, there are three things that are necessary.
The three thing that is necessary are a container, some differences, and some exchanges.
These ideas here are based on the PhD research and other writings from a woman named Glenda E.
Young.
who studied self-organization.
And so she says that we need to have a container.
Now, a contain can be lots of different things.
A container can a physical boundary.
Our room today is a containers.
The container could be more of a conceptual boundary, the project that were on.
Container can be semi-physical.
It can the campus we're on.
We are in the Oslo campus of our company, right?
There's also a part of the company in Beijing.
So it might be physical, it may be more just kind of conceptual.
I am part the American team.
Right?
I'm working in Oslow, but I one of Americans.
That might a different container that we are on, so any person will maybe in a handful or more containers on a project.
But there has to be something that bounds us.
Think about me telling you about people going to the Jimmy Buffett concert.
They go to this music concert, right?
They had to in the same physical place.
That was their container for self-organization to occur.
We have to have in this room for a self organization.
There's got to something we have that bound us together.
The next thing that we need, we needed differences.
If we were all the How we organized, how we self-organized wouldn't really matter.
So we have to have some differences amongst us.
Now, any time we're talking about humans, that's fairly pretty much a given we are going to differences.
The differences can come in all sorts of ways.
They can be technical differences, can mean knowledge differences knowledge of the technology, knowledge the domain, it could be the experience,
could our gender, our power in the organization, educational level, years of experience.
Our network within the organization, all those types of things will differ.
As humans, we're going to have plenty of differences, but we need those in order for self-organization to occur.
We also need what she called transforming exchanges.
A transforming exchange is where one or more of these agents, in our case humans generally, I don't mean that as a joke.
Sometimes the agents can be groups.
The QA department talks to the programming department.
So when agents talk, there have to be transforming exchanges.
I go talk to my chief architect, and my Chief Architect tells me a good way to design a solution.
That was a transforming exchange.
That was a transforming exchange, a good one.
So any sort of exchange here where something is going to influence what you do next, knowledge, information, motivation,
I go talk to my product owner and my project owner tells me about an amazing site visit she just had with a client.
I leave motivated.
I'm excited about this project, I cannot wait for this to get out in people's hands.
So that's a transforming exchange.
Containers, differences, exchanges.
Three things that influence how we self-organize.
Now if those things influence we can use them.
We can us them to influence a team self organizes.
And we're going to want to use these in good ways.
So one of the things that we can do is we an introduce or remove containers.
We can enlarge a container, shrink a We can influence the differences.
And I gave an example of where I was introducing a difference on a team.
I said I had a particular decision-making style.
When I give the example, they rushed to decide.
All right, I have some teams that I work with who rushed decide, that don't talk about things, in my opinion, thoroughly enough.
They're very quick to decided.
So I might want to slow that down.
Introduce a different on that team by bringing somebody onto that teams who makes decisions in a diffrent way.
A little bit more deliberate, maybe too deliberate.
Maybe that's the right balance.
So I'm introducing a difference there.
An exchange.
I may introduce, have people talk to each other.
who aren't talking today.
I introduce a new exchange into the team, right?
And introducing that new change, that team may self-organize a slightly different way.
Notice I use the word may there.
What we're talking about here is intervening with the teams.
Intervene with a team.
Introduce a container or ask for a change to occur.
I'm intervening with the team.
I do not know how that will result.
Right, I put a new intervention in with a team, but I don't know if they will respond.
For example, if I may ask a person to start pair programming, and I've done that a lot, then I have a pretty good idea of how a pair will react to pair programing.
But I really don' know what this person will do.
They may respond in a predictable way, they may not.
So we have to take a series of educated guesses as we make these interventions with our team We're trying to help a team get better and better in terms
of how they self-organize.
We are not doing this just for our fun, we are trying help the team be better.
But any one intervention I'm taking a little bit of an educated guess as to how that team will respond to my intervention.
I am going to do an exercise here shortly where I will ask you to think about how you might intervene with a few teams.
Before I do that, I want to show a couple more things that we can do as part of these containers, differences and exchanges.
So here we go.
With containers, I can enlarge or shrink the team.
I could make the teams bigger or smaller.
This team is not working well together, let's make it a little bit smaller, all right?
Let's let the six-person team figure out how to work together.
Then I'll add two people back, the eight people not getting along, it's not workin' out.
Maybe I need to make the team bigger.
Maybe it's a seven-person team, I want to add two people.
So changing the size of the teams will, of course, change how they work together.
I can shrink the responsibility boundaries.
Here's real example.
And their definition of done included handed off to the sysadmin group.
The siss admin group would deploy the software.
And they were giving the softwares to sss admins in a state that was not very deployable.
Right, the system administrators had too much work figuring out how to actually deploy this.
It was too manual, it was very hard for the systems administrators to do.
across a couple of thousand servers.
So we expanded the scope of responsibility for that team.
I told them their job was not to just hand it to the system administrators, their jobs was to get it deployed with the System Administrators help.
And so I increased the scale of their responsibilities, not just have it ready to be deployed, but actually deployed.
Changed how they self-organized.
They now had a larger scope for responsibility.
Change team membership, maybe not even changing size.
Just take one person out, add another person.
That will certainly change how we self-organize.
Create new teams or groups, introduce a new group, split a team into two, things like that will be examples of changing our containers.
Let's look at changing differences, some of the things we can do here.
Talk to a team and have them, encourage them or ask them to make their decisions a different way.
Some teams feel like they have to have consensus on every decision.
We all have Maybe that works out great for some teams, maybe not for others.
So with a team that is struggling with this, Maybe I can encourage them to use a different decision-making style.
Look, do we really have to agree on everything?
Maybe we can just do a typical kind of thumbs up, thumbs down, thumb's neutral type of thing.
As long as nobody is saying thumbs-down, we'll go with his decision.
There's other techniques called things like fists of five and things this.
Maybe, I could go to an approach where we don't quite require consensus.
Getting some sort of discussion going there in a different way.
I'm a big fan of having a fierce debate about things.
Let's come, have a first debate, figure it out, and then we'll agree, we will move on.
Not everybody on the team may have to support that.
Maybe I have another team who is doing the opposite and I want to push them to have consensus.
Do not make a decision unless everyone of you agree.
One of the things I probably spend half my life doing when I'm consulting is asking questions.
What could go wrong if we chose this?
What other three decisions did we rule out?
Why is this decision better than that one?
what was your second best decision?
So I will ask a lot of questions like that.
Early in my career, when I was learning how to be a manager, I actually wanted to become proficient at asking these types of question.
What I started to do, is go into meetings, and I would actually track on my fingers how many times I made a statement versus how may times i asked a question,
Making sure I asked more questions than I made statements in those meetings.
So asking hard questions of a team will bring out whether they agree or disagree.
Now it won't stay on either ear.
One of the things that you can do is to try to bring the differences among team members by asking those hard question.
Last one, our exchanges.
We need transforming exchanges Here's something I did that a lot of people would think was very non-agile.
And those of you who know me know I'm very agile.
I kind of live and breathe to help agile teams.
Here is something that I do that people accuse me of having done that was non agile I had a Scrum team and I told them that I wanted all of their key architectural
decisions to be reviewed by an architect who was not really over their team.
He was just kind of architect in the company, senior guy in company but he wasn't like responsible for their teams.
And I said I want all your decisions run by Todd.
I want you to take all of your decisions to him and make sure he approves of all your big architectural decisions.
Then I went over to Todd and I talked to them and explained what I was doing.
I said, I'm going to have this team run all their architectural decision by you.
And I'd like you look out for them making big mistakes, but mostly I wanted you be here as somebody scary.
I want this team to have to worry about, uh oh, we have go present this to Todd.
And that would make them think through their decisions more thoroughly.
They would be more prepared, they wouldn't rush to decide, and they would more thorough, which is something I wanted out of this time.
I told Todd, I said I don't really want you to overrule them very often.
Of course do so if you think they're about to make a big mistake.
But I say the biggest thing I just want to do is ask them some of those hard questions.
Intimidate them.
Make sure they come to you prepared.
But if they're giving you good answers and you can tell they've thought about it, that's probably good enough.
So here I was, I kind of slowed this team down.
A non-agile thing to do.
I made them go get approval on their big architectural decisions.
But I did it for their good, to get better results out of what they were doing.
So I would still support what I do there, even though it may look like a non agile thing.
It was an exchange that I introduced.
Introduced a new exchange into this.
Sometimes you can look at this and say, who's talking that shouldn't be?
Who do we have not talking?
And we can introduce new exchanges into the mix.
What I'd like to do is do a little exercise here where you get a chance to intervene with some teams.
Oh my god, this thing is going to kill me.
Here's what I'd like you to do.
Here is an example.
So suppose you are a scrum master or coach for an agile team.
The next couple slides, these are what are on the handout.
They describe some teams that are having some troubles.
What I would like to you do, I'll let you self-organize into a couple of groups, those next to, and discuss these problems.
We'll do the first one here together, then I will let pick one or two to each talk about.
I want you figure out how you would intervene with this team and whether that intervention is a change in container, difference,
or exchange.
So here's an example.
Let's talk about number one here.
We've got a team that has four programmers, two testers, database engineer, and you.
The programmers and testors are not working well together.
Programmers work in isolation until two days are left in the iteration.
Then they throw the code over the wall to the testters.
Anybody have an idea of what you might change here and whether that's a change in container, difference, or exchange?
What might you change, here?
I'm sure some people have been in this situation.
Yes?
OK, so get the programmers and testers integrated better.
Change the container.
One way we might do that, maybe they're not sitting close enough to each other.
Maybe I need to set programmer, tester, programmer tester like a dinner party or something.
Get them more integrated in their container that way.
Other thoughts on things we may do?
Yes, thank you.
What would that be, a change in container, difference or exchange?
The container, yeah.
Yeah, when we change the responsibilities, it changes the container.
So now the programmers are not responsible for write good code, they're responsible to write high quality code.
Esther?
Well, first, I want to know more about what's going on.
Of course.
But the example that was just given in changing the responsibility is also dampening the difference.
It's saying you don't have these distinct roles between I am a tester and you're a developer.
That's an excellent point.
Thank you.
All of these, we're going to want to know more information.
We're just going have to make some guesses with half a page of information on these things.
But you're absolutely right.
Very often, if not always, when we change one of the things, there will be ancillary effects.
I change the container, I have an influence, as Esther pointed out, on terms of the differences here.
I'm no longer a programmer and tester, but I am a team member when we make that type of change.
So, when you go through these, think about which one you think is primarily is.
One of things you can think of is if you see something that is, okay, it's primarily a container but also see the impact on differences and exchanges,
Sometimes we can look at that, and that tells us, to some extent, the magnitude of the impact there.
If you're changing something that sounds pretty much like one of these, maybe only a minor intervention.
You're doing something if you make a change that's going to impact all three, much more likely a stronger intervention, you have to decide.
Are you trying to make strong intervention or are you just trying make minor interventions with your team?
So here's what I'd like you to do.
Let's take, I don't know, six, seven minutes, or maybe 10 minutes.
I'll look at our timing here.
But form up into some groups, just a couple of you next to each other, and talk about one, maybe two of the other situations on there.
We'll get back together in a few minutes and share these and see if we can have some answers for at least one or two more of these others.
So talk with us for a minute in your groups.
Got it figured out?
Working together there.
OK.
Let's start up again, see how we do here.
I know we're all shy, but let's see if we can at least talk about one or two of these.
Do we have a group that will volunteer to tell me what possible interventions you came up with for one of this problems?
We have group who will help us out in one our discussions.
Thank you.
Which one did you guys talk Number two, this is failing to deliver potentially shippable code.
What might you do there?
One suggestion would be to have the product owner sit closer to the developers.
OK.
So they would know better if the feature is actually done.
Have the project owner set closer the team?
What do you think we're changing there, is that primarily a container, difference, or exchange?
Well, it's a Container Analytics change.
Yeah.
Yeah, so we're changing the container.
We're bringing the product owner closer in with the team.
Or introducing a new exchange.
Were having the project owner talking with a team more frequently.
All right.
So we've got some new exchanges going on there.
Right.
What about another one?
Anybody talk about three, four, five or six?
Let's get one more.
Get another comment or two.
I appreciate your comments on that one.
Thank you.
One more?
Yes.
Number five, oh yeah, yeah.
OK, so introduce something like planning poker is a different way to estimate.
Planning poker's a consensus-based approach to estimating.
Everybody holds up a card all at once.
Some people will be talking about, I think, in the next section I'm doing after lunch.
So we might do that to help avoid the influence that Jeff is having by being so domineering.
This is actually a real one I worked with.
That is one of the things we did there.
Thank you for that.
And again, a lot of these The way I use this is a lot of times when I'm consulting to companies, I've seen a problem before,
and I go, OK, what did I do before?
And I remember what I might have done with a previous company, did it work, does this situation seem similar, now I know what to do.
So I'll use it that way.
But if I don't know to what do, if i'm seeing something that I haven't seen, or I am trying to think through possible solutions,
thinking through the containers, differences, exchanges that exist in that company I find helpful as a thinking tool.
OK, what containers are here?
What containers could I change?
Who's talking that, who's not talking maybe should be?
what exchanges could i introduce?
And so I'll think about it that way.
So sometimes I use this as a thinking tool with some of the teams I work with when I try to find interventions, way to influence them.
I want to shift and talk about kind of the second main topic here, which is how to influence how a team evolves.
So teams have what's called a self-organizing path.
The way a time is self organized today is different than how they are going to be self organize tomorrow when a teams moves along this path,
right?
Self organization is not something you can put on a Gantt chart.
right inside okay we're done self-organizing check that off right it constantly happens a team self organizes constantly so we have to be aware of of directing
the team guiding the teen to better and better levels of fitness with their environment Self-organization proceeds from the premise that effective organization
is evolved, not designed.
It aims to create an environment in which successful divisions of labor and routines not only emerge, but also self-adjust.
in response to environmental changes.
So we adjust to our environment.
He says this happens because management sets up an environment and encourages rapid evolution toward a higher fitness, not because manager has mastered
the art of planning and monitoring workflows.
Again, management's job, leadership's, job is to set up and environment where this can happen, where the team is able to rapidly evolve,
rapidly adjust, to their environment, we don't pre-plan it.
So team evolution, if we think about evolution.
Evolution is a result of three things.
Variation, selection, and retention.
And let's not think of a team first.
Let's think something easier like a giraffe.
A giraffe has a random mutation that leads to a longer neck.
That is variation.
We randomly varied, right?
Selection means that that random variation actually turned out to be a good thing.
That giraffe could survive where others couldn't.
Retention is where evolution has that giraffe species continue to have that long neck.
The mutation is passed along to descendants.
So for evolution to occur, we need variation.
We're going to need changes to happen.
And we're gonna have to have a way to select among those.
and we have the best to be retained.
Variation, selection, and retention.
Anderson, in one of his articles, wrote about seven levers for influencing.
How a team evolves and so I want to touch on some of these these levers here The first one is select the external environment Things that you can do to
influence how a team evolves is you could adjust their external environment.
This is very similar in some ways to the containers we had of the earlier discussion.
That's more than just the physical environment, sometimes we can adjust the business we're in or the definition of business were in.
I remember the first time I went to work with Yahoo, this was back in 2003 or 2004. Yahoo.
Think about how you think of Yahoo?
I think about how you would define Yahoo, and I go out there 2003 2004 and they tell me we're a media company like a Media company right and you know they
were they, were in the process of gradually moving headquarters and all key employees down to southern california They're,
gonna be in hollywood all right we are a, media, company, we create media for the web You're not a.
Media you're you, know kind of second rate search engine at this point, right?
You're a technology company.
And I think this is part of what Yahoo has struggled with over the last eight, nine years, figuring out their identity.
But they went for years where they had this CEO who said, we're media company, and so we can think about the external environment.
Now, a lot of us cannot influence that, but I want to just touch on this one in case some of this can.
Some of our companies are innovators.
Others are fast followers.
What type of influence do we have on how we view our company?
Second thing that we can do, and hopefully more of us have influence over this, is define what is good performance.
What is acceptable, what good is performance in your company, right?
What messages do you send if you cancel training?
Anytime there's a crisis, we cancel the training.
Think about the type message that sends.
It sends a message we value the short term over the long term.
I had a boss, many of us have had boss like this.
This boss thrived on chaos, and he loved it when employees rose to the occasion during chaos and put out fires, even if they were the ones who caused the fires.
And so we've often had bosses like that who love that firefighting capability.
So that just encourages employees to create fires so they can be the one to put them out.
So what do you define, what to you as a leader define as good performance?
What are you rewarding as performance, right?
The things that we reward, the things we praise and talk about in the company, those will be the thing that teams move towards.
So I wanna make sure teams are moving in their right direction.
Manage meaning, What becomes meaningful in your organization, all right.
What type of stories are told in a company?
What type of stories get passed around?
Those stories, again, influence what people value and what they respond to.
I live in Boulder, Colorado.
I got invited into a, what to me would have been a fantastic client.
They're about five miles from my house, they're a medium sized division of a very large company, and we're going to be an absolutely fantastic clients.
And I go there and I'm spending the entire day giving them some advice and they are kind of interviewing me to see if they want me hang around for the
long term, do a long-term engagement with them.
Man do they have problems.
This is going to be a great client to have.
And I get to the end of the day and I've heard about this new general manager they've got, and the guy sounds, yeah, I'm not real wild about the stuff
I heard.
But I got to end the of day, but I already decided I don't want to work with these guys because it's going be hopeless.
I won't be able to help them.
I get to this, I'm supposed to have a meeting at four o'clock with the general manager and I go meet with human resources director because the GM is too
busy to meet me, he's going to be late and the human resource guy is just kind of babysitting me for a little while and he starts telling me stories about
this general manage and how great he is and one of the reasons he so great is because he goes out in the parking lot at five o clock every day,
typical US quitting time and counts the cars.
And he wants to, this human resource guy is trying to impress me because this GM counts the cars and isn't that great?
He's making people work late by counting the cards.
And I just wanted to kind of shock the guy and I said, oh, that's fantastic.
He goes out there at five o'clock and he counts their cars.
Then what does he do?
Come in and find anybody who's working too late and sends them home?
And this human resource guy, no, he wants him here late.
What type of culture is this setting up when you know your boss is out counting the cars at 5 o'clock?
It's a horrible thing.
I had another company I worked at.
where we actually had a story that was getting passed around that I thought was fantastic.
The company was a small company that public and was finally going to be profitable.
Maybe.
Maybe they were going to make a profit this quarter.
It depended if we could keep costs in check.
As long as we kept costs down, this company was going make money.
And it was gonna be real close.
The company's either gonna make little bit or lose a little.
But that first quarter in which you cross over and you're now profitable is huge.
right and whether we make a thousand dollars or lose a $1000 that is a huge difference and it is it's going to be really close and so we have this all
company meeting and the CEO stands up in front of the the whole company and is stressing the importance of keeping cost down Right?
Don't buy office supplies.
You can buy them three weeks from now if you need them.
Do not buy off of supplies, don't book any business travel.
We're trying to be profitable.
And then here's the key part of what he told us.
He said, while this meeting is going on, I have the janitors going to every bathroom in our building.
They are taking out the nice, comfortable two-ply toilet paper and removing it and putting in cheaper one- ply toiletpaper.
I'm sure this cost him more money than it saved by going to cheaper toilet paper.
But I remember him saying, he said, that I want everybody in here thinking about profitability at least one time a day.
Really interesting message, but he got his point across.
And the company did achieve their profitability.
So what becomes meaningful in your company?
What type of stories get passed around?
Another thing we can do to help evolve Pick people.
Now we're back a little bit into the container difference exchange thing, talking about some of the people involved.
So think about who we want on the team.
give you one other story about somebody put on a team one time i had a teen that was uh...
uh they were doing too well and i put a person on the team of the program on that team who's not one of a better programmers i don't know what it was about
this guy's name was mark uh but he was like blue i considered him like glue he would he wouldn't keep the teen together and had to know if fighting they've
been put together to an acquisition and this uh this one per mark he just had great personality he with the one that uh that people were always going over
to his house after work and on the weekends and things like that.
I looked back on teams that he had been on, I'd worked with this company for a handful of years, and nobody ever left when Mark was on that team.
He just had a personality that kept people together, just a real friendly guy.
So I put him on a team and he said, what is my job on this team?
I said basically to be the glue, i want you to keep this theme together.
We have this thing that's coming together from an acquisition, they hate each other.
And you're just such a nice guy.
People always get along with you.
And your job is to help make sure this team stays together through the rest of this project.
So we think about who we're putting together on a team.
One of the questions we often get is, should a team have the right to decide who's on them?
I'm okay with teams deciding, with companies deciding to give that power to a theme, but it's not something I normally do.
I normal do not let teams have to right decide, who are team members.
Much more of a fan of keeping this as part of management's responsibilities, because this is one of primary ways that leadership in an organization gets
to influence self organization.
So, I'm not a big fan of abdicating that, giving that to teams, but I have done that on teams that I would put pretty far up the maturity level.
A couple other things that we can do to influence self-organization.
Reconfigure the network refers to having different paths of communication, different types of conversation occurring, and to introduce or remove flows.
I want to show an example of what I'm thinking about here.
Imagine you have a team in two locations.
You have a team here, and you have team back home where I live in Denver.
So half your team in Oslo, half of your time in denver.
A very common way to structure that team would be as shown here.
We would have, a, team, in, Denver, we would, have the team and Oslow and they would just coordinate their work.
But they, would essentially separate teams.
Now, there's some danger to that.
There's a little bit of possibility of us and them mentality creeping in here.
So there is some dangerous here, so another possible way of constructing that team, assuming we have the right skill sets in each city,
would be to do this.
We'd have what we call a deliberately distributed team.
Have half the team here in Denver, another team that's half here half in denver.
so have two teams that are equally distributed.
So I know our common reaction is to look at this and say, I'll do the top one.
I have an intact team in Oslo, an in-tact team Denver.
But sometimes that leads to problems.
And sometimes the way to get around that problem is do do bottom picture here.
So we reconfigure the network.
We have different paths of communication.
All right?
I tend to think of this a little bit this way.
If we do that top Not a lot of day-to-day hassle.
I don't got to get on the phone at a weird time of the day.
Not lot a hassle on that top one, but a big risk of a blow up.
We can have some us versus them problems.
we can some miscommunication.
Of course, we do design by contract, But the two teams go in different directions.
And then they find out they've gone later.
They find that they have gone in a different direction and things aren't working.
So very little day to day hassle, big chance of later problems The bottom picture, a lot of day-to-day hassle, but not a big chance of any long-term problems.
So I kind of think of that bottom one as a little bit like an insurance policy.
I can do that.
Bottom one, I'm going to be paying insurance premiums every day, every time I get on the phone at a weird time.
And paying little insurance to keep us in the right direction.
But I don't have the big blow up.
I'm not advocating either one.
I am not saying one is better than the other.
As much as I look at that top one and think by default that's how it will structure teams, I often do it the bottom way for various reasons on a given team.
So we can reconfigure the network in a slightly different way.
Another thing we can do to influence our evolutionary path is to create what are called vicarious selection systems.
Now, think about it this way.
Imagine you're thinking about Agile, you are thinking of doing some Scrum, but you also think of Kanban, and you've also got some people in your company
who love waterfall.
Here's the best way to resolve that dispute.
Have a bunch of teams use Waterfall, have a BUNCH of Teams use Scrum, Have them develop products for the next few years,
and at the end of let's say a 5 year period, let us figure out which of those sub companies made more money.
That's a very lengthy process to figure that out, a lengthy and a expensive experiment.
So we don't want to do an experiment like that, it's too expensive.
What we want is to set up vicarious, alternative selection systems.
Alternative selection system are ones that can help us find out what ideas are good ones.
One of the best examples of a vicaerious selection is Google.
You've probably heard that Google has their 20% policy.
Every employee at Google gets to spend 20 percent of their time on whatever project or initiative they want.
Now imagine you're a Google manager or Google VP and you see a lot of your developers flocking to work on a particular project.
That's a pretty good indicator that project is going to be successful.
People want this.
My programmers and testers want to work on this, people want work to on projects that will be successfully.
And that they would use themselves.
Google's audiences, a lot of it is their own people.
They're representative of their audience.
So when they see people flocking to those type of projects, that is an indicator of that might be a good idea.
So what type of things can we set up in our companies to be vicarious selection systems?
Retrospectives can help with this.
Seems we'll start to identify the problem sooner.
Last one I want to touch on here is energize the system, pump energy into the systems.
It is amazing when you visit a team that is energized how much more they are getting done than a time that it is not energized about their process.
So one of the things we want do is to make sure a teen has a clear elevating goal.
I had a reference to a book called Teamwork, I think down there at the bottom.
Another reference here is to make sure a team has an igniting purpose.
This comes from a Book by Wenda Gratton at London Business School.
And a Team with an Igniting Purpose will outperform a Teams that doesn't.
So part of our jobs as leaders is help teams find what ignites their passion.
Now, this doesn't always think of something like this.
I always thing of somebody like Steve Jobs, you know, giving great keynote talks and getting his Apple employees so motivated.
It doesn' have to be somebody as passionate and inspiring as Steve jobs.
As an example, let's take somebody who's nowhere near as inspiring Steve job.
Let's think about somebody A very successful business guy, but I don't think of him as giving the same kind of impassioned speeches as Steve Jobs would do.
Now let's flashback.
1993, Bill Gates says, we're not interested in the internet.
A little bit later, he realizes they need to be interested in the internet.
And you probably have heard about a memo that he sent out.
It wasn't even an email.
A memo he circulated around Microsoft in 1995, it was called the Internet Tidal Wave Memo, where he got all of Microsoft riled up about the web.
Okay, this might have been Bill Gates' shining moment.
Here was his big passionate speech.
The internet is a tidal wave, it changes the rules.
It's an incredible opportunity as well as an incredibly challenge.
I'm looking forward to your input on how we can improve our strategy.
is not very inspiring.
Doesn't exactly say a whole lot.
Any CEO I've worked with or worked for could have written that same memo.
But that was the one that got Microsoft turned around and focused on the internet.
So it doesn't have to be some amazing speech by a guy in a black turtleneck.
It can just be something that gets us all excited about whatever it is.
I don't consider this to be a particularly fiery memo, but this turned Microsoft around on the spot.
So seven things we can do there to influence how a team moves through their evolutionary self-organizing path.
Thank you all very much.
