How to Rule a Self-Organizing Team

[article]
Summary:
Matthias Bohlen shares with us the importance of self organization. As a manager, you must set time or organizational boundaries that serve a purpose and let team members do what they think is appropriate and necessary within those boundaries.

The cellphone rang on a Sunday afternoon. The number on the display was new to me, so I slid my finger and curiously answered the call. The caller, however, was a coachee of mine whom I knew quite well. We have an agreement that in urgent cases he can call me even on a Sunday. He therefore did not hesitate to get right to the point.

“Matthias, this is George Markakis. I guess I could use your help once again.”

“Hello George, nice to hear your voice,” I said. “This phone number is new—what happened?”

“Last month, I left my old company and accepted a new position as the head of product development at Acme Software, right around the corner from here,” George told me. “Is there any chance that you can stop by on Monday so that we can talk?”

“First of all, let me congratulate to your new position, George! And yes, on Monday, I am in your area. We can meet at 3 p.m. if you want. Do you want to tell me what the challenge is?”

“Not now. You’ll see what I mean on Monday. See you at three.”

George is a fast guy. He will have a reason, I thought.

When I entered George’s office the next week, I saw a bandage around his head. “Hey, George, what happened? Nothing really serious, I hope?”

“No, just a little accident with the bike,” George replied. “My twenty-two-year-old daughter Julie and I met this weekend, and of course she wanted to impress me with something that she can do and I can’t. So we went for a speed ride on our bikes. I tried to insist that I could still keep up with her speed, even at my age. But when the road suddenly turned into cobblestone, the front wheel of my bike began to wobble so hard that I felt I was losing control of it.”

“That sounds dangerous,” I responded. “And what did you do?”

“I grasped the handlebar more firmly and the bike seemed to stabilize at first,” George explained. “However, the wobble went through my arms and body and suddenly influenced the entire bike. A moment later, I crashed and found myself sitting on the road.”

George then described how Julie helped him get up and collect his bike. After doing so, she commented on the accident.

“She said something about a mistake I made when I encountered the cobblestone road, “ said George. “But right now I cannot remember what she said, it was something about a firm grip on the handlebar.”

I felt that the elephant had left the room and decided that we should get to the real reason why he called me.

“George, I can’t help you with speed riding on the bike,” I stated. “What did you really call me for?”

George told me that after becoming the head of development at Acme, he had to take care of two particular development teams. Three months before George came, Acme had started an agile transformation initiative, and those two teams were the pilot teams for the use of agile methods.

George said, “When I came here, I noticed that the market and the customers are very different from what I know from my previous company. Every customer wants something different every two months or so, and no two customers are the same! They want our system to adapt quickly to their particular situation, and they are trying to make us get everything done yesterday.”

“And how did you react?” I asked.

“Well, I am trying to reuse the methods that I learnt in my previous company,” answered George. “Whenever a new requirement pops up, I look for an idle resource that can implement it. I go to the programmer and tell him what to do.”

“And did that work?” I asked inquisitively.

“No.” George said. Especially with those two agile teams, I have a problem. They do not accept my effort to make them do what the customers want. Instead, they tell me something about self-organization and ask me to stop micromanaging them with such a firm grip.”

George wanted the teams to achieve results, preferably with high quality and in a predictable time frame. On the other hand, he realized that product development is not one of the most predictable processes and suspected that his teams might have a point.

George was a smart guy. He saw that he was getting nowhere when he intervened too much with the teams. A very pre-determined product was going to be developed; one that might not be successful in the market. On the other hand, if he would engage too weakly, the team might create something fuzzy and unclear, which would also not correlate well with what the market needs. He was afraid that the team members would research for too long to find many options, and that they would not stop in time to close the options and deliver the product.

George made me probe into his dilemma a bit more.

“Matthias, my question is, ‘How much do you really have to guide, limit, or frame such a self-organizing team so that it successfully delivers something useful?’”he asked.

“Let me think for a moment, George,” I replied.

By now, George had told me two stories: one about the bike accident and one about the “team accident.” I was pretty sure that there was a common theme—a connection between the two stories. So I decided to ask George to find the common theme himself, to which I would add my advice.

“George, you already know the answer,” I said in a matter-of-fact way.

“What do you mean?” George wondered.

“You told me two stories— about biking and about managing self-organizing teams,” I responded. “I noticed that the first and the second story have two important words in common. Can you spot the connection?”

“No—what the heck…” he said.

“It was something in Julie’s words when she picked you up,” I replied. “Something about a mistake you made. And the teams also (sort of) criticized you about a mistake.”

“Oops, you mean the words firm grip?” he asked.

“Exactly!” I said enthusiastically.

George did not hesitate a single moment; he called Julie on the phone.

“Darling, what did you say to me after the bike accident?” George asked Julie. “It was something about a firm grip.” I watched him while he listened to his daughter on the phone.

“OK, thanks a lot,” he told Julie. “Maybe you helped me more than you think. See you tonight?”

After talking to Julie, George learned some valuable lessons about bike riding. When you ride a bicycle on a cobbled street, the cobblestones cause the wheel to vibrate. When you grasp the handlebar too firmly, it transmits the vibration to your body and to the entire bike. The vibration finds a resonance frequency and reinforces itself, the entire bike wobbles, and eventually you fall down, along with the bike. On the other hand, if you don't hold the handlebars firmly enough, the cobblestones drive the handlebar quickly out of your control, here's a crash to occur, too.

Apparently, it works best if you keep your hands slightly open so that the handles of the handlebar have some (but not too much) spare room in your hands. While the vibration continues in your arms and hands, the rest of your body and the bike itself remain stable. You, as a driver, can feel the powerful vibrations in your hands, but the strength of this vibration is still manageable. The speed of the bike, despite the cobblestones, remains relatively high.

This was the connection—the common theme. Teams are like road bikes, markets and customers are like the cobblestones, and managers are like bike drivers. The driver must "join" the pavement and the bike to form an overall system, to which they he exerts just enough control—not too much and not too little.

Over-regulated teams suppress important information, as not to attract attention. They ignore important changes and differences that arise in everyday life. They think that the system must be stable at all cost. There are rules that suppress any news or prevent it from entering the system from the outside. "Business as usual" is the motto.

Under-regulated teams are not much better. They have no focus; they cannot recognize important information, because everything is of equal importance and has no consequences whatsoever. People avoid conflict, work unfocused and inefficiently, and can be easily distracted by outside interruptions.

Self-organizing teams work best in the middle of these two extremes. It is important that people can clearly see the boundaries; for example knowing who is part of the team and who is not, which deadlines apply, how often work must be delivered and at what quality. Team members should make positive use of differences in skills or opinion. That way, stress and conflict can be openly addressed and resolved in the team as well as outside of it. Special skills of individual team members are not envied but "plagiarized."

Communication in properly controlled environments is closely interconnected; it does not only take place top-down but also bottom-up and sideways. Communication in such a team creates meaning and purpose and gives the team direction. Patterns evolve, successful approaches are replicated, failures are analyzed, and people learn from them.

All this does not happen when there is no frame around self-organization. As a manager, you set time or organizational boundaries that serve a purpose and let team members do what they think is appropriate and necessary within those boundaries. In the same way, the driver of the bike allows it to wobble as much as necessary, but not more.

The rest of the coaching session was a piece of cake. George and I discussed his particular team situation, the market situation, and what to do about it. We spent an hour on it and came out with a list of small experiments for George to try. Shortly after that, George was able to resolve the conflict and learn how much “grip” the teams needed.

Try the same inside your organization. Establish self-organizing, cross-functional teams, and provide them with the necessary frame to give them guidance. A frame can be organizational (i.e. team and department boundaries), a time constraint, a set of goals, a set of policies, and so on. Clearly communicate this frame setting and then let the teams do whatever necessary within that frame. Let team members think and decide for themselves and help them by removing any obstacles that are beyond their (but maybe within your) control. Give them feedback—positive and negative—as timely as possible. After doing this, watch them achieve results faster and watch your to-do list shrink.

Tags: 

User Comments

14 comments
Peter Saddington's picture

I'm sorry. This is just rubbish.

I made an account specifically to comment on this post.
Language reflects your mental models. The type of language used in here is limiting and dangerous.

So what you're saying is that a "grip" of some sort on a team is helpful for them to succeed? Are you kidding me? This article is a horrible mashup of industrial thinking, improper metaphors and a general mis-understanding of knowledge, knowledge work, and knowledge workers.

You have just lost a subscriber to this blog.

February 28, 2013 - 9:12am
rtrosper's picture

I have to agree - I'm glad I skimmed it or I would have wasted even more time. There is NO useful advice contained herein that couldn't have been summed up with "work with the team" - which isn't much help.

February 28, 2013 - 3:25pm
Matthias Bohlen's picture

@rtrosper: Looks as if you are trying to save so much time that you sum up an entire article with 4 words. That's a disease of today. People think they have no time any more to sit at the fireplace and listen to a story, allowing their minds to digest and build up energy to act the next day. Sad thing!

March 1, 2013 - 5:49am
Clarke Ching's picture

Come on, Peter, that's just rude and angry.

I hope people don't *skim* the article, see this comment, then skip reading the entire text. It's a clever metaphor - one which I'll "borrow" - and I'm very glad I read the article.

Clarke

March 1, 2013 - 11:10am
Leyton Collins's picture

Matthias, this is a great article with great analogies. This article covers something I learned myself several years ago in a management training class and a colleague of mine at the time also said he learned in Judo training. That lesson -- When dealing with an opposing force, just move to the side whenever possible. It’s also two of my favorite quotes from the Dalai Lama “Seek not to accept provocation” and “Seek to understand before seeking to be understood.”

A good manager understands that they need to know how much leeway and how many constraints to give each of their teams and team members; or as your article puts it how tight a grip is needed on what is going on.

Certain others may say otherwise. I’d suggest certain obtuse ignoramous individuals would not understand this no matter how many analogies or languages were used. Oops, was that accepting a provocation? Not for me. :-) LOL

February 28, 2013 - 1:16pm
Matthias Bohlen's picture

@Leyton Collins: Thank you for your positive feedback. However, I am not sure I get the Judo metaphor correctly. Who is the "opposing force" in this case? From my p.o.v., I see a triangular, tightly coupled system: the market, the team and the manager. Three agents, each one exchanging forces with the other two, respectively. Would be great if they could arrange themselves as an orchestra.

March 1, 2013 - 5:58am
Grey Beard's picture

Peter Saddington: I agree, but I think I'd describe it slightly differently: it's not that it's entirely wrong, it's that it's basic management.

Generalization of what the article says:
Micromanagement=bad; no management=bad.

This isn't revolutionary, nor is it rocket science.

If you're got prisoners or draftees digging ditches, then you need to keep that "tight grip", so they don't run away or dig the wrong ditch. If you've got smart people doing creative work, then you need to worry in the other direction: left too much on their own, they may (not "will", but MAY) drift off in directions other than what the group (company, in this case) needs.

I don't see where this has anything to do with Agile, unless it's that with Agile, the group may be more likely to say "Hey, stop that!" than with traditional word-comes-down-from-on-high management.

February 28, 2013 - 3:53pm
Matthias Bohlen's picture

@Grey Beard: It can seem revolutionary and rocket science to manage agile teams, depending on what you did before. For George, as he had never managed agile teams before, it definitely was rocket science! He really wasn't sure about how far he should go and whether it was his responsibility to interfere or not (e.g. "what do I do with all these urgent change requests?").

What this has to do with Agile? The dynamics between an agile team and their manager can be very complex and can lead to a clash of cultures. I have seen teams fail, I have seen projects fail and I have also seen managers fail and even lose their job in such a situation.

Understanding those dynamics can help a manager to be far more successful with his teams. The point is not that this is basic management. From my p.o.v., the point is helping people to see that and be able to act.

March 1, 2013 - 5:29am
Grey Beard's picture

Hmm. So it sounds like you're agreeing that it's basic management, but you suggest that an agile team is somehow different from any other team in needing to understand the relationship between the manager and the team. Maybe I've been too self-managed throughout my career -- I still don't see this as being specific to agile?! It would seem to apply to any team/manager relationship. If the point is that George wasn't "getting it", then it's still not that interesting -- it just means that George hasn't been exposed to agile and/or is a lousy manager.

March 1, 2013 - 10:22am
Matthias Bohlen's picture

@Peter Saddington: Hope you still read here – if not, my comment is for the other readers of this site.

Yes, Peter, language is important, of course. My use of language was deliberate: In the article, I used my coachee's language. Like many other managers, George really uses words like 'rule' and 'grip'. What if I had used language from Agile or from complex adaptive systems (CAS)?

For example, this piece of CAS language here would have failed wonderfully:

"George, make sure that you constrain your system of agents at least and only so much that your agents really experience a transforming exchange of signals. Make sure that your feedback allows them to adapt and adjust their signal-to-value transformation rules. And remember that you are also an agent in this complex adaptive system!"

Guess what George would have responded? "Matthias, WHAT ON EARTH are you talking about? Are you sure that you don't waste my time?"

Or, I could also have failed wonderfully using language from Scrum:

"George, make sure that you ask your teams to give you a potentially deliverable increment of business value at the end of each sprint. Let them self-organize around the question how that business value should be implemented. Make sure that your feedback allows them to learn what business value is, and remember: you are a part of all this!"

Guess what? George's response would have been almost the same as above!

As a coach, I always have to start with my coachee's language. Use words that he/she can understand. "A grip on the handlebar" was something he could understand because he liked speed bike riding. From there, the discussion went into George's team situation, his market situation (e.g. "how do you define/create value inside your market?") and then into the coupling between his teams, himself and the market (i.e. the bike, himself, and the cobblestone road).

And, yes, Peter, a "grip" of some sort on a team is helpful for them to succeed! The only problem is that "grip" does not mean "tell them what to do" but it means "constrain the number of options they need to consider so that they can focus on what is important and can decide for themselves."

Letting a self-organizing team run free without constraints is like playing a game without rules – it does not help anybody.

March 1, 2013 - 5:02am

Pages

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.