Self Organizing Teams are Superior to Command n’ Control Teams

I’ve been thinking a lot lately about self-organized teams versus teams that are run in a command and control manner.  My experience and observation is that self organized teams blow the doors off of teams that are tightly controlled by some type of centralized leader.  I’ll throw out a couple reasons why I think this is:

  • People in a self-organized team are able to make decisions themselves and accordingly adapt to changing situations.  Command and control grunts have to wait for the boss to tell them what to do.  That introduces latency in the development process as the team waits for the leader to shake free to deal with a decision.  It can also sap a developer of any energy to contribute to the design and approach if they know they don’t have any say in the matter.  It’s a negative incentive to increase their intellectual participation in the project, and that can only hurt the team.
  • Self organized teams do a much better job of utilizing the talents of the team because more minds are involved in any activity.  By investing one person with all decision making authority, you effectively shut down the other team member’s contributions to the design and planning.  They become drones.
  • Self organized teams have much more communication between team members.  A command and control team chokes communication by running too much through one person.
  • Command and control organizations don’t provide as many chances for personal development.  The best way to learn is to have actual responsibility and opportunities to do new things.  If all you do is what you’re told without question, you don’t get to learn how to make decisions.
  • A self organized team is collectively aware of the upcoming work and much better able to bootstrap themselves with new work when they complete their existing task.  I’ve learned that there’s a lag between telling a developer to write a feature and the beginning of coding because it takes some time to understand what’s required.  You can cut down that lag by doing planning and design together as a team.
  • Self organized teams spread knowledge around much better and make decisions together.  That makes each team member more effective because they have much more background on the “why” of the coding assignments.  A command and control team member often lacks an understanding of why a decision was made because they weren’t involved with that decision.  That hampers their ability to follow a design or approach.

Maybe that works for some perfect team Jeremy, but I can’t trust my guys to bootstrap themselves.  I have to be in control.  Are you sure?  Really?  You’ll never know how people will deal with responsibility until they actually have some.  I’m actually an optimist in regards to people.  I actually think people can and largely will behave in a responsible manner. 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Yoke

    If I have a team of 7 and all 7 of them want to lead, manage and no one wants to do the work…..then self organization seems to introduce a forum for ego centric behavior and ultimately heavy conflict. This might be darwinian in some respects, but ignores the pragmatic reality that I need them to get things done.

  • Kent S.

    The McCarthys have extensive experience in helping people to self-organize into a hyper-producive (jelled) teams. see

  • SteveJ

    Most organizations are modeled on military ones. In a military organization it makes sense to have clear heirarchical structures with little room for questioning or innovation from those who havent earned their stripes. Most businesses at least claim that they want to be innovative and empowered (especially in our field), and the members of this field tend to be highly trained before they even join the tream (compared to a recruit). We also have few life-or-death decisions cross our desks.

    Based on that, I’m not sure you HAVE to have a central leader IF your employees are trained, enthusiastic, professional, etc. I’m pretty certain you need a central leader role, but I don’t think you have to put anyone in particular into it. If you have people that you have invested wisely in and they can keep their egos in check, then there’s no reason why the juniorest of the group can’t lead the way. In that vein, being the TeamLeader is more like being a parent, you need to enpower your children to lead the way so they can take your role someday.

    So how do you empower the team…uhh…by leading well? In the beginning you’re likely to have one or no members that can create a team concept. The end goal remains to create a team of leaders. And once everyone is a “leader” there is no central smart leader, but a self-organized kick-arse team where the least capable can shape and manage the vision.

    Of course, I’m not sure if that works well unless vision/leadership is shared and egos are left at the door. That may be too hard to pull off in an organization, in which case strong decisive leaders or the ability to weed out undesirables are needed. I think you can go very far with a strong leader, but I think the potential is even higher with a TEAM of strong leaders.

  • Emad Al-Ashi

    well, why does sound like it’s two divergent approaches when i see that it’s not?

    the mistakes that happen in teams that has TeamLeader (IMHO) is not due to the structure, but it’s due to the way it’s done.
    it boils down to the behavior which the TeamLeader takes to solve issues; so if he did the right thing (by being a true leader and giving good chances to others to proove them selves…and all the good suff jeremy said about self-organized team)…if the team leader paved that environment…then you have a successful team.
    on the other hand…if the Team Leader’s idea about team leadership is to be self centralized and sololy making decisions without any consultation..then thats the failure.

    emphasizing on what WayneMack said; it’s proved, throughout history as community-structured beings, it’s proved that leadership is an essential strategy in order to drive communities (teams are small communities).
    where to drive it? well…that is answered depending on what leader you put on that community.
    but imagining a team without a leader holds with it all the chaotic attributes something can be described of.

    my end point is that you can have the beauty of the two worlds by putting a knowledgable (and thats not in technology only) and smart leader who can get the best out of his team, by helping them, supporting them, GUIDING them (not forcing them)…etc
    we are providing solutions to the wrong causes

  • Simon Baker

    Good post. Further to your first point about decision making latency: The latency is proportional to the distance the decision maker is away from the point where the decision is needed. This is often far away from the coal face (hierarchically, geographically, or both).

    There are knock-on problems: Small decisions aren’t possible because the latency is too great – you’ll spend all your time waiting around. And because decisions are bigger than they need to be, they aren’t easily reversible. (If you try to reverse them you have to traverse the hierarchy again adding more latency). Which means it’s more difficult to fail fast, learn, and try something else.

    Self-organisation only works if people are (and importantly feel that they are) empowered to make decisions, own the necessary authority, are prepared to be responsible and hold one another accountable to their commitments.

  • Brian Button

    I posted something kind of like this a couple of months back about the hardest part of being an agile manager. See

  • Chad Myers

    I work in a highly C&C environment (by its very nature) and unfortunately there’s no changing it — so I’ve had a lot of time to think about this very subject. I’ve boiled it down to this:

    If you want to be really successful, hire talented, smart people and enable them to be talented, smart people. If you have to impose restrictions and process to prevent errors from happening, it’s usually to compensate for a weak or uncooperative member of the team.

    Unfortunately, in many circumstances, process and security restrictions are unavoidable: a.) Government work in general, b.) SOX requirements c.) HIPPA (or other various medical-privacy-related regulations).

    It has been my experience (not that that counts for much) that it is darn near impossible to do any sort of agile-type development in this kind of environment. Waterfall is almost completely inherent and required in the system (even though, not surprisingly, it’s even less successful than in other ‘normal’ waterfall scenarios).

    It seems that some sort of iteration is inevitable no matter which ‘methodology’ you choose or is hoisted on you and the more process you have in place, the more difficult and painful this iteration is (and the more frustrated everyone gets).

    The only way I’ve found to work in this type of environment is to have one really Smart Person(tm) (though I’ll settle for a Knowledgeable Person(tm) when it is the only alternative) from each interest group and keep these people very close so that the turn around time for the red-tape is kept to a minimum.

  • jmiller

    @Ian, Fine be that way. Boil the salient point of this post down to “Dictator bad”

    @Joe, Go write your post 😉


    Here’s his post –

  • Erik

    There’s actually an interesting read on this, a book titled “Creating Leaderful Organizations” that I recommend. It’s an interesting idea which I happened to post about myself a while back. Always good for stirring up a debate.

  • AgileJoe

    I can personally attest to the success of self-organizing teams (organic). I manage a team of 15 developers all with varying skill sets and I am a true believer that the collective consciousness of many is far more powerful then the individuality of task based assignment. The most important aspect of successfully managing a team of developers is easy.

    1. You have to be a developer yourself. If you don’t know how to code don’t manage developers period!!!! And knowing COBOL doesn’t count!

    2. You have to manage the team not the individuals. Think of yourself more as a coach not a manager. Maximize your assets by understanding your team’s weakness and strengths.

    3. If you have mediocre programmers (first off yikes!) second as long as they show a willingness to learn, paired programming is the key to success for bringing the juniors up to par with the seniors.

    4. Empowerment, allow EVERYONE to take ownership of stories and task. If a junior wants it let him/her role with it. Your TDD practices along with the pressure from their peers will make certain it is done correctly. Ever fumbled the ball playing football? I am sure your team wasn’t too happy with you and you made certain not to do it again.

    5. Embrace the fact that your team need to understand their goals! What they are playing for? What is the goal for the week (Velocity, Stories)?

    6. They need a way to measure and understand if it is 1 and 10 or 4 and 20? Information radiators coupled with a good agile project management tool such as Target Process, RallyDev or even XPlanner can help with this.

    7. Coach them every day! Think of your standup as halftime. If they are behind you need to pep them up help them understand the why the defense is getting beat or why the offence can’t score. If they are ahead you need to continue with the positive motivation.

    8. Get rid of your heroes!!!! You know who they are the ones that always want the ball who yell at the other players for not doing what they want. They are a cancer and must be removed.

    I can go on…I smell a post coming
    Joe Ocampo

  • SteveJ

    Scott – Agreed. You either have invested wisely in some people that you can trust to do their jobs or you’re wasting your money. It’s no different than anything else.

    WayneMack – “A central leader can overcome this tendency by steering some of the more challenging work to the meeker members and ensuring the more outspoken do their share of the boring tasks.”

    I’m sorry, I’ve never seen this work. The busier/productive the leader, the more likely he/she will let inertia carry everyone forward. After all it’s working, right? It’s just like coaching kids sports teams, you decide Jimmy can catch, and that’s all he’ll ever do. You don’t take your #1 QB and teach him to kick field goals.

    On the other hand if you have a good team of people you’ve invested wisely in (ie not wasting money, and thus competent enough to enjoy customers) then that team tends to be self-correcting. If I see Joe has done UI work for the last 3 years, I’m more likely to see if he wants to take one of “my” device driver tasks. As a team member, I’m more open to people trying new things because it’s not directly my fault if the team falters for a couple days, unlike the “Commander” who will be criticized if output appears to drop for a week.

    That said, there has to be a leader. No doubt about it. You stick 5 developers in a room and withold pizza until they come up with a decision and someone’s going to die. We definitely need nudging and a final authority to appeal to.

  • Carlton Nettleton

    I never can figure this out – if you have mediocre developers, why do people never invest any time and money to make them better?

  • ScottBellware

    > The list of cited assertions will be true only when
    > developers (talking only on software) are very
    > (but very very) good developers.

    Were we trying to take on something as failure-prone and complex as a software project with mediocre developers? Hmm… never really thought of arbitrarilly putting so much at risk. Interesting approach. Kinda like letting the lunatics run the asylum. Makes for good headlines.

  • WayneMack

    As Ian notes above, I think it is a matter for finding an appropriate balance based upon the individuals and the situation. As Jeremy notes that are good things that can possibly happen with a self organizing team and bad things that can happen with central leadership. To be fair, however, there are also some bad things possible with a self organizing team and good possibilities with a central leader.

    Lacking a central leader, a self organizing team can generate a power struggle as members try to take on decision making authority. The group can split into two competing groups. Though a central leader cannot prevent this type of group dynamic, he can take steps to minimize its effects.

    Meeker team members and those with less confidence can end up doing most of the menial tasks while the more interesting tasks go to the more aggressive and more self confident. A central leader can overcome this tendency by steering some of the more challenging work to the meeker members and ensuring the more outspoken do their share of the boring tasks.

    It is easier for someone to carve out a role on a self directed team and stagnate. It is useful at times to have a central leader who can push someone in a new direction.

    I am not in favor of a completely self directed team, but neither do I favor having an absolute leader who makes all decisions. I feel the ideal is a leader with a light touch who is able to adjust his style based on the situations and personnel on the team.

  • jpalermo

    > It seems clear that the author of the post is very fond of the wonderful utopia-fully world things.

    It’s not clear. Can you explain why?

    >How many developers are able to take right decisions based on overall business criteria
    >such as sales priorities, customer’s actual needs, marketing intentions, productivity

    Not many. Certainly not me, but that’s not the developer role. That’s the product owner (or “customer”) role. As a developer, it’s not up to me how to balance sales priorities with marketing, etc. That is a very tough job indeed, and if the software team is tasked with that, it’s poorly managed (or a company of 1). Rather, a healthy software team will have qualified people manning all necessary roles.

    >Different responsabilities must be distributed among different people with different profiles

    You have it correct here, so I’m confused about your meaning in the previous paragraph.

    In my last engagement, I trained a product manager who had never done that job before (had never been involved with software). If was tricky at first giving up control of the roadmap priority (I was in a management position on the team), but as a company we made it his responsibility to weigh all business factors to have the roadmap prioritized and clarified. It took a few weeks, but in the end, we decentralized control, and the team sped up considerably.

  • Ian Horwill

    I don’t think it’s necessarily an either/or situation. What you’re describing sounds awfully like a committee. I believe you need individuals responsible for teams (and, looking higher up the organization chart, departments etc.). However, the good points that you describe only get killed off if you set up a dictatorship. Any half-decent leader will encourage contribution from the team, who will recognize when good decisions are made given the circumstances (which they are made aware of).

  • FHierro

    It seems clear that the author of the post is very fond of the wonderful utopia-fully world things.

    The list of cited assertions will be true only when developers (talking only on software) are very (but very very) good developers.

    How many developers are able to take right decisions based on overall business criteria such as sales priorities, customer’s actual needs, marketing intentions, productivity optimization, … as well as decisions related to its main responsability such as maintenable designs, suitable usage of patterns, good user interfaces, code optimization, etc, etc, etc ???

    Only a few …

    Different responsabilities must be distributed among different people with different profiles, experience and background and, belive it or not, it is also demonstrated to be “better” (not the best !!).