Nobody is irreplaceable
Over ten years as a PM, a chronic need to get everything right and a habit of doing everyone else’s job. I still don’t regret the experience.
When I first started managing projects, my idea of a good manager was fairly simple. She should know everything, do everything and solve problems before anyone else notices them. Anything she doesn’t know? Better learn it right now. By herself, obviously. Otherwise, what kind of brilliant PM am I?
An introvert takes a wrong turn
The funniest part is that I once dreamed of a job where I wouldn’t have to talk to anyone at all. Communication was a source of stress for a long time. Then I picked a job built around talking things through and getting people to agree. Quite an elaborate joke at my own expense.
Sometimes I still wonder how I managed to choose a profession where talking to people fills almost half the working day. Maybe I still haven’t figured out how I’m wired. An introvert with professional conditioning? An ambivert on the lowest setting? Either way, I occasionally want to stay home for weeks without opening the windows. I certainly have questions for my nervous system, especially when I disappear into details and lose track of time. Finishing this article at four on a Saturday morning, for instance.
Part of choosing the profession was an attempt to organise my own life. These days I organise other people’s work for a living, while my own life still needs the occasional planning meeting. Sometimes with escalation.
I can’t say communication suddenly became easy or natural. I still have to fight the urge to hyperfocus, dig deeper and check everything again until I’ve worn myself out. But this profession made me develop skills I once wanted nothing to do with. That may be one of the most unexpected and useful consequences of the choice.
I’ll sort it out myself
At some point, I became quite accomplished at being a one-woman band. Need a specification? I’ll write it. I’ll work out how it should behave. The states and error cases too. And the dependencies, of course. Need testing? I’ll run the scenarios and find the bugs. Then check the fixes. The client doesn’t understand why the system works this way? Give me a minute. I’ll look into it and explain practically every step.
A problem that really belongs to another specialist? No trouble. We’ll search, read the documentation, and see what’s going on. Then we’ll write a proper ticket so we don’t have to bother the business analyst again. And it really did work. I built up my technical knowledge and learned to speak the team’s language. Designers and developers made more sense to me. Other specialists did too. Today I can get to grips with tricky tasks faster and spot trouble sooner. I don’t need everyone to walk me through their part before I understand what’s going on.
At some point, though, professional curiosity quietly became a habit of taking on other people’s work. Sometimes without anyone even asking.
It’s great to be able to figure everything out yourself. But sometimes the best thing you can do for a project is stop taking work away from your own team and let the professionals do their jobs.
I’ll save everyone
There’s a strange guilty pleasure in sorting out a spectacular mess. Especially when you save a deadline, reach an agreement with an unhappy client, or find a solution while everyone else is lost. But if we need a rescue mission every week, why are we always in trouble? Eventually, you can get so used to it that calm, predictable work begins to seem suspicious. Even though that was supposedly what we wanted.
Being convenient gets inconvenient
When a manager constantly picks everything up, people get used to it. Not necessarily because they’re awful people. A system adapts remarkably quickly to someone always willing to take just a little more.
Today you help someone figure out a task. Tomorrow you write the whole thing. Next day you check it yourself because it’s quicker. A month later, you’re genuinely surprised nothing moves without you.
On one hand, you feel indispensable. You know almost everything about the project and can take over any process. On the other, disappear for a couple of days and it turns out half the information lives exclusively in your head. Excellent project architecture. Really fault-tolerant stuff.
I even thought that level of involvement was the highest form of professionalism. If I can help, why wouldn’t I? If I can figure it out myself, why waste anyone else’s time? But “help the team” and “do it for the team” are separated by a very fine line. One I crossed regularly.
Thanks for the initiative. Here’s more work
There’s a fairly universal feature of employment that isn’t particularly specific to IT. At first, an extra task is an exception. Then it becomes a habit. After a while, people are genuinely surprised when you stop doing work that was never actually part of your job.
The sad part is that your pay rarely keeps up with the extra hats. You slowly pick up design and analysis. Then QA and technical advice. A bit of management too, if there’s time. Your job title and payslip don’t magically catch up. Helping colleagues and stepping outside your role aren’t bad things. There’s simply a substantial difference between being able to do more and being permanently obliged to do more.
Being a premium employee on a basic plan doesn’t necessarily mean someone is deliberately exploiting your kindness. Sometimes we spend years showing we’ll expand our own job description for free. Then we’re surprised nobody suggests stopping. It’s worth checking what the extra responsibility gives us in return. Authority, money, prospects? Excellent. Just another ticket marked ASAP, followed by complaints that it isn’t done yet? Might be time to reconsider.
More skills don’t have to mean more jobs
Eventually I realised you can understand the technical side of a project brilliantly and still have no time for actual management. You’re busy debugging a scenario. Meanwhile the plan still needs attention. So do deadlines and risks. People still need updates and agreements still need following up.
Sometimes you genuinely do need to use your expertise in another specialist’s place. A project may have no analyst, an urgent technical assessment may be needed, or checking a small feature yourself may be simpler than another round of coordination. That’s fine. This is precisely where accumulated experience pays off. But knowing how a system works doesn’t mean constantly designing it for the developer. Understanding testing doesn’t automatically make you QA. Being able to write specifications doesn’t mean taking every one away from the analyst.
Easy to promise, hard to say no
I used to find it much easier to tell a client “Yes, we’ll try” than explain why their request didn’t fit the schedule, budget, or team’s capabilities. Especially when the relationship was good and I didn’t want to spoil it. I genuinely enjoyed making clients happy, finding compromises, and resolving things without endless approvals. Occasionally, I found the compromise and the team got to deliver it.
Clients don’t always see a fundamental difference between “we’ll try” and “we’ll do it”. More than once, I discovered I’d volunteered to create a problem out of absolutely nothing. The client expected delivery. The team discovered a new commitment. I got to make it happen. Fantastic. Really nailed that negotiation. Eventually, I had to admit good client relationships aren’t measured by how much we concede. My diplomacy shouldn’t be paid for with the team’s time. Stating constraints early is more professional than promising the impossible and scrambling to deliver.
Better work or a blown budget?
Quality was its own story. I knew how something could be better and sometimes got carried away. Could the designer polish it a bit more? Could the developer spend another couple of hours? Could we throw in this tiny thing for free, because without it the result feels unfinished? The client hadn’t always asked for these improvements. Sometimes a working solution at the agreed price was perfectly sufficient. Meanwhile, I’d imagined an ideal result and was trying to squeeze it into a budget nobody had allocated for that particular heroism.
My personal sense of beauty shouldn’t automatically become extra work for the team. Particularly when we’re delivering under a specific commercial agreement rather than building our own product. I still care about quality. Saving money isn’t an excuse to do a bad job. I just understand the trade-offs better now. Quality has to make sense for the budget, timeline and business need. Often, the right move is to offer two options at different prices instead of delivering the expensive one for the price of the cheap one.
Peace, friendship, and a nervous twitch
Project management carries a particular kind of load that doesn’t always fit neatly into person-hours. We regulate expectations, smooth over conflicts, and translate client frustration into something constructive. Preferably while staying calm, even when our own supply of diplomacy ran out hours ago. That’s emotional labour, managing your own emotional reactions as part of the job. The longer you have to perform unflappability, the more energy it takes, especially when other people’s worries gradually start feeling like your own.
The worst part begins outside work. All day you listen and reassure people. You support them and help sort things out. In the evening, you discover there’s nothing left for your own problems. You may start feeling that everyone always needs something from you while hardly anyone cares how you’re doing. The people close to you may have no idea: you keep a composed face at work, then get home and don’t want to speak to anyone.
You can spend all day with people and still feel completely alone. You become so used to being the person who solves problems that you stop asking for help yourself. Even when you need support, it’s easier to say “I’m fine” than explain what isn’t. Over time, that stress can lead to occupational burnout, leaving you emotionally drained, cynical about work and unsure you’re achieving anything. Feeling unwanted and socially isolated can make things worse. Burnout isn’t the same as depression and doesn’t necessarily lead to it, but lasting exhaustion alongside other risk factors isn’t something to dismiss as ordinary tiredness.
From the outside, you can look perfectly successful. Projects move forward and clients are happy. The team gets things done. Problems get sorted. Your own life, meanwhile, becomes a continuous recovery period between workdays. Jira rarely has a ticket for the two hours you spent putting everyone back together. Never mind the six months you spent trying to do the same for yourself.
When we leave, someone will replace us. Maybe not immediately. Maybe at greater expense. Maybe they’ll even miss us. None of that recognition is much use to a manager who’s already burned out.
Then experience kicks in
I still want to know how other people’s work works. I still care about the projects and want them to turn out brilliantly. I just understand the cost of my decisions better. Good client relationships shouldn’t be bought with the team’s time. The ideal result doesn’t always justify the expense. Someone else’s urgency doesn’t automatically have to become my problem. And I certainly don’t want to save everyone and everything at the expense of my own nerves. Now I ask who benefits from making something better and what it’ll cost, rather than just how to improve it.
The good-girl syndrome hasn’t vanished, of course. I still want to open someone else’s ticket and dig in. Fix this, double-check that, sort out half the questions while I’m there. But now I notice more often when it’s time to stop. I don’t regret it: all that improvisation gave me expertise you can’t get from books or courses. I’m simply more deliberate about where I use it. If I could speak to myself at the start of my IT career, I wouldn’t give a long lecture. She wouldn’t listen anyway. I’d boil it down to three thoughts.
- Don’t confuse quality with perfectionism. Every decision has a cost. Someone has to pay for the team’s time and resources. Perfection at any cost isn’t professionalism. Understand which efforts are actually worth it.
- Don’t turn competence into an obligation to do three people’s jobs. Understanding other people’s work is useful. Replacing the whole team is rather less so. Expertise should expand your options, not your job description.
- Don’t pay for a successful project with your nervous system. Easing conflicts, solving problems, and caring about the result are part of the profession. Experiencing every work problem as a personal tragedy? No, thanks. Projects end. You still have to live with yourself.
I’m a project manager. About working with russian clients and teams, sharing experience and things I’ve noticed.