For engineers, few career moves can feel quite as dramatic as the one from individual contributor to engineering manager.
Gone are the days spent tackling individual user stories, fixing bugs and diving deep into code. In their place are meetings, one-on-ones and planning sessions. In a lot of ways, it’s like transitioning from player to coach on a sports team. Rather than accumulating personal stats, like how many features you built or lines of code you committed, your impact is defined by how you shaped the success of the team, which can be much harder to measure.
Oftentimes, it comes down to questions that don’t have simple answers: What has your team accomplished? Are they happy and motivated? Is their current work setting them up for future success?
That’s something Brennan Roberts struggled with in his first year managing a team of engineers at sweetgreen. Like many new engineering managers, Roberts had worked his way into the position by being a strong individual contributor. Understanding his new position required him to shift his perspective and recalibrate how he measured success.
Managing engineers is a balancing act between when to get involved and when to step back, finding projects that tap into an employee’s strength and help them grow, and deftly removing obstacles that impede progress. Pressing the right buttons may not yield immediate results, but over time, it will be reflected in on-time project deliveries, employee promotions, and a collaborative atmosphere.
Xiaojie Zhang, who recently stepped into an engineering manager position at the on-demand storage company, Clutter, has found success helping employees determine project priorities and spending more time removing project obstacles than writing code. At the autonomous electric vehicle company Canoo, David Arft has been able to amplify his impact by constantly communicating with his employees and ensuring no one is held up by a lack of information.
Roberts has measured his impact by checking off his day-to-day management goals as he helps his team execute projects.
We spoke with Roberts, Zhang and Arft about how they grew into their roles as engineering managers. Their advice includes:
- Create a prioritized list of things you want to accomplish, and block off time on your calendar to get them done.
- Put your team members in a position to succeed, both by giving them tasks that play to their strengths, and ones that stretch their skills.
- Communicate early and often about what’s going well, and what isn’t.
- Find ways for employees to learn from each other, through collaboration, discussions or exercises like pair programming.
- Make sure everyone knows what they’re supposed to be working on. It’s not always as obvious as it seems.
- Refrain from trying to solve every technical problem that arises. You don’t have the time, and it’ll stifle your team’s growth.
HOW DO YOU ASSESS AND MEASURE YOUR IMPACT AS A MANAGER?
It's a big change from being an independent contributor. I’ve missed being able to measure my impact by the number of user stories or bugs that I've knocked out that week. To get around that, I’ve started measuring every task that I do as a story and track it in a Getting Things Done framework. That’s allowed me to see my tasks both at a tactical and a strategic level.
It can be as simple as writing: “I need to review this document today.” I create and prioritize my list once or twice a day, so I can just go through my list of tasks rather than stop and think after each item. It can be easy to lose sight of what you’re accomplishing, so providing that visibility to yourself of what you’ve done and still need to do is helpful.
For me, it comes down to self-reflection: How am I adding value into the product that's being delivered? A key way is being available to answer questions, provide guidance and ensure that each of my team’s members understand how their work is contributing to our overall goals. I know I’m being effective when people aren’t held up by a lack of information, or by a decision that hasn’t been made.
I use the “Three P Model”: People, process, purpose. First of all, you want to make sure your team is happy about what they’re doing and that they’re meeting expectations and are motivated. I measure that by talking with them regularly and plan to launch employee satisfaction surveys. For process, I want to make sure everything is moving smoothly through using agile methodology, and that we hit our deadlines. For purpose, my goal is that the feature we build is good for the business — we measure that through data.
I don’t think it’s that easy to assess success. It’s more of a feeling. It’s team members leaving the conference room understanding what they need to do, and knowing that they aren’t blocking each other’s progress on a task. There are all these little indicators that can tell you if you’re doing a good job as a manager. You should be a multiplier, not an add-on.
HOW DO YOU CREATE AN ENVIRONMENT WHERE EVERYONE FEELS EMPOWERED TO CONTRIBUTE?
Zhang: The team should be like a family or a group of friends. Communication needs to be open so that, if there’s pushback on a technical design, they’re not afraid to trade ideas and persuade each other to find the best solution. Everyone has something we can learn from, and I try to keep an open and transparent atmosphere to support that.
I also try to encourage everyone to contribute in meetings. One way I’ve done that is by distributing the agenda for a meeting a couple days in advance. English is my second language, so I usually want to read the agenda before a meeting, and I know there are other people on our team in a similar situation. Doing so gives everyone full context into what will happen at the mmeeting so that they can come in ready to contribute.
It’s a big change from being an independent contributor. I’ve missed being able to measure my impact by the number of user stories or bugs that I’ve knocked out that week.”
Arft: For me, it's a trust thing. You have to give people small examples they can go back to where you helped them: “I brought this problem to Dave, and he solved it.” Or, “I expressed a concern with how this was being handled and Dave fixed it.” And you just build on that over time.
I also like to keep a fun environment. I like to joke around a lot and be conversational. On a lean team, one of the keys to success is having open conversations so people feel free to ask for help from the people around them.
HOW DO YOU SUPPORT YOUR EMPLOYEES’ GROWTH?
Arft: Each person has their own unique area where they want to grow. I try to make sure that when those specific opportunities come up, I'm able to pull them into that project. I do that by asking people directly what skill sets they would like to grow, what areas they enjoy and what things make them want to get out of bed in the morning and come into work.
We’ve also found that practicing extreme ownership has helped people be successful. Instead of having someone just write code, they need to integrate it into the controller and make sure it has end-to-end functionality. That allows them to step out of the simple task they were working on and understand how it impacts everyone else. It builds skills and gives people exposure into what they’re doing, and why it matters.
Roberts: We do a lot of pair programming. It works best when we rotate often, usually at a cadence of every three days. We’ve found that it’s not only a good way to transfer knowledge, but that it also directly transfers skills and productivity habits. When two people sit down, it’s amazing how quickly knowledge will spread across the team.
WHAT TIPS DO YOU HAVE FOR MANAGING AND DELIVERING COMPLEX PROJECTS?
Zhang: I'm working on a big project that has a lot of moving parts. I started with first trying to understand the full scope of the project and identify the riskiest part that I should tackle first. I plan to break down the project into deliverable parts, so that I can attach milestones and create deadlines. This will help us measure whether we’re hitting our deadlines or not, and figure out what we need to do to deliver our project on time.
We’ve also found that practicing extreme ownership has helped people be successful.”
Arft: Each project requires a different approach, but starting with a small step-by-step approach and creating a framework of what you're trying to accomplish helps. One of the first things I did to map out the plan for our electric car was to buy a six-foot whiteboard. We then started listing everything our car needed to do, and we drew connections between them with notes on how we would accomplish each of those functions.
When it came to setting deadlines, we started with some high-level goals for the year and for the vehicle. Then we worked backwards from there, breaking those goals into smaller chunks and identifying specific tasks that would take about a month to complete. I like to keep a notebook tracking the status of where we’re at with each task to keep it top of mind. Then we hold a project review at the end of the month and figure out what changes we need to make.
Roberts: Try to avoid letting projects become complex in the first place. Just because your stakeholders have a grand, sweeping vision doesn't mean everything needs to happen all at once. Work with your product team to prioritize, and split the work into shorter, simpler milestones. You have a unique perspective on the dependencies between pieces of work. You might be able to make two seemingly dependent features independent with little or no change to the design. This can be a big win for reducing complexity, allowing for even smaller milestones.
WHEN DO YOU MAKE THE DECISION TO GET INVOLVED, AS OPPOSED TO STEPPING BACK AND TRUSTING YOUR TEAM TO SOLVE A PROBLEM?
Zhang: When you make the transfer from individual contributor to engineering manager, it can be tough to let go of the desire to look into every detail on the technical side. But it doesn’t scale. You need to build a trusting relationship with your reports and know that they can do the job with or without you. That way, you can focus on the bigger-picture issues. So, we’ll do regular check-ins on the technical side, while I focus on ways to boost our code deployment efficiency and make the sprint planning process smoother.
Arft: I like to start out at a high level by outlining the overall goal and scope of the project, and then work with the team to decide which role each person is going to play and what they are going to deliver. After that, I tend to take a step back and keep an eye on progress and make sure everything is going smoothly.
For our last project, we started a daily standup to give the team more opportunities to chat and talk through the next steps, successes and any needs they may have for more resources. My goal is for the team to be able to operate without me — I’m there as somebody who can remove hurdles.
Roberts: I try to keep my involvement to the initial architecture phase and have had to reign in my instincts to jump in on the day-to-day issues that crop up after that. It's not productive or sustainable in the long run if I’m focused on those day-to-day issues.
HOW DO YOU DIVIDE YOUR TIME BETWEEN TECHNICAL WORK AND MANAGEMENT?
Roberts: I’ve found that the time requirements for the managerial side are pretty flat unless you have a critical incident. So that’s one hour a week with each report. The big variations from time demands are coming from the project planning side. But I still have standing time slots for reviewing code.
There was a certain point where I realized that blocking off time on my own calendar did not mean I was being passive aggressive. If I have five things to do in a day and never make time to do those things, I'm setting myself up for failure. So blocking out time, especially if you can tie it to specific items that you're planning to do that day, is something I've found really useful.
You need to build a trusting relationship with your reports and know that they can do the job with or without you. That way, you can focus on the bigger-picture issues.”
Zhang: I’ve needed to ramp up and understand all of the technology we use at Clutter, so I’ve been spending about 50-to-60 percent of my time on the technical side coding and reviewing technical specs and products. I spend the remaining time talking with my team and getting to know everyone. As I’ve become more familiar with the tech side, I like to spend about 40 percent on the technical side and 60 percent at the management level. I think it’s important to remain up-to-date on the technical side — otherwise, what’s the purpose of me attending a meeting? A good engineering manager should first be a good senior engineer; then they can mentor and lead other engineers
WHAT DO BAD ENGINEERING MANAGERS DO?
Arft: I go by what I wouldn’t want from my manager. For me, I don’t want to be micromanaged. I like to have goals and the autonomy to operate within those bounds. Another mistake is to hide the urgency or importance of a task. Give me the opportunity to understand why this is important, and why it needs to be done in that timeframe.
Zhang: The biggest mistake an engineering manager can make is to see a gap or an issue and not act on it. If an engineering manager says, “That’s not my problem,” then there’s a problem there. It’s your job to look at the bigger picture, and if you can see that something is missing and there’s no owner, you own it. In my experience, if a bad thing happens and a manager doesn’t address it, eventually the problem will grow into a black hole and fight back.
HOW DO YOU GIVE PERFORMANCE FEEDBACK?
Roberts: I have a standing one-on-one slot with each team member, and that's their time to use however they want. We keep an agenda that both the report and I have access to and can add action items on. They can use that meeting to code or ask questions, or for career mentorship. If I notice that they're stuck on the same ticket at standup everyday for five days straight, then I’ll know there’s a problem there. It’s important to address those early so it isn’t a surprise.
For success, I think it's important to give shout outs as often as you can. There's no resource scarcity for recognizing people's achievements. Do it as much as you can, because that can mean a lot to the other person. We’ll typically use Slack because that has the most visibility. And, of course, you have to find the right emoji or gif to go with it.
The biggest mistake an engineering manager can make is to see a gap or an issue and not act on it.”
Arft: If there’s a problem, don’t assume you know the answer or reason behind it. I try to approach issues with open eyes and ears to understand the situation from the other person's point of view and get to the root of the problem. I’ve learned that it’s helpful to clearly state what your expectations are, and that if there are any discrepancies, you’ll work together to solve them. Putting that out there has made sure that we are all on the same page.
Zhang: I always do weekly one-on-ones with my reports. If I see something off, I try to be transparent. If they haven’t been productive lately, I try to ask them why and assure them that it’s fine. It may be a life event, it could just be different moods. Either way, we need to put that on the table and figure out a way to overcome it. That way, it won't be a difficult conversation during review season.
WHAT BOOKS DO YOU RECOMMEND ON MANAGEMENT?
Arft: Principles by Ray Daleo. It’s something that I revert back to regularly. He has a lot of good tips both from a managerial perspective and from a self-reflection perspective. Keep your ideas and your thoughts expansive so you don't get stuck on one path or method.
Zhang: Trillion Dollar Coach: The Leadership Playbook of Silicon Valley’s Bill Campbell, by Eric Schmidt, Jonathan Rosenberg and Alan Eagle. One idea I pulled from that book is that a team should be like a community. Everyone needs to support each other. Just because someone’s a senior employee, that doesn’t mean you should always follow their lead. Everyone should be equal.