Advice to First-Time Engineering Managers
Transitioning into any new role at work means absorbing many new skills as quickly as possible—and this is especially true of transitioning into management. But unless we take time to reflect on and express what we’ve learned in the process, we’re likely to forget most of it. So here are the top four pieces of advice I would like to go back and give my younger self on first transitioning into engineering management in Silicon Valley.
1. Your knowledge and experience have just reset
In Silicon Valley, engineering managers are typically drawn from the pool of senior engineers, and these are people who reached their positions by being technically solid and by gaining respect from people across the org. But once you switch into management it may seem like your career has reset. You may have been in a tenured role with several promotions under your belt before, but now you’re a “Manager I” and at the bottom of a new job ladder. Indeed, in some companies’ job ladders, a front-line manager isn’t referred to as an “M1” but rather as an “M0”—a “Manager Zero.” It may be demoralizing to suddenly be at the bottom of a new job ladder — but that’s the point. Management is about people, and, while your technical skills will help you manage engineers, they will be of secondary importance compared to all the new skills you have to learn. That’s what this job ladder reset is actively telling you.
My first month as a manager I remember feeling like I was in The Matrix because I was learning so quickly it felt like knowledge was being downloaded straight into my head. Where before you were just in charge of shipping some code inside of your boss’s framework, now you’re in charge of building that framework — and of making sure everyone is still executing on it — and of figuring out what work to feed into it — and of arguing for its priority against a dozen other projects at your director and VP levels. Where before your boss would just tell you you’re mentoring some new engineer who’s joining next month, now you’re the one managing job profiles with your recruiter — and doing cold calls of LinkedIn connections — and doing sell calls with candidates with exploding completing offers. And where before you and your teammates would just gripe about the recurring performance review cycle, now you’re the one in charge of their performance — and of representing them in calibration — and of writing up their promotion packets — and of mentoring and guiding them in their careers.
Not all of these new responsibilities will land on you at the same time, but actively check in with your manager to see what’s the next thing you should be learning, and get constant feedback on how you’ve been ramping up.
2. Don’t try to read minds; just ask people what they need
This advice might seem trivial, but inexperienced and first-time managers often think that being the manager means they need to present an air of infallibility and always have the right answers. But in reality this means that they will spend most of their time trying to guess what their team needs—and getting it right less often than they think. This attitude will eventually create a gulf between the manager and reports: the manager will be afraid of getting asked for something directly since it will be something they weren’t able to predict; and the reports will feel like they can’t communicate freely and fully with their manager to get the support they need, and will often end up churning to a new team.
Many senior managers and engineering leaders have a simple way of avoiding this communication breakdown, and it’s simply by explicitly asking their teams, “What do you need?” and “What more can I do for you?” This breaks down the walls and shows that the manager is admitting they don’t know everything but that they want to help solve the team’s problems. Inviting this kind of open feedback is a great way to establish trust and confidence in a new team.
This advice also works both ways, because an engineer can also ask their manager, “What do you need?” and “What more can I do for you?” It’s a sign that the report feels on top of their current workload and is looking for new challenges and more scope. For a manager who was dealing with multiple problems that all look resource-constrained, having a report suddenly announce that they feel on top of their current scope and are ready for more is like suddenly getting extra headcount.
A followup piece of advice is, when one of your engineers approaches you with a problem, assume that they’ve already thought of all the obvious technical solutions themselves and are looking for a different kind of help. If one of them is having trouble hitting a deadline and thinks they’ll have to pull some all-nighters, they wouldn’t expect you as their manager to just pull those all-nighters with them. They’re hoping for you to provide a solution like negotiating a different deadline entirely, freeing someone else up to help out with the project, or pulling in some resources from another team they didn’t even know about. Engineers don’t expect their managers to just be engineers with more authority, but engineers with access to different skill sets and resources.
3. Be humble and admit when you’re wrong
Early in my career I once worked with an engineering leader who made his share of good and bad decisions, but what I remember most about him isn’t any one bad decision he made but the fact that he never admitted he was wrong. Often he would communicate a controversial and unpopular decision over email, and the discontent would rise to the point where other senior leaders in his organization would reply-all to the thread to voice the problems this was causing and cite their concerns with the decision-making process. But, invariably, this leader’s response was to reply-all back with a point-for-point rebuttal of these concerns and then double-down on his original decision.
The problems here should be evident — but let’s evidence some of them anyway. Setting aside any details around whatever this leader’s controversial decision was, the fact that people are replying-all to raise concerns at the very least shows that he should have handled something differently. It takes a lot of courage to stand up to a person in your management chain, and people will only take that risk because they think there is something that materially needs to change in the organization. These are symptoms of an underlying dysfunction that you need to introspect to find and address. But simply saying, “No, I’m right — I was always right,” is asserting that obedience to authority is the only thing that this leader values and that you should never expect any change.
Obviously don’t do this. When you make bad decisions, admit it, point out what you’ve learned, and show what you want to do differently in the future. Use it as an opportunity to show humility and gain trust with your team, and incorporate some of their direct feedback into your future actions. People don’t expect their managers to be infallible; they expect them to be open and receptive to feedback.
4. Be available, not availing
As you transition into management, it’s natural to carry over some of the habits you had in your previous role. One habit I had as a tech lead (TL) was, some days after getting back from lunch and heading to our desks, I’d check in on the engineers in my team to see if they needed help with anything. A common problem with new engineers is they waste time struggling with a problem because they’re too embarrassed to ask for help and think that they should be able to figure it out by themselves. I always appreciated it when my mentors would freely give of their time to help me resolve an issue, and so I tried to take that a step further by actively volunteering my time to my team. If people didn’t have any questions, that was fine; but many appreciated getting some extra attention that helped them overcome problems quickly and become more productive.
While this is an innocuous practice for a TL, it’s a terrible thing to do as a manager. A TL is generally responsible for their team’s productivity, so they have to help people get their work done (code reviews, design reviews, debugging), do major feature work themselves, and even help complete others’ tasks that are behind schedule; so it’s great to have their support. But that’s not your manager’s role. They generally can’t roll up their sleeves to help you finish your task; they just need you to get it done. So having your manager pop up at your desk — even to volunteer help — is just unsettling.
I quickly phased this behavior out when I became a manager, and later on I realized why. At a management conference I learned that one of the traits people most value in their manager is consistency. I was surprised at the time, but it’s now obvious that everyone wants to know what to expect from their manager from day to day and to have psychological safety. And the simplest way to start building that safety is to just not interrupt them.
Set up a framework for how you interact with and get information from your team — and stick to it. Generally this means recurring meetings of stand-ups, one-on-ones, sprint plannings, etc. Don’t drop by unexpectedly to ask how a project is going — that should have been information you got in a stand-up. If you need to discuss some new work with someone, mention it in your next one-on-one, then schedule the meeting a few days in advance to give them time to prepare. And, if you ever need to break this pattern and reach out to someone urgently or reshuffle their assigned work, treat it as an opportunity to retrospect and see how it could have been avoided.
In general, never just avail yourself of your team’s time. Set up clear channels for how you assign work and need progress communicated, then leave them alone to execute and trust them to get it done. But in the meantime you should always make yourself available to your team. Let them know that they can reach out to you with whatever they need to escalate, and be available for interrupts. If you can’t spend a fair amount of time at your desk just being physically available for them, then set up bookable office hours for people to drop by.
These four pieces of advice were the biggest ones I wanted to share now, but I’m always learning more. And I’ll finish with one last bonus piece of advice for now:
