I have been an engineering manager for about ten years, across four companies, working with teams of different sizes and very different problems. I would not call myself an expert, but I have seen the same patterns repeat over and over, especially when people first move into management. I have seen them in others, and I have definitely seen them in myself.
These are some of the lessons I wish I had taken more seriously earlier.
Put down the IDE
This has been said before, and probably needs to keep being said: once you become a manager, writing code should no longer be how you measure whether you had a productive day.
Your value has shifted. You are no longer primarily responsible for solving technical problems yourself; you are responsible for creating the conditions where your team can solve them well. That means spending time on strategy, team dynamics, decision-making, mentoring, removing friction, and understanding the broader context around the work.
There are times when writing code makes sense. I still like staying close to it. But if you are regularly picking up tickets because it feels productive, familiar, or easier than the management work sitting in front of you, it is worth asking who you are doing it for.
Letting go is uncomfortable. Coding is measurable. Management often is not.
Make expectations explicit
Time and time again, I hear managers frustrated that someone is not meeting their expectations. When I ask whether those expectations have actually been communicated, the answer is often no.
Did you state what you expected clearly? Did the other person understand it? Did they have a chance to ask questions or tell you where they disagreed? Do they know they are accountable for it?
You cannot fairly hold someone accountable for an expectation they did not know existed.
This becomes particularly important with performance problems. By the time you are seriously concerned about someone's performance, nothing you say should come as a surprise to them.
Calibrate on people with someone more experienced
Evaluating people is a skill, and you are probably not going to be particularly well calibrated when you first become a manager.
Find someone with more experience and talk through your assessments with them. Discuss performance, growth areas, promotions, and the feedback you are planning to give. Ideally, find someone who is not in your reporting structure and has enough distance to challenge your assumptions.
One of the easiest mistakes to make is avoiding a difficult performance conversation and telling someone they are doing well when they are not. It feels kinder in the moment. It rarely is.
Eventually you end up in a calibration or promotion conversation trying to explain a concern that the person themselves has never heard. Worse, everyone else on the team can often see what is happening. That creates a problem much larger than the conversation you were trying to avoid.
Become friends with recruiting
A big part of management is attracting and retaining great people, which makes recruiting one of the most important partnerships you have when building a team.
When you have open roles, meet regularly with your recruiter. Be active in top-of-funnel reviews. Talk about who you are seeing, what is working, what is not, and where good candidates are dropping out.
These meetings are easy to treat as optional when your calendar is full. They are not.
Hiring is not something you hand to recruiting and check back on later. The time you put into it shows up in the team you eventually build.
There is another benefit I did not appreciate early enough: recruiters often have an unusually broad view of what is happening inside a company. They hear what candidates are saying, what managers are asking for, which teams are struggling to hire, and how the company is being perceived from the outside. If you build a good relationship with recruiting, you often learn things that never make it into a status update.
Find your person, and it should not be someone you report to
Management can be lonely.
Find someone outside your reporting line who you trust enough to be unpolished with. Someone you can vent to, think out loud with, and pressure-test a decision before you make it.
This is different from having a good manager. Your manager is still your manager. There are inevitably things you will frame differently when talking to the person responsible for evaluating you.
You need at least one relationship where there is no reason to perform.
“I don’t know, but I’ll find out” is a great answer
Congratulations, you are now a manager and suddenly people are looking to you for answers.
You will not always have them.
That is fine. What matters is what you do next.
“I don’t know, but I’ll find out” is a perfectly good answer, as long as you actually find out. Pretending you know something when you do not is much more damaging than admitting uncertainty.
There is a second benefit here. When a manager is comfortable saying they do not know, it becomes easier for everyone else to do the same. That matters on teams where people are solving problems that are actually difficult.
Find a senior engineering manager outside your company
This is different from finding someone you can vent to. Find someone more experienced than you, preferably at another company, who you can occasionally talk to about management.
It does not need to be a formal mentorship relationship. In fact, I prefer when it is not. Sometimes you just need to ask, “Have you seen this before?” and get an answer from someone who has.
It is very easy to spend years inside one company and start believing that the way your organization works is simply the way organizations work.
Sometimes it is.
Sometimes your company is just weird.
Having someone outside the bubble helps you tell the difference.
Do not solve people’s problems for them
This was one of the harder lessons for me to learn.
When someone brings you a problem, the instinct is often to fix it. You probably became a manager in part because you were good at solving problems, so this can feel like the obvious way to help.
Often it is not.
For problems the person is capable of owning themselves, your job is to help them think through the situation, understand their options, and decide what they want to do next. If you continually step in and solve things for people, they learn to bring you problems instead of learning how to solve them.
There are obviously situations where a manager needs to step in directly. Harassment, serious performance issues, safety concerns, and other problems involving your responsibilities as a manager are not coaching exercises.
But when someone can own the problem, let them own it. Support them without becoming the solution.
Manage on output, unless the method matters
Do not expect people to work the way you do.
Be clear about the outcome, the constraints, and what success looks like, then give people room to figure out how to get there.
The method does matter sometimes. Security matters. Maintainability matters. Collaboration matters. How someone treats the people around them matters. A person who delivers impressive results while leaving a trail of broken systems and unhappy coworkers is not actually delivering impressive results.
But outside of those constraints, resist the urge to prescribe exactly how someone should work simply because it is how you would do it.
If the outcome is good and the path there is sustainable, let people surprise you.
Be kind to yourself
You are going to get some of this wrong.
I have.
Management is a skill that takes time to develop, and the first few years involve regularly finding yourself in situations you have never dealt with before. Sometimes you will handle them well. Sometimes you will replay the conversation afterward and realize exactly what you should have said.
Learn from it, apologize when you need to, and try to do better the next time.
You would probably give someone on your team that same room to learn. Give yourself some of it too.
And find a way to treat yourself.