No Organizational Charts in Agile?

Most companies use a traditional pyramidal structure, i.e. boss at the top, next in command on the line below, their underlings on the next level. John McKee asserts that this structure probably started about 5,000 BC with the Sumerian civilization. After they crashed, it was picked up by subsequent generations of leaders — next being the Egyptians about 2,000 BC. It has existed, more or less, in the same style since then.

Given how successful this reporting and management structure was for all the past civilizations, I am not inclined to recommend it to anyone.

There are tons of management studies that support the reasons for not using a structure like this. Key issues include

  1. They are always out of date
  2. They don’t deal with how things “really” get done
  3. They distance company leadership from the important work of the organization


They work when the boss is involved. And, if he or she isn’t involved, they show that the leader is not up to the task and should be replaced.

It’s not simply for small companies. The critical factor — that the boss is never more than one step away from the person who’s doing things – can be modified for even the biggest companies.

Flat organizations work because

  1. Decisions are made faster
  2. Money is spent according to the priorities of the company
  3. There’s less culture clash internally with fiefdoms being created by each department head

Agile or not? Do org charts have their place?

[HT: Tech Republic]

12 Replies to “No Organizational Charts in Agile?”

  1. Is the question really whether an org chart is meaningful for an Agile effort or is it whether a hierarchical structure is an appropriate one?

    If you have teams that satay a together, then that permanence can be represented in a chart of some kind, right?

  2. Org chart or hierarchic is not a bad concept as it is. I think conflict resolution is one place where a clear line of authority makes lives easier.

    The problem comes with rigidity and lack of communication flow.
    Also that important information always tends to flow from the top down also creates problems of context and agility.

    Hence instead of banishing hierarchy, lets think of how to make empowerment within hierarchy and developing communication channels.

  3. Pingback: No Organizational Charts in Agile? | Agile | Syngu
  4. Sounds like an interesting idea. I’ve thought about things like this fairly often while trying to grow the software development group at a small company…what would be the best way to structure the organization. I see many articles like this, but very few that actually give some recommendations. Does anyone have any recommendations on how to structure the organization in light of this?

  5. OMG. I can’t believe I’m reading this!

    I’m sorry but I have to wonder if the author has ever worked in a real “for-profit” organization. The traditional hierarchical structure isn’t perfect – that I can buy – but a flat structure… Really?

    There is a reason why Scrum (among other things) recommends a team of 5 to 9 people. Can you imagine be an effective manager for more than 10 people?

    You may be interested in reading this:
    Hierarchies aren’t evil but people can be:
    Agile managers do not act like cowboys:

    1. lattice organizations as made famous by Gore Associates .These structures are flat and work quite well.

      I think the author means organizational flatness but not feature team increase in size. They could be related but don’t have to be

      As I said before, hierarchy is not bad infact can be useful. But is it required as a rule? No, other structures are also possible

Leave a Reply