The task was delivered on Friday. On Monday the client opens the result and says: this isn't it. Formally there is nothing to fault. The developer built exactly what the message from the twelfth said. But between the twelfth and that Friday, the commercial director asked in another chat for a way to filter products by warehouse, and accounting sent a separate email clarifying that prices must be shown both with and without VAT. Nobody forgot anything and nobody cut corners. Those three conversations simply never met.
What follows is a week of rework, paid for either by the client or by the contractor out of its own margin. The person whose job is to bring such conversations into one place is called a project manager. They don't write code and they don't draw mockups. Here is what they get paid for, and when you can honestly do without one.
Why this line is the first to be cut from the estimate
The budgeting logic is simple: we pay for what we can touch. A developer hands over a working website, a designer hands over pictures of the future pages, a tester brings a list of bugs. A manager hands over nothing you can open and look at, so the "project management" line, usually 10–15% of the estimate, is the first one clients ask to remove. The second argument is more convincing: the team is small, everyone is in touch, we'll sort things out directly. And that's true, as long as the project has one client, one developer, and one task.
The third reason is confusion about what this person actually does. The role has a reputation as the one who collects progress reports and reminds people about deadlines. Seen that way, there is nothing to pay for: a developer can report on their own work, and a calendar does the reminding.
What the role actually carries
The useful part of a manager's work isn't oversight. A manager holds four things that otherwise nobody holds.
The boundaries of the task. What is included, what isn't, and how we will know the work is done. This gets written down before the start, not worked out at handover. "Add a warehouse filter" and "add a warehouse filter that accounts for stock set aside for unpaid orders" are jobs of different sizes. The difference will surface either at the start, in a half-hour conversation, or at the end, in a week of rework.
The task queue. A business always has more wishes than development hours, and they come from different offices. There has to be one place where those requests are put into a single ordered list. Otherwise the queue is set by whoever wrote last and loudest.
Other people's promises. The server passwords are still with the previous contractor, the data is being prepared by the client's specialist in 1C (Russia's leading ERP and accounting platform), accounting is paying for the certificate, the lawyer is reviewing the contract. A developer who runs into a wait like that just sits idle, and from the outside it looks like "they're slow."
Translation from one language to the other. The business says "the stock doesn't add up." The developer hears "the site and 1C show different numbers." Someone has to understand both languages and put the clarifying questions to both sides.
This shows most where a website exchanges data with 1C. The client has its own specialist, a contractor builds the site, and questions hang between them: in what form to pass the data, how often, who answers for discrepancies. There is a technical solution here, and we use it, but you still have to reach an agreement with the people on the other side. Software doesn't do the negotiating.
Where the time goes when nobody fills the role
Hours don't vanish all at once. They leak through four channels.
The first is waiting. A developer hits a question like "what price do we show if the item is out of stock and available to order," and posts it in the group chat. The answer arrives a day later: the person who knew it was on vacation, and the others didn't realize the question was meant for them.
The second is switching between jobs. A developer who handles the correspondence personally spends the whole day jumping between two occupations: figuring out the software and figuring out the people. After every conversation it takes time to get back into the task.
The third is rework, the most expensive channel, because you pay for it twice. First for the work that was done wrong, then for the same work done right.
The fourth is the wrong order of work: a polished customer account area gets built first, and then it turns out the accounting system sends too little data and there is nothing to show in it.
It's easier to count in hours: rates differ from one company to the next, but the ratio is roughly the same everywhere. Take a team of three developers and estimate how much time each one spends on messages, clarifications, and calls. It usually comes to about an hour a day. That's fifteen hours a week, almost two full working days, paid at a developer's rate. Meanwhile an hour from a specialist whose main job is communication costs two to three times less. The conversations won't disappear entirely, but the second bill does: the one for rework, which doesn't arise when the terms for accepting the work are written down in advance.
What happens to quality
Quality here doesn't mean the number of bugs in the software. A tester catches breakages but not the main disaster of a project: it was built carefully, it runs properly, and something else entirely was needed. That mistake is born at the very beginning, when the task was understood in someone's own way, and it surfaces at handover.
The second layer is the knock-on effects in neighboring places. In a large online store, say 400,000 products and 4,000 visitors a day, a harmless tweak to the price calculation travels beyond the site itself: into the product files that go to marketplaces, into catalog search, into reports. The developer keeps their own area in mind. Someone has to keep the whole picture and ask "what happens to the exports" before the change goes live.
The third layer is predictability. When it's known what will be ready and when, the business can prepare for the season, launch advertising, train its sales staff. Without that the project turns into a black box, and that uncertainty costs more than the development itself.
When a manager isn't needed, and when one does harm
Not everyone needs the role. If the project has one developer, one person on the business side who makes the decisions, and tasks arrive one at a time, an intermediary only lengthens the chain. A stream of small, similar tasks also gets by without a dedicated person. Written rules are enough: where to send a request, in what order requests are picked up, and how quickly we respond. We run some of our projects exactly that way; how we take a site on for support is covered in a separate article.
The business owner can carry this work too, given a willingness to spend a few hours a week on it: writing down what counts as done, keeping one list of priorities, answering questions within the day. What works badly is something else, namely piling management onto the lead developer on top of their own tasks. They either stop writing code or stop managing. Usually it's the management that suffers: code is visible, and the absence of management is not.
A manager does harm in two cases. Without the authority to decide, they turn into a game of telephone, passing questions back and forth and adding a round of delay each time. And without an understanding of the client's business, they ask the business the developer's questions and the developer the business's questions, and irritate both. Process for its own sake belongs here too: daily meetings for a team of two, three task lists in different tools, reports nobody reads.
How to tell you already need one
The thing to look at is the number of places where people hand work over to each other, not the size of the team. Tasks come from more than two people. More than two people are doing the work at the same time. There is a dependency on someone outside: your own 1C specialist, an agency, a data provider. Work regularly comes back for revision after handover. If at least three of these apply, the role already exists in your project. It's just being done for free, and badly, by several people at once.
That said, project management is a job to be done, not necessarily a separate position on a full salary. You can fill it part-time, hand it to the contractor along with the development, or cover it yourself as the owner. The choice is much the same as the one between an in-house developer and an outside team. The mistake isn't failing to hire for the role separately. It's assigning it to no one.
