You can’t wear the manager and developer hats at the same time Paul Glen

Here’s something that never works out well: A small project comes along, one that doesn’t necessarily need a full-time project manager. So it’s decided that one of the developers on the project can double as the project manager. After all, who better understands what needs to be done than the developer?
That’s true, and many developers do make good project managers. There’s no inherent conflict between the type of person who makes a good developer and one who makes a good project manager. They’re both detail-oriented and results-driven. But it’s simply not possible to be a good developer and a good project manager simultaneously.

To understand the incompatibility, you have to think about the types of things developers and project managers are called on to do.

Developing software is like living in a dream state. To be productive, you have to enter an entirely symbolic world, where you manipulate algorithms and variables, foresee flows and contingencies, test out ideas, and follow intricate threads of thought. Working in this sort of world requires long periods of uninterrupted concentration. Whenever you’re interrupted, you lose your train of thought. And after the interruption is over, it can take time to return where you were before the interruption began 15 minutes or so if you’re lucky, but maybe not until the next day.

In other words, the cost of task-switching during software development is very high.

Project management demands an entirely different mindset and work style. Instead of living in a dream state, project managers need to be intimately and immediately connected to the facts, emotions, and politics of their environment. Project managers don’t just create abstract project plans and track progress against a theoretical construct. Their job is to coordinate the activity of numerous people, understanding what progress they make, what obstacles they face, what resources they need, and how each individual’s work affects the productivity of others. In other words, their work is almost entirely interruption-driven. They need to be available at all times to handle crises, prevent problems, and communicate with an entire community of stakeholders.

There’s simply no way to reconcile these two diametrically opposed work styles. If you ask someone to be both a project manager and a developer, he will have to choose one as his primary work mode over the other. He may choose to be a developer first and a project manager second, but then he will be largely unavailable to the project team and external stakeholders, and the entire project will suffer from lack of leadership. Or he may choose to be a project manager first and a developer second. But then the development tasks he assigns himself are unlikely to be completed on time or be well constructed.

So if you want to improve project productivity, set this common temptation aside. Choosing a developer to serve as a project manager can impair the productivity of the project, and it’s cruel to the developer because you’re asking that person to do the impossible.

(Paul Glen is the co-author of The Geek Leader’s Handbook and a principal of Leading Geeks, an education and consulting firm devoted to clarifying the murky world of human emotion for people who gravitate toward concrete thinking. Reach him via: info@leadinggeeks.com).