One of the best books I read last year was a relatively short but incredibly useful guide by Konstantin Borisov on conducting interviews—“To Hire or Not to Hire? Or How to Interview a Developer.” I now recommend it to everyone, whether they are conducting interviews themselves or preparing to be interviewed. It gives you a much clearer understanding of what a potential employer is like and whether they are worth considering.
But Konstantin Borisov also wrote another book—“How a Good Developer Can Avoid Becoming a Bad Manager.” The topic may not seem obvious at first, but it’s actually incredibly relevant. In the IT industry, it’s well known that top specialists often get promoted simply because they excel at their tasks. One day, you’re a great developer, the next, you’re mentoring a couple of interns. Before you know it, you’re made a lead developer, then given a team to manage, and suddenly—you’re a manager.
I went through a similar path myself, though for a long time, I tried to balance both roles. I loved mentoring specialists and building teams, but at the same time, I still wanted to be a hands-on developer. Eventually, I realized that trying to do both was making me worse at each, and I finally made the decision to fully transition into management.
But while my transition into management was a conscious choice, not everyone takes this path intentionally. Many, as I described earlier, simply get promoted due to their technical excellence. However, no matter how someone arrives at management, they all face the same challenge: you were a good developer, but now you need to become at least a decent manager. Or better yet, a great one.
“How a Good Developer Can Avoid Becoming a Bad Manager” is another highly concentrated collection of fantastic, practical advice. While reading, I marked numerous passages, and I could honestly sign off on almost every paragraph. Many of the insights in the book are things I figured out through my own experiences, while others were learned through painful mistakes. But if every IT manager followed Konstantin Borisov’s approaches, I wouldn’t hesitate to bring them onto my team. In fact, these principles are exactly what I look for when evaluating managers for my own teams. Not all of them were easy to work with, but I always found common ground and recognized the strengths that helped drive projects forward.
The truth is, not everyone is meant to be a manager, and sometimes, it’s a mistake to promote an outstanding specialist into a leadership role. You might end up with neither a great manager nor a brilliant expert anymore. Here’s a great quote from the book:
The psychological leap into management is just as significant. A manager sees things differently. And different team leads struggle with different aspects of the role. For example, some people can’t stand being constantly interrupted every few minutes—it drives them crazy. Others struggle to grasp the idea that making a decision quickly is often more important than making the perfect decision. And some will find themselves on the verge of a nervous breakdown when they realize that they are ultimately responsible for every failure—even those caused by their most careless subordinates.
But once the decision is made, it’s crucial to act wisely and thoughtfully.
Just like in his previous book, Konstantin Borisov structures the content into distinct sections:
- At the beginning, he explores management in general and how IT management differs from traditional management. Some key differences that stood out to me:
- Extensive delegation of authority is required.
- Highly independent-minded employees who need very careful management—”even though they often behave quite aggressively themselves.”
- All projects are high-risk by default.
- The next section—probably the largest in the book—dives into motivation and responsibility. This is where I practically marked every page with a highlighter!
- The third section is entirely dedicated to financial motivation and is straightforwardly titled “Money.” It covers when and why salary increases make sense—and when they don’t. How bonuses can actually backfire and even lead to employees quitting. And, most importantly, how money is often an overrated tool for retaining talent.
- In the fourth section, the author discusses project control approaches, different models like Time & Material vs. Fixed Price, and to what extent Scrum is actually a management tool (and how much it truly helps managers).
- And interestingly, Konstantin Borisov ends the book with a short section on becoming a new manager. It includes a list of common pitfalls, real-life examples, and the most frequent mistakes made by first-time leaders.
The sections on motivation and demotivation were my favorites. Probably because these are the topics I’ve been most interested in for the past fifteen years. No matter what tools or methodologies you use in a team, even the best processes become secondary if the team doesn’t know how to work with motivation. Demotivated employees will be unproductive regardless of processes, and turnover will skyrocket. Meanwhile, highly motivated employees will be willing to put in extra effort (which can also be a problem if not managed properly) and support the team purely for the sake of the idea.
According to the author, many factors matter here, but I highlighted a few key quotes:
- When facing issues within a team, you can’t just stop and restart work “from scratch.” “…People are too valuable a resource, and finding 20-30 available specialists is simply impossible. Additionally, in ‘crisis’ projects, knowledge is distributed among key individuals, and without them, work cannot continue. The client also won’t tolerate delays due to a ‘restart’ of the project.“
- “…Working on motivation should start by eliminating demotivation. The thing is, motivation is a very fragile thing. For someone to care about the greater good, strive for self-improvement, and go above and beyond, they need to feel good about their environment. Demotivation, on the other hand, is usually blunt and leaves lasting scars. If a manager loses their temper once, calls a developer useless, and threatens to fire them, they can then relax and no longer bother with motivating that employee. That manager has already broken everything, and bringing motivation back to even a neutral level will require specialized skills and significant, deliberate effort.“
- The ability to acknowledge mistakes and take responsibility for problems. When a team sees that no one is being scapegoated, they appreciate it and focus on finding solutions instead of becoming defensive. But it’s also important to take responsibility in a way that demonstrates exactly what you “could have” done better. This sends the right message to the team.
It’s very easy for a manager to develop an inflated sense of self-importance and blame their employees for everything that goes wrong. But it’s crucial to remember that, in the end, the manager is responsible for all failures, and that responsibility cannot be shifted onto others. If you start seeing your subordinates as useless, soon enough, the only ones left under your management will be useless.
I want to highlight one particular quote about trust because, for me, trust is just as important a leadership skill as productivity. Without trust, there can be no true partnership.
Since trust is a fundamental issue and often difficult to grasp, I’d like to summarize the key points concisely:
- A manager must trust their team because there is no practical benefit in not trusting them.
- A manager should not work with people they consider untrustworthy.
- A manager must not confuse trust with a guarantee against mistakes—everyone makes mistakes.
- Demonstrating trust is not a sign of weakness; it’s about focusing on results rather than getting caught up in personal conflicts or insecurities.
In short, I could keep quoting this book endlessly, but it’s already quite a short read. It’s better to just read it yourself. Especially since, just like the first one, this book is available for free on LitRes!
My rating: 5/5
