I hear the question of whether a project needs a manager regularly, and it almost always sounds hopeful. A client looks at the budget, sees the line "project management" and thinks: maybe we can do without it? The programmers understand everything themselves, tasks can be given to them directly, and I can run the calls myself. We'll save fifteen percent and live happily ever after.
The honest answer: yes, profitable projects without a dedicated manager exist. I have taken part in several. But that "yes" comes with a very important "but", and that "but" is the whole point of this article.
A jazz quartet and a symphony orchestra
A jazz quartet plays beautifully without a conductor. Four musicians hear each other, exchange glances, improvise, and music happens. Nobody waves a baton, but that does not mean there is no conducting. It is there, just distributed among everyone: the saxophonist nods to show his solo is coming, the drummer keeps the tempo, the pianist signals the ending. The conductor's function has not disappeared, it has dissolved into the musicians.
Now put a symphony orchestra of eighty people on stage without a conductor. The violins cannot hear the horns, the timpani come in a bar early, and within a minute a beautiful score turns into noise. The musicians may be the best in the world. The problem is not skill but coordination.
Projects work exactly the same way. A small team of highly motivated professionals can work without a separate manager because the manager's role is "spread" across all members. But spread does not mean absent. Someone still talks to the client, someone watches the deadlines, someone decides what matters more today. It is just done by the same people who write the code.
What a manager actually does
Many people think a project manager is someone who assigns tasks and asks "so, is it done?". If that were true, he really could be replaced with a calendar reminder. But a manager's real work consists of things that are invisible while being done and very noticeable when they stop being done.
- Translates the client's language into the team's language and back. The client says "I want it to be convenient", the programmer hears "we need to redo the architecture", the manager finds out that what is really needed is one button.
- Shields the team from chaos. The client sends five ideas a day, and if all of them go straight to the programmers, work does not move at all.
- Watches money and deadlines. Not at the end of the project, but every week, while the deviation is still small.
- Sees risks before they become problems.
- Keeps business priorities in focus when the team gets carried away with a technically interesting but useless task.
If someone on your team does all of this, well and with pleasure, you may really not need a separate manager. If nobody does it, you have not saved on a manager. You have simply stopped managing the project.
When it works without a manager
In my experience, a project without a dedicated manager can be profitable when several conditions come together. The team is small, up to four or five people. They are experienced and have worked together before, so they do not need to agree on basics. One of them, usually the lead developer or architect, takes on communication with the client and enjoys it. The client understands what he wants and can put it into words. The scope is clear and does not change every week.
Notice how many "ifs" there are in that list. It is like driving without a navigator: easy in your home town, possible in a foreign country, but with adventures.
When it is dangerous
Three risks I see most often when the manager is removed to save money.
The first: chaos in communication with the client. The client writes to three developers at once, each understands something different, different promises are made, and a month later the client is sure he was promised one thing and given another. And by the way, he will be right.
The second: losing focus on business priorities. Programmers left without an outside focus tend to do what is technically interesting. A beautiful architecture, a perfect refactoring, a trendy library. All of it may be correct, just not when the client has to launch sales in two weeks.
The third: going over budget. Without someone comparing plan and actual every week, overspending piles up unnoticed. Every task takes "a little longer", and in total the project turns out a third more expensive. The fifteen percent saved on the manager is eaten up by the middle of the project.
The middle way
At Ingello we often use a hybrid scheme. On small projects the manager's role is taken by the architect, who already understands the system and the client's business better than anyone. Tools help him: a shared tracker, automatic reports on deadlines and budget, a clear acceptance process. The routine that a person used to do (reminders, summaries, collecting statuses) is done by bots. And part of the work that used to require long negotiations we remove with a formal description of the system through Fractal: when the data and screen schemas are described in advance, there is much less to argue about.
This does not cancel management. It shrinks it down to what really requires human judgement.
A practitioner's conclusion
If you are wondering whether to remove the manager from a project, ask yourself one question: who exactly will do his job? Not "someone will figure it out", but a specific name. If there is such a name and that person is willing and able, go ahead. If there is no name, you are not saving money, you are taking out a loan that you will repay with interest in the form of rework, missed deadlines and damaged client relationships.
A quartet can play without a conductor. But only if every musician in it is a bit of a conductor.
