David Loftesness is now the head of engineering at eero and the co-author of Scaling Teams.
There’s an all-too-common cycle in tech these days. Startup avoids management. Founder makes all the decisions. Startup gets traction. Hiring takes off. Management is suddenly needed. Founder turns to his best engineer: “I’m drowning. Can you manage this team for me?"
David Loftesness, Twitter’s former Director of Engineering, has been that chosen developer many times over two decades and six technology companies, including Xmarks and Geoworks. After steering his way through multiple engineer-to-manager transitions, Loftesness started shepherding other developers into their first leadership positions.
In 2015, he collected his wisdom on the subject into a 90-day plan for developers who transition into management. In this exclusive article, he breaks down this plan to help engineering leaders set their priorities, gain their footing, and assess their own performance so they can grow fast and start empowering others.
Here’s Why You Need a Plan
“It’s true that there are a billion blog posts about how to manage. But I felt that not only did they often contradict each other, but they also lacked defined checkpoints,” says Loftesness. “What I needed was a time-bound plan where there were opportunities to opt-out or level-up. That’s how I approach the 90-day plan for engineers becoming technical managers.”
He built the plan when he realized that tech companies are often predisposed to converting in-house engineers into managers (sometimes regardless of their interests or experience). On one hand, a developer enters management with rich context on the technology and workflow, all of which help with product development and process. However, a newly-minted technical leader typically has no idea how to manage people.
In an informal survey, Loftesness found that only one out of every 15 engineering managers received formal management training prior to becoming a manager. When asked which methods had been most helpful for learning to manage effectively, nearly 75% reported “trial and error,” half cited feedback from direct reports, and 40% said observing peer managers.
This rang incredibly true to Loftesness: “When I first became a manager, I spent at least six months just faking it. I built out our scheduling and thought, ‘I guess we need to have meetings…’ so we created meetings. Basically I just replicated what I saw around me.”
The takeaway? If left unaddressed, many engineering teams end up being entrusted to technical phenoms who also happen to be untested leaders. These new managers are often put to an even more rigorous test because they’ve been asked to manage just in-time — to fill a personnel gap, ship an overdue product or handle a company crisis.
Loftesness’ 90-day framework can help new managers navigate their first quarter with three distinct stages: Own Your Education (Days 1-30), Find Your Rhythm (Days 31-60) and Assessing Yourself (Days 61-90). But first, there’s the decision of whether to commit to management -- which is a much bigger deal (with bigger tradeoffs) than most people suspect.
Day 0: Inevitable Truths You Need to Accept Upfront
Most engineers spend so much time in the codebase that they don’t take on leadership responsibilities until they’re tapped to do so. It’s usually up to seasoned managers to identify those with potential. “Over the years, I found it all starts with a gut feeling about an engineer,” says Loftesness. “But it won’t be successful unless the manager-to-be is able to visualize herself taking on a very different type of role away from the code.” Loftesness has found that the best new managers have contemplated and fully accepted these new realities.
Prepare to manage in three directions.
“About two years ago, one of my engineers asked me: ‘How do I know if I'm ready?’” Loftesness says. Before answering, he drew this simple diagram:
“You’re ready if you understand from the beginning that you’re going to be managing in three directions, not just overseeing a team of developers,” says Loftesness. Here are the three relationships that he references, and the questions a potential manager should be able to answer about each:
- Your team. Can you effectively lead engineers, particularly your former colleagues? Do you fully understand the work? Will you take responsibility for your team’s goals?
- Your peers. Can you work well with your fellow managers and avoid turf battles? Do you communicate effectively with your peers?
- Your manager. Can you give clear snapshots of the state of projects for busy managers? Can you skillfully push back if you disagree with your manager?
Loftesness adds that high-caliber leaders learn to manage up to their boss, down to their team, and across to their peers. “This is not a sequence or rank order, but a checklist,” says Loftesness. “You want to make sure all three of these boxes are checked — maybe not immediately, but within the first 90 days.”
Determine at the onset how it’ll motivate you.
“This is an entirely new job. Don’t expect to just bolt-on some management work and call yourself a manager,” says Loftesness. “You now have people whose happiness and effectiveness at work rests largely on your shoulders. You’re responsible for the results but can’t do it all yourself.”
As a manager, you no longer ride the rollercoaster. But you operate it. That should exhilarate you. If it doesn’t, maybe it’s not for you.
Before taking on responsibility for others, you need to thoroughly investigate your motivations for taking the role. Be honest with yourself about what drives you. Loftesness has seen good and bad motivations both baptize and drown new technical managers. Here are the most important things to look out for:
Don’t manage in order to please the boss. “Making the boss happy at the exclusion of your own happiness is not a good reason to take on a role,” says Loftesness. “It’s especially challenging if your manager was your friend or colleague first. Step back and answer to yourself first.”
Don’t manage only to advance your career. Many tech companies have parallel career paths to seniority for both technical and managerial high-performers. “It’s great that you want to lead a team, but take stock. Ask yourself if it’s the right time. Are you ready to accept the role at this moment? If you take the job prematurely and fail, that's going to be a step backwards. Not a step forwards."
Don’t manage to “take one for the team.” If you’ve played the role of a martyr in the past, press pause. As a manager, being a hero — and each related rise and fall — will impact more than you. “Know yourself well enough to determine if you are going to resent taking one for the team,” says Loftesness. “The motivation to step up to relieve colleagues is noble, but not sustainable if it’s the sole, driving reason to lead.”
Manage if growth for you involves others. “One summer, two of my engineers became managers. It was the season of fresh-faced summer interns. One manager bemoaned being assigned to an intern and saw the relationship as a time-suck. The other saw it as an opportunity to groom a better engineer,” says Loftesness. “They can still love the technical work, but managers are most content when they get to help people become better at their jobs.”
Manage if you channel empathy. As a manager, it’s fundamental to have the ability to empathize. “Empathy isn’t natural for everyone, but I have a way I like to test for it. I ask people to recount a conflict on the job. Then I ask them to describe what was going on inside the other person’s head,” says Loftesness. “If they can explain why the other person wanted them to do something, that’s the sign of empathy — and a manager.”
Manage if you can give the trust you ask of others. Perhaps the most important tip: Don’t lie. Don’t share sensitive information from a one-on-one meeting. But there’s a more collaborative way to build — not just keep — trust. “A good manager is like a good interviewer,” says Loftesness. “The best interviewers do what they want the interviewee to do. They’ll share a personal moment, a funny story and they’ll get that back. They don't dominate airtime, obviously, but they give a little bit and they get a lot back typically. I think it's very similar with the manager. Asking questions and showing that you actually care creates a lot of space to share feelings and engender trust.”
When you see a teammate struggling, are you one of the first people to go over and offer a hand? That’s a sign.
Get ready to say goodbye to coding.
Coding, architecture and technical decision-making is no longer your primary job when you manage other engineers. This comes as a huge surprise to many who make the switch, and it’s one of the most difficult adjustments.
“It’s okay to have a transition period, but the longer you hold on, the longer it will take to become a competent manager,” says Loftesness. “A company’s growth can dictate the context, but, given the volume of material to absorb, I think new managers need to commit to a year away from the code.”
Consider this: most engineers spend four years of college learning to be an entry-level coder. So doesn’t it make sense to dedicate a fraction of that time to learning how to manage? Decide if you can stick to a year-long coding sabbatical.
When Loftesness talks about a break from the code, he means from writing it. “For a manager, reading code is significantly more important than writing it. Writing code is a temptation — and distraction — for any manager,” says Loftesness. “It’s okay to read enough to know what people are working on, to understand progress and manage the team. Just don’t slip into writing code as an escape from management responsibilities.”
Loftesness has seen numerous technical managers struggle with this transition. “There was one engineer I worked with who knew this was going to happen conceptually but couldn’t let go in practice. In the end, management was a bigger change than she expected. She was keen in observing other managers and me, and saw that there’d be a lot of emails, meetings and non-coding work.” But she didn’t realize how much she’d miss coding and eventually returned to being an individual contributor.
As with any new job, the most important task you should be doing at any given time will definitely be uncomfortable. It should be.
“At first, I didn’t stop coding after I got promoted because it was familiar work and a way to ship faster. But I paid for it,” says Loftesness. “I avoided telling my boss that a project was off track and also didn’t give a critical review to a member on my team. If I had focused on giving performance feedback, I would have fired an underperformer months earlier. It would have been better in the long run for the engineer, the project and the team. I should have stopped coding much sooner.”
“Know the difference between crutches and training wheels,” he says. If a new manager serves as “training wheels,” he’s done something to enable his team to execute better and faster in the future. But he’s a “crutch” if he rushes in to do the job himself — removing the opportunity for somebody else to learn.
“Trust but verify,” says Loftesness. “Don’t watch them code everything, but pay attention to the important pieces and give them positive or negative feedback based on their work.” Also, choose times to let them run with an idea that you may not agree with at first. There’s no bigger show of trust.
“Find those moments for new managers to define and explore something new. If it's mission critical and the failure of this task would derail the project, that’s not the right time. But there are other moments they want to do X, you think they should do Y. Explain your motivations on both sides. Letting them do X whether they succeed or fail is a really big trust-building moment.
Get ready to say 'hello' to your team.
When Loftesness became an engineering manager at Twitter, he learned early just how vital lines of communication — versus lines of code — were to his success. “I took over a highly visible project that the VP of engineering had launched. My manager was pulled in too many directions and asked me to oversee the project. The singular goal was to get it out the door.”
Loftesness charged ahead, asking for three more engineers to get it shipped as quickly as possible. One new, thoughtful engineer asked him details about the the background of the project, and a few hard questions about its objective. “Up until that moment, this was the project at the company. It was going to save Twitter, so no one questioned it,” recalls Loftesness. “But after the engineer’s questions, we realized we had built the wrong product and cancelled the project. We found another way forward, but it was a big moment for our group and Twitter’s management team.”
Deciding to become a technical manager means that instead of coding and design work, your charge will be to establish frequent opportunities for communication — to better understand the people on your team and enable them to do their best work. Here are two non-obvious tactics he uses to listen carefully to his team:
Continuous career conversations. “It may not be in your first conversation, but I do think very quickly you want to know what are your people trying to achieve? What are their career goals, if they have them? Usually they'll say, ‘I just want to keep being an engineer,’ but they might have something specific like, ‘Oh I want to be a manager in a couple years,’ or, ‘I want to do a start up someday so I want to learn everything I need to do,’ or, ‘I want to be a recognized technical expert.’ Whatever it is, it's really important to ask that question and then to check in on that regularly.”
A calendar sequenced by seniority and size. “Each week, I have my meeting with my boss on Monday morning, then my full team meeting on Monday afternoon, and then each 1:1 starting on Tuesday. The order intentionally facilitates top-down communication, so that engineers doing the work have as much context as possible. Otherwise, I become a bottleneck and information will come out in dribs and drabs — from me or someone else. Up-and-down communication is the easiest place for a manager to get lost.”
As you can see, there’s a lot of thinking, preparation and strategizing that has to go into the transition to management before the role even starts. The faster your can work through and decide how you’re going to handle these challenges, the more prepared you’ll be for the work ahead. If management still sounds like the right path for you, here’s what you should do next.
Days 1-30: Own Your Education
If you’ve decided to transition from engineer to technical manager, your first month is about committing to own your education. Here are three ways Loftesness recommends doing so:
Block off time to study up. There’s no easier or more effective way to own your management education than to reserve time on your calendar. These sessions are in addition to the new staff meeting or 1:1s, where you practice what you learn. “I mean it. Go into your calendar and block off time,” says Loftesness. “The purpose of this time is to become a better manager, whether that is meeting with a mentor or reading up on management tactics.”
Here’s a few of Loftesness’ go-to management reads that he recommends for any new technical manager:
Peopleware by Tom DeMarco and Timothy Lister. This is an all-time classic, dated in the details but still true in its principles and overall approach.
The Mythical Man-Month: Essays on Software Engineering by Frederick P. Brooks Jr., particularly the more recent edition with his “No Silver Bullet” essay.
First, Break All The Rules by Marcus Buckingham and Curt Coffman. They bring a tremendous amount of Gallup data to bear on what it takes to be a great manager.
And there’s a ton of great short-form management writers out there, including Spolsky, Rands, and Sutton. Don’t take any of them as gospel but use them to hone your own sense of how you can best manage your team.
Don’t hide your study sessions. New managers will actively learn from their team, but also from other sources and resources. “When you block time for your education on being a better manager, own it,” says Loftesness. “That starts with keeping your schedule visible to your team. A lot of times new managers make their calendars hidden, which can cause confusion and tension in the team. Your team will appreciate your effort before they even benefit from it. Literally block time off on your calendar and call it something like, ‘Management: leveling up.’”
Find a management mentor (or two or three). Nearly half of the engineering managers from Loftesness’ poll never sought input from a mentor with experience in management. That’s a missed opportunity. “In your first month, ask your boss for mentor recommendations, but not to be your mentor,” says Loftesness. “You should already be getting guidance from your boss. Look for someone who’s at least slightly removed who can give additional guidance and perspective.”
You’ll be surprised how many engineering managers will respond well to these requests. “Twitter and Amazon had directors that were very willing to give time to younger managers to help them improve,” says Loftesness. “In the absence of asking someone directly, ping a manager mailing list. The ask doesn’t have to be complicated: ‘I’m looking for somebody to spend some time working through a few questions about management. Is anyone available?’”
Days 31-60: Find Your Rhythm
During the second month, your goal is to structure your schedule to find a new rhythm, one that will be noticeably different from your days as a coder. Here’s what worked for Loftesness and many of the other managers he’s counseled.
Cancel meetings. It may seem counterintuitive, but giving in to the endless cycle of meetings is one of the most common new manager traps. “I think being judicious — even vicious — about canceling meetings is a key habit to start early,” says Loftesness. “Of course, be respectful if you decline, but always protect your time. “People will invite you to meetings because other managers are attending or they’ve just cast a wide net. It’s easy to feel obligated. I encourage my managers to ask themselves: “Is this meeting important to getting your job done?”
When it comes to your engineers’ time, honor and defend their judgement. “I once had a colleague who would love to tattle on people that reported to me. He’d say, ‘Do you know Susan hasn't come to the last three meetings? Can you talk to her about that?’ I’d let him know that Susan is able to make her own decisions, and that if you need her there, convince her that it’s important.”
Continue to calendar defensively, but not in a vacuum. In your 30 days, you’ve scheduled recurring meetings with your team and time to learn how to become a better manager. Continue to defensively block your calendar, but not at the expense of your engineers’ time. “If an engineer and I need to meet, I typically earmark time slots at the beginning or end of a day to avoid interrupting their ‘maker time,’” says Loftesness. “An hour at the beginning of the day is much less expensive than a half an hour in the middle of the day.”
Build yourself an "event loop." An event loop is a management checklist to run through periodically — every day, week and month. “The objective is to ensure you’re making time for the important activities that can get lost in the noise,” says Loftesness. “The weekly and monthly ones are particularly tough because you cycle through less frequently, but they’re as important to make a habit.” Here’s an example of an event loop for an engineering manager:
To be effective with an event loop, block time on your calendar to revisit and answer each set of questions according to their designated frequency. If you need to reschedule or delay it, that’s okay — at least it’ll be a conscious choice and give you opportunities to reprioritize, if necessary.
In some cases, it’s best to not kick the can down the road. “During the recruiting cycle, daily event loops can be helpful. At these times, there's very little that's more important than closing that awesome candidate,” says Loftesness. “Yet, it's really easy to postpone sending an email to the applicant until after the next meeting. But if you block off time, you’ll get to it.”
Days 61-90: Assess yourself: Do you actually want this?
The final month of the 90-day plan should be all about candidly measuring your potential as a manager. There are two areas to nail down: First, you should be able to articulate the strength and career direction for each of your reports. Second, you have produced concrete evidence that you are able — and motivated — to be an engineering manager. Here are the questions Loftesness asks his new managers to answer to assess themselves:
What is the unique about each team member and your plan to capitalize on it?
Loftesness has adopted this question from Marcus Buckingham, author of The One Thing You Need to Know, to gauge if a new manager has identified the unfair advantage of each member of her team. Give yourself one minute to name it per person. Next, you should be able to articulate how you plan to capitalize on each talent to help your team win and get them to where they want to go in their career.
“One of my engineers was very casual with designing software. He would speed through the design phase and slap the implementation together. But then I realized why,” says Loftesness. “He was brilliant at debugging software. He charged through everything so he could start to debug.” The engineer’s lack of motivation to improve his software design was detrimental to the team and product, but his unique talent was instrumental to their success. So Loftesness created a “firefighter” role, in which he could debug full-time.
At times, the cases are less straightforward. Engineers may exhibit a unique talent that is beneficial to the team, but not their career. “One engineering manager, Glen, was spectacular at his job. He was self-aware and clear with his expectations,” says Loftesness. “His most outstanding skill was his ability to recognize a key issue for the team and act quickly. At one point he wrote a clear outline of his expectations for code reviews for his team, and almost immediately, there was a measurable increase in the team’s output.”
Glen was beloved by his team, but he chose to go back to being an engineer. He realized he loved developing code more than people, despite being effective in both roles. In the end, it was more important to Loftesness to keep Glen motivated and at the company, than unhappy and looking elsewhere.
After 90 days, if you’re not able to answer what’s unique about each member of the team, you haven’t had the right conversations or asked the right questions.
Reflect on whether you fell short because of skill, time or motivation. If the former two reasons, make adjustments to improve. If the latter, that is also an important realization — the role may not be right for you.
Is the team actually delivering results?
While the first question is about individuals, this question is about their coordination as a team. Here are a few concrete questions to answer to evaluate its performance:
- How's the quality of the software been? Is it improving or not?
- How have they been doing with their milestones?
- How's the team morale?
After 90 days, managers should be able to assess any areas that need improvement. If they can’t address it immediately, they should have an idea of where to get started. If not, it could be that they aren’t cut out for the role.
Of course, delivering results is most critical for the company, but understanding how it was done should be of equal interest to the manager. “Dig deeper behind whether they’ve met their milestones. If your team has missed deadlines, did you pack too much work into a milestone because of the skillsets on the team? Which types of deadlines do we miss and why?” says Loftesness. “It’s not only about how many miles you’ve clocked, but how your engine’s running.”
Can you see where you're starting to add value?
“Each new technical manager has a slice of responsibility — from reducing cost in some area or increasing the top of the funnel for customer growth — that feeds into something meaningful for the company,” says Loftesness. As a new manager, you’ve likely come into the role because that responsibility was broken or at a breaking point.
Sometimes that entry point helps you benchmark progress and other times you’re still getting your bearings. Either way, after 90 days, you should start to see concrete evidence of where you can have value. If you’ve made improvements and have been able to address what got you the job in the first place, that’s success at this stage. If not, you should have a plan of how you’re going to get there.
How many evening and weekend hours are you working?
“There are many reasons why new technical managers are in overdrive at the beginning,” says Loftesness. “They are excited about the new role, the learning curve, or developing a team. They may work into the night and through weekends.” After 90 days, start to ask yourself: Are you putting in extra time because you’re excited or doing it because this is your new life?
Quantifying your “after-work” hours is a simple gut-check to test your happiness and the sustainability of the role. How are you going to feel in a year when you’re still sacrificing your weekends? That may be a sign that it’s not going to work out.
At the same time, don’t give up too early. Just begin checking-in with yourself after two months. “Honestly, I’ve only seen one manager who was immediately happier as a manager than as an engineer,” says Loftesness. “The transition from engineer to manager is a foray into the the uncomfortable and new.” So start by asking yourself if it’s sustainable, not if you’re happier. At the beginning, it’s more realistic to be on a path to happiness, than to be happy.
Day 90: Resolve to Step Up or Aside
On Day 90, a new manager should have had enough runway to decide to move ahead or transition out of an engineering leadership role. If you haven’t passed the tests from the previous 90 days — or don’t have interest in passing them — it’s time to step aside. If you have or see a concrete path forward, congrats! Your work is just getting started.
Here are Loftesness’ suggestions for making the decision:
Put Day 90 on your calendar.
As a fan of blocking tasks and priorities on calendars, Loftesness encourages new managers to flag Day 90 on their calendars after their first day on the job. “It’s important that a young technical manager sees a checkpoint on the horizon,” says Loftesness. “Day 90 is the go/no-go decision.” Block at least a few hours to gather your thoughts and reflect on your own, and another hour to discuss with your boss.
If not, step aside, not down.
There could be a host of reasons for not wanting to manage: a stronger love of coding, a wrong motivation, no sustainable path to happiness. They are all valid and important to act on. “Don’t think of it as stepping down, but rather focusing on your strengths and what motivates you,” says Loftesness. “You shouldn't take an ego-beating if you step down from the role. It’s really important to recognize that something isn't working for you and to be able to step back to, hopefully, the thing that you love.”
Organizations should have tracks for both management and technical up-leveling. “It's most dangerous at companies where management is further up from engineering on the ladder,” says Loftesness. “Talent should have the ability to move from technical to management ladders and keep the view from their rung. They should feel comfortable taking opportunities without losing seniority. Companies also benefit by grooming more well-informed, multi-faceted employees, who know much more about how the organization works.”
Companies can make it easy for engineers to try on management by downplaying the transition from the beginning. “Creating a safe and effective Day 90 for technical managers starts on Day One. Don’t make a big deal about an engineer’s transition to technical manager,” says Loftesness. “If a company sends out a company-wide announcement, calls it a promotion and extends a public congratulations, it makes it harder for the engineer to step aside — even if that’s the right decision for the person and the company.”
If yes, there's a ton more to learn.
If you find that management suits you, you’re still at the very beginning of a long journey with a lot of room to grow. Here are Loftesness’ next tactics to to jumpstart your management education after Day 90:
Focus on enhancing strengths, not fixing weaknesses.
“It’s a common trap for new managers to focus on fixing their engineer’s weaknesses than enhancing their strengths. The upside from improving someone's strength is typically greater and more likely to stick than the upside from addressing a weakness.
Parse personality and performance.
“When new managers give critical feedback, they can easily end up criticizing something that's part of their engineers’ personality.” If they’re a loud mouth, they won’t suddenly stop. If they are good at something, you may opt to tolerate it. So your approach should be how they can be a loud mouth without it being harmful to the team.
Find your truth-teller.
Throughout his management career, Loftesness has always found the truth-teller on his team. It’s the person without a filter that just says what's on his mind. “Sometimes the person will give it to you straight directly, and other times the truth-teller will say it in a group setting,” says Loftesness. “Don’t react poorly to their public challenges.
Understand that the more senior you get, the harder it is to hear the truth on the ground. If you’ve found someone who’ll give it to you unfiltered, tell them: ‘Hey, I love having you on my team because you give me this raw feedback. That's a special job for you — I want to hear what's going on.’ That can be really rewarding for that person.”
Lengthen your syllabus.
Through the years, Loftesness has collected his favorite guides for management leadership. If you’ve already read his first set of recommendations listed above, add a few more, such as Slack by Tom DeMarco or “What Are The Primary Traits of a Great People Manager” by Joe Xavier.
Whether through management books or mentors, there’s a lot of effort behind the decision to be an engineering manager — and even more diligent work to be a good one. Over the course of 90 days, it will involve a sequence of steps, including meeting with mentors, blocking time to study up on management and identifying the unique attributes of everyone on your team.
What’s most important is to commit to management exclusively, channeling the singular focus you once dedicated to coding. If you try to be a jack of all trades, you’ll be a master of none. Referencing a post by GaiamTV Product Director Jesse Weaver, Loftesness says, “Don’t be a Swiss Army knife, with its many partially helpful tools. A sommelier won’t use the mini corkscrew. A lumberjack won’t benefit from the little saw. Commit to being a manager and stick to your plan."