6 Tips for the New Engineering Managers
You became an engineering manager because you were a strong engineer and demonstrated strong leadership. You solved hard problems, had answers in design reviews, and moved fast. In your first months as a manager, the same habits slow your team down.
In this article, I want to mentor new engineering managers, and this is the list I'd start with. It's also the list I'd have liked to read when I started.
Don't try to be the smartest person in the room
As an engineer, your value was the right answer. As a manager, if you always answer first, the team stops looking for the answer and waits for yours. Leave space for others to contribute, and ask the area expert for their decision.
In a design review, don't open with your solution. Ask the person who owns the area: "You know the payments service best. What would you pick, and why?" Then speak last.
Google's Project Aristotle studied about 180 teams and ranked psychological safety first of five team dynamics. On the best teams, people spoke in roughly equal amounts. As a manager, you need to get up to speed on others rather than solve every problem yourself.
Note: You still own the decision when experts disagree, or nobody owns the area. Asking first doesn't mean you never decide.
Learn to delegate, and stop doing the tasks yourself
Doing a task yourself used to be the fastest way to close it. Now it's the slowest way to grow a team. Every task you keep is a task nobody else learns, and you become the bottleneck for reviews, releases, and decisions.
Delegate the outcome, and say how much decision power comes with it. Delegation Poker from Management 3.0 offers seven levels: Tell, Sell, Consult, Agree, Advise, Inquire, and Delegate. Name the level when you hand the task over:
You own the caching change. You pick the design.
Tell me what you chose before the release.
That's the Inquire level: the engineer decides, and you can still ask questions afterward.
Cost. At first, it's slower, and the result won't look like the solution you'd write. Don't take the task back. Review the outcome, give feedback, and move one level up next time.
Find a mentor, and follow their advice
Management has no compiler, no tests, and no stack trace. You learn from feedback, and a mentor gives you that feedback before a mistake reaches your team. Find an experienced manager inside or outside your company, meet on a schedule, bring real situations, and then actually try what they suggest.
My mentor helped me with many things. These are the ones a mentor usually helps with:
- preparing a hard conversation: negative feedback, a performance problem, a conflict between two engineers;
- saying no to a stakeholder without breaking the relationship;
- reviewing how you run your meetings and 1:1s;
- deciding what to delegate and what to keep;
- your own career: where you want to be in two or three years.
A monthly 30-minute call works: bring two or three situations from the last month, and report back on what you tried after the previous call.
Note: Your mentor's advice comes from their company and their team. Adapt it to your team, and if it doesn't fit, say so on the next call.
Train empathy and protect your team's work-life balance
Engineers rarely say "I'm burning out" at a standup. You see it in other signals: messages at 23:00, commits on weekends, a quiet person who gets quieter, a strong engineer who stops arguing in code reviews. Train yourself to notice these signals, and ask about them in a 1:1.
Then protect the team's time. When a stakeholder adds scope to a fixed deadline, the team absorbs it with overtime unless you cut scope or move the date. That's your job, not theirs.
Gallup estimates that managers account for at least 70% of the variance in employee engagement across business units. That's survey research about engagement, not burnout, but it shows how much of your team's day depends on you.
What to change. Add a workload question to every 1:1 ("How is your workload this week?"), and treat repeated after-hours work as a planning problem, not as commitment. Read more about 1:1s in the article: 10 Tips for Effective 1-2-1 Meetings.
Log decisions, and don't leave abstract agreements
A call ends with "OK, let's do it." Two weeks later, three people remember three different decisions. That's an abstract agreement: nobody wrote down what exactly the team agreed, who owns it, or by when.
Fix every agreement in writing right after the call. An email or a chat message is enough:
Subject: Decision: move report generation to a background job
Decided: report generation moves out of the API into a background job.
Owner: backend team
Due: end of sprint 42
Open: retry policy, we decide it on Thursday
Reply by Friday if you remember it differently.
For architecture decisions, write an ADR (Architecture Decision Record). I prefer ADR templates that record the options considered, so the reader can see why the team chose this one over the others.
What to change. Send the recap the same day to everyone who was on the call, and keep decisions in one place the team can search: a decision log page, a wiki, or ADRs in the repository. Read more in the articles: 10 ADR Anti-Patterns and ADR Best Practices and Best Practices for Effective Software Architecture Documentation.
Engineering manager or IC track? Both are fine
Not every strong engineer wants to manage people, and that's fine. Don't promote someone into management just to give them a raise or a bigger title. If your company has an individual contributor (IC) track, with senior, staff, and principal engineer roles, offer it as an equal path.
The same applies to you. If, after a few months, you realize you don't like management, it's fine to leave the position and return to engineering. That's a decision about the work you want to do, not a failure.
Note: Some companies have no IC track above senior engineer. There, stepping back can mean a smaller title, so discuss it openly with your own manager before you decide.