Fog Creek Software
Discussion Board

Hierarchical or flat project management?

I was subjected to an HR video once where a comment was made that some people prefer a hierarchical arrangement, while others prefer a flat cooperative setup. The speaker in the video stressed that there was no "right" way, and we should respect each mode of operation.

I disagree. I think a project with a *totally* flat structure (no leadership) is doomed to failure. I also think that *too* strict a hierarchy, while it may succeed, is going to create more problems than it solves.

In my experience, with smaller (<20) teams, the best approach is one decisive leadership figure who is willing to "own" the project, make decisions, and go to bat for the team; the rest of the project can be relatively flat, but recognition of experience should be encouraged.

As any subgroup gets larger than 5ish people, then that subgroup should have one person put in charge - again, to make decisions and filter info for the project leader.

I was prompted to make this point when I was reading the Python project page - Python has a single person in charge. This made me think - Linus, Larry Wall, Jobs, Gates - the most successful enterprises have *always* had a single strong will driving.



Sunday, August 17, 2003

Python is not the perfect example for your observation. There is Python Labs, and a bunch of "steering commitees", but the reason Guido van Rossum does all the hard decisions on his own is not that he's actively pulling them to his desk, but rather the lack of experience, especially real-world experience, the others in the Python commitees show. In a recent interview over at O'Reillys Guido was kind of whining about the geekiness of his team mates. I believe the other decision makers you mentioned do have quite a different personality, and really see their organizations/projects as their own "babies".

But generally, I'd agree - as Brooks had already pointed out that you need one surgeon in your team, while the rest has a mere assistant status.

Johnny Bravo
Sunday, August 17, 2003

The structure of any team should be primarily decided about what the team is supposed to accomplish.  There is no single best way.  In an environment of very high levels of uncertainty, for instance, a committee-style team where decisions are made by consensus can go a long way towards reducing risk.  Similarly, when speed is king, have a central decision making authority can really accelerate things.

Many places that I've worked in the last ten years or so tend to build "matrixed" teams.  This is the most laughable abuse of team structure of them all.  Ostensibly, it tries to build a team with the best properties of a functional team and a cross-functional team.  In reality, though, it's usually the worst features of these two that a matrixed team exhibits.

If you really want to build the best team for achieving a certain goal, you have to spend the calories to do it right.  That means not adopting the "one-size fits all" solution - it fits no one very well.  You have to plan a solid team structure, a good process, and a great product.  Without this, you can expect only mediocrity.

So let it be written; so let it be done.

Sunday, August 17, 2003

I prefer a hierarchical arrangement. I have worked in places that are totally flat, and in those cases, no one took responsibility. I think this says a lot.

James Ladd
Sunday, August 17, 2003

"In an environment of very high levels of uncertainty, for instance, a committee-style team where decisions are made by consensus can go a long way towards reducing risk"

Because so few decisions actually get made? (or as a friend once said: "Indecision is the key to flexibility")

Sorry, had to be said. [g]


Sunday, August 17, 2003

I agree, our organization had much better results when our leader had a vision that we all worked on. Some people hated his "just do it this way, trust me" approach, but overall we got much more done than now where everybody is told to "use your best judgment". Granted, there are many factors that affect success.

My Econ Professor told me, Monarchies are the ultimate form of government. If you don't like things, there is just one person to get rid of.  :)

Sunday, August 17, 2003

The best development groups I've worked in were run sort of like an NBA basketball team. There were less than 6 developers who were all super good, then there was a project manager who was a former developer and acted as a "coach", ensuring that the team actually was working towards a goal. I'd like to point out that in these situations  we were working on "products" vs. "systems." And, everyone in the group thought the product was "cool." And, the programmers often were contributing feature ideas whilst developing the product. Eg: "yeah well we need feature X, but check this out, if we add g to feature X, we get Xg and that's way cooler than just X alone!" Then the PM would either agree or say "just focus on getting X out the door by next friday" etc.

I think the heirarchical management style does work for very IT/Systems style projects. By this I mean something like a course management system for a university, or a billing system, or a medical records management system. At risk of offending people, I've worked on a few of these projects and really hated it. There isn't really anything cool or interesting about these systems, so it is really hard to get motivated.Therefore having a lot of hierarchy makes everything seem more efficient and you don't have to think about the fact that you are just working on a giant data processing system.

The one project like this I worked on during college to pay the bills worked the best when I was just joe coder and reported to a manager who basically just gave me a list of stuff to do. I could just work down the list and then leave. The other project like this i worked on when my cool product company caved in was a nightmare, because there was not very much management, and I had to think of tasks myself to finish, and when I thought about it, I wanted to die, because i'm thinking "oh my god i'm working at an insurance company." Anyway, this is rambling but my point is:

flat hierarchy with coach/PM = good for product development

multi tiered hierarchy with many different levels = good for huge, boring, systems engineering type projects

Sunday, August 17, 2003

See  "Constantine on Peopleware" Larry Constantine, 1995 for really good discussion of factors and alternatives in team organization.

Ideal team structure depends a lot on the type of problem and the people involved. The higher the skill level and the more experience as a team,  then consensus "Brainstorming" teams work better, especially with less well-defined problems. Known problem, variety in skill levels and less experience working together, but skilled leader: hierarchical.

For many projects - most of the people have never worked together before, they are using at least one new tool/technology, most if not all are new to the problem domain - you better hope there is someone who can drive it in a hierarchical fashion (and is empowered to do so). The lack of such people and the resulting degradation to consensus management is the short road to a long, drawn-out failure, IME. I think this is why people express a preference for hierarchical teams - it presumes someone strong enough to drive and the presence of such a person is a key determinant for success.

Jim S.
Sunday, August 17, 2003

I'd agree that any enterprise or project is going to benefit when there is someone that takes charge and pushes towards well defined goals.

It isn't necessarily always the same person though.

The most effective teams I've been in and led have had a more organic reaction to the process.  The one most likely to could step forward at the appropriate point and say 'I think this, or that' and the team would coalesce around that decision.

However, it still needs someone at the head of the whole project to manage that and to both be alive to others experience and when to let them have their head and when to make a tree pruning decision.

Simon Lucy
Monday, August 18, 2003

at the risk of being flamed... how does it work at companies which are CMM certified?

Prakash S
Monday, August 18, 2003

"Because so few decisions actually get made? (or as a friend once said: "Indecision is the key to flexibility")"

Well said ;)

I won't argue that consensus oriented teams make efficient decisions - in general, they do not.  They don't even always make the best decisions, in the real world.  I hope no one took that as the point I was trying to make.

Hierarchical systems suffer from the same problems as any other centralized system.  The decision making node represents a single point of failure.  If a bad decision is made here, it will affect the entire organization.  On the other hand, this kind of organization offers the same kinds of benefits as other centralized systems - speed and focus.

The point I wanted to stress is not so much that one approach is better than the other but that they offer different benefits and liabilities.  The constraints of the problem you are trying to solve needs to dictate your approach in exactly the same way that your problem space dictates your approach to a solution when you are designing information systems.  There is no best, one-size-fits-all solution, and management by checklist is no replacement for using your mind to think things through.

Monday, August 18, 2003

I think one real big problem project teams face is "idea lock-in" (to borrow from another thread) - the inability to admit that an early assumption or decision was wrong.

With a hierarchical structure, the problem is that the leader gets his/her ego confused with the issue - challenging the decision becomes challenging the leader. A good leader will be able to get past this.

With a flat/consensus model, the danger is that "might makes right" or "everyone is lost but me" syndrome. Here, since eight people came to a conclusion, then gosh darnit, it must be the right thing to do, right?

Again, a strong group needs to be able to get past their assumptions and do the right thing in the light of new ideas or evidence.


Monday, August 18, 2003

A strong leadership is a must. There should be at least a business leader and technical leader. In large projects leadership can be developed by field-specific persons, like leading designer/architector, system/network engineer and so on.

Evgeny Gesin /Javadesk/
Monday, August 18, 2003

Have you ever read "Mythical Man-Month" ?

Tuesday, August 19, 2003

A leader is needed to have any team be productive and heading down the correct path.  Totally flat teams (AKA self-managed teams) only work if someone takes the responsibility for decisions at some point in time.

Too steep a hierarchy usually results in no real leadership, just a bunch of people telling other people what to do. 

Somewhere in the middle is more workable.

Joe AA
Tuesday, August 19, 2003

*  Recent Topics

*  Fog Creek Home