A frequent Red Canary contributor, Craig Fitzpatrick is the CEO of Devshop. This entry was borrowed from his blog, Uncommon Sense (for Software).

Software projects are different from other kinds of projects. I believe that while general purpose project management theory gives a good grounding in basic project management, it’s not enough to be a successful software manager.

Software development is regarded by some as the most complex intellectual activity known to man. The model of “command and control”, where there is a single “boss” who makes the majority of the decisions and hands them down to the “doers” doesn’t work for software projects.

The reason? The balance of the knowledge required to make so many of the decisions lies with the individual developers that are far closer to the implementation (the code) than the manager will ever be. Even more importantly, no single developer has a complete view of the system. Any good sized system has a team of developers working on it. Some were there from the beginning, some are new to the project and all have varying levels of knowledge of their own little pieces of the whole.

The role of a manager in the software world is:

1) The coach
2) The liaison to the outside world
3) The tie-breaker (in the case of disagreements amongst the team)
4) The one who holds the “whole” vision, freeing others to specialize in certain parts

What’s a manager to do when the knowledge and experience required to make the bulk of the decisions rests with several different people on the team? How do you hold people accountable for work that you do not yourself understand? (If you’ve never spent years coding hands-on for yourself, please do not try to convince anyone that you understand software development. You don’t.)

The answer is that it’s actually the “team” that really needs to manage the project. The manager facilitates the team in doing that. For a working example of the team managing a process, consider the popular process of design and code reviews. It would appear that “management by the team” has snuck it’s way into our lives, without us necessarily noticing it…

The design review process was developed to make sure that there was a consistent level of quality in the sub-systems that were being introduced into a larger system. Also, that the team at large would be initiated to this sub-system before it was introduced, for familiarity’s sake. And finally, that the team could bring their knowledge of other related sub-systems to the table, to make sure that this new sub-system wasn’t going to break anything else.

The way it works is that the developer of a new sub-system does the design on paper and brings it before the team for critique and discussion. The team is allowed to make suggestions and the author (designer) takes them away and brings the revised design back to the team for approval.

In most cases, the original designer has final say about the suggestions the team makes, unless there’s something particularly controversial, in which case it gets kicked up to a manager or team lead for a tie-breaker. This process is done before any significant code is written, since it’s much easier to change diagrams and text than it is to change code. Whether your requirements for the design came from the ARD (Almighty Requirements Document) or a user story, doesn’t really matter.

This process works really well. Most of the developers I know that use it, swear by it. Interestingly enough, although it resembles a “committee” (a dirty, dirty word), design reviews seem to happen without any large amounts of friction or politics and can be done without introducing significant delays in throughput.

Developers are usually a pretty pragmatic bunch and genuinely do want to produce the best designs and code possible (they are on a never ending quest for the most elegant solution to a problem, regardless of who’s idea it was). In almost all cases, I’ve seen the original designers take enough criticism to send your average person crying and happily go about adjusting their designs, ready to come back for another round. Everyone knows that the process is for the greater good, and developers usually love it when someone else spots a possible hole or problem that they missed (saves them work fixing it later!).

This is essentially a peer review process. It means that for design (which is critical), nothing gets implemented without the support of the team. It means that the whole team is aware of what’s going on and gets a broader view of the entire application.

From a group dynamic perspective, another interesting thing to note is that instead of say, 9 developers pointed at their boss for approval, each of the 9 developers is looking to the other 8 (or some designated sub-set) for approval. That’s what I call healthy peer pressure. Developers take pride in their designs and their code. Who wants to look dumb in front of their peers? Or sloppy? Who wants the team to think that one of them could have designed it better?

When you know you’re presenting your work to peers who are actually capable of critiquing you on a detailed level (versus presenting your work to a boss who’s never coded or doesn’t know the details of the implementation), you take great care before you step into the room, designs in hand.

What’s really going on in the design review process (or code review, after the design is implemented but before the code is considered “complete”), is that the team is truly collaborating. They are discussing, critiquing and learning about parts of the system that they themselves are not directly on the hook for. Each sub-system gets the benefit of the whole team’s knowledge, for not a lot of extra overhead. Mistakes are caught, risks avoided, conflicts resolved before the expensive (time and money) part begins – the coding.

I believe that there are many more “management” activities that can benefit from this dynamic, in software projects. What about reviewing time estimates as a team? Schedule? Priorities? Risks? Bugs?

I believe that having each person not only accountable to the “boss”, but instead to each other, creates a whole new level of performance. We often like to speak rhetoric like, “we’re a team and we depend on each other to be successful”, but often don’t act accordingly. Many of our processes still reflect a bunch of worker bees being held accountable by a single boss-like entity.

Take this peer review process far enough and it could beg the question, “Who’s managing this project anyway?” Answer: the team.