This is an R-rated post. I am going to be very direct and honest, based on my personal experience and how I see things. It is not a general rule. If you do not agree with anything you read here, that is fine. I am not here to define rules, and I am happy to hear your thoughts.

The part nobody warns you about

Here is the thing nobody tells you when you move from engineering into management. The day you take the job, you stop shipping code, and your output stops being your output. It becomes whatever your team ships. That sounds obvious until you live it. Your instinct is still to open the editor and fix the bug yourself, because that is what you are good at and it feels productive. But every hour you spend doing your old job is an hour you are not doing the new one.

The hardest part is technical credibility. You earned your spot because you were a good engineer, and you can still read the pull request and see the better way to do it. The question is whether you should. Jumping in and rewriting someone’s code proves you are smart and teaches them nothing. Most of the time the right move is to ask a question and let them get there themselves, even if it is slower, even if it is not how you would have done it. Letting go of the keyboard is most of the job, and it is much harder than it sounds.

And yes, the question every engineer asks: do I keep coding? My answer is a little, on things that are not on the critical path, so you do not lose touch with the tools your team lives in. But the moment your coding becomes a blocker for someone else, you drop it. Your job is now to make the team fast, not to be the fastest person on it.

First of all, if you are a manager or in a management position, you have to remember that delivering the project is the goal, but to get there you have to manage people. And people are not robots. They have feelings, they have personal problems, they have their own goals, and you have to understand that. You can read tons of books on how to manage teams or projects, but dealing with people is not something you learn from a book. You learn it through the relationships you build over time.

A successful manager is the one who can listen to their team, understand their needs, and help them achieve their goals. Not the one who is there only to create Gantt charts and burndowns and keep asking for daily reports. A true manager trusts their team. If you do not trust your team, you have to reconsider something. And most important of all, a manager who has the team on their side can achieve the impossible.

What trusting your team actually looks like

Trust is easy to say and hard to do. In practice it means handing people a problem instead of a task, and letting them own the solution. It means removing the blockers in their way and then getting out of the way. It means a one on one that is about them, their growth and what is frustrating them, not a status update you could have read in the ticket. And it means taking the hit publicly when something goes wrong, and giving them the credit publicly when it goes right.

Do those things and you will not need to ask for daily reports. You already know how your team is doing, because you actually talk to them.

To finish, if you are a manager or want to become one, be ready to make decisions when they are needed, even when you do not have all the information you would like. Someone who cannot make a decision and take responsibility for it should never become a manager.

A manager’s job is not to receive orders, ask for status updates, and keep a spreadsheet up to date. If your job is all about checking the backlog and creating reports, then I am sorry, but you are not a manager. You are a bureaucrat.

Further reading

This post is my opinion, not a manual. If you want to go deeper and learn from people who have written proper books on the subject, these are the ones worth your time:

  • James Stanier, Become an Effective Software Engineering Manager — the most direct answer to “I am an engineer, now what do I do as a manager?”.
  • Camille Fournier, The Manager’s Path — the path from tech lead to senior leadership, stage by stage.
  • Will Larson, An Elegant Puzzle: Systems of Engineering Management — for the systems and structure side of the job.
  • Andrew S. Grove, High Output Management — the old classic, still the best on leverage and output.
  • Kim Scott, Radical Candor — on caring about people while still being direct with them, which is most of what I wrote about above.
  • Will Larson, Staff Engineer: Leadership Beyond the Management Track (2021) — the reminder that management is not the only way up. You can lead as a senior engineer without ever managing people.

This post was written with the help of AI (Claude by Anthropic).