Most smaller and larger organizations are stuffed with folks holding the title “project manager”. For starters: These jobs are probably the most essential jobs any company has. If your engineers aren’t good, you sure have erroneous code, but persistence will fix the issues. If your marketing folks aren’t good you sure will have a difficult time getting the message out, but a bit of external help will make up leeway. If management is no good, the board hopefully fixes this issue quickly. Yet if a project manager fails you’re in deep trouble. Why? She’s the one that holds together the strings of a project (1). If she’s good, things – aka projects – just happen. In case he holds the strings together poorly, the project will most likely end up an utter failure.

Yet, most organizations have way too many project managers on their payroll doing way too many futile things. This report, that chart, lots of meetings, more E-Mail. Their bottom line contribution: Zero, worse, probably negative.

Why? Let me explain.

Most organizations are led by business people (as opposed to engineers). Both groups tend to mingle mostly among like-minded people. It’s simply easier to find a common language. As a consequence business people tend to hire business people, i.e. ‘project managers’. And as most organizations have always lots of things to accomplish (not least to satisfy the egos of some higher ups), a lot of project managers get hired.

The outcome: an oversupply of project management folks. At the same time the number of engineers stays mostly the same (You know, focus on costs and headcount and all that…).

The result is an oversupply of project management resources compared to engineering resources. The following figure illustrates this point: disk A denotes the available project management resources. These generate a equally sized demand for engineering resources (this being the maximum load this project manager team is able to handle in terms of projects, tasks and workloads). Disk B represents the available engineering resources.

The effect is a significant oversupply of A versus B. In a market economy there are two possible solutions to this imbalance. Price and or quantities available in the market space will adapt until the market clears.

Unfortunately this is not the free market but the rather closed compound of a firm. So what will happen?

Each project manager has been given a specific set of goals. Yet the available engineering resources will not match the combined demand by all project mangers. The consequence is fierce political infighting over scarce resources (2). People start to focus on internal politics instead of external product value for your customer.

First observation: Too many project managers ensure internal feuding instead of external customer focus.

We tried to avoid such a situation at local.ch. We basically never employed a project manager. How did we do it

• In a team of 32 (3) of which 22 were engineers, we had two engineering directors. Their task was to ensure a smooth engineering operation. On the one hand they were the prime interlocutors for the business people with their requirements. Second, they were responsible for the overall engineering direction. This did involve only a minimal part of day-to-day project management.  
• As outlined in the previous post, we split the local.ch platform into several building blocks and assigned a team and team lead to each block (we had a frontend, a backend, a classifieds, a guide, a mobile, a mapping, a product, a sysadmin team, though a couple of people were in several teams).
• Each team was responsible for its own objectives, tasks and their timely execution. Each team was tasked to ensure that its individual plans would not collide with the plans of adjacent teams and their respective release plans.  
• We met every Thursday to commonly elaborate and agree the main release goals. We started with a general update on the progress of the entire platform, followed by a coordination meeting attended by all team leads plus whoever had an issue to raise. Once this overall release plan was agreed to, we delegated everything else to the teams. We tried hard to limit these Thursday discussions to the most top level items only, delegating all subsequent detail discussions and decision making to the parties directly involved. When I say “tried hard”: we tried to stay focused, but sometimes fell short (4). But who doesn’t occasionally?
• We relied extensively on agile development methods. More on that in the next post.

The result – with all shortcomings – were very dedicated teams. They rose to their responsibilities and started to own the issues. They took pride in getting things done quickly, efficiently and effectively without much management. Things just happened. And they happened quickly: In the frontend team we were on nearly a daily release cycles, in the backend team they were not far behind.

Second observation: true responsibility is a powerful motivator.

The basic recipe is a transparent split of building blocks and assigned responsibilities. Plus maximum delegation of decision-making combined with a set a set of simple and commonly shared ground rules. And then get out of the way and let excellent people do their job.

Next in the series how to build a scalable startup: Scrum.

_______ 

(1) For proponents of the Spider versus Starfish theme: Even a pretty self-organizing team, will need some time to re-calibrate if you take out the team leader.  

(2) There is another solution though: Reduce the number of project managers up to below available engineering resources. But then again, who wants to cut those project roadmaps to size?

(3) Of these 35 colleagues, 25 were on the local.ch payroll, long-term partner companies employed 7.

(4) For readers from local.ch and friends: I know, we all did live up to this better pre-Amundsen. For all other readers: Contact me for details.