Three years ago, Jessica McKellar and a group of friends from MIT started stealthy chat startup Zulip. Less than two years later, it was acquired byDropbox. And this wasn’t an anomaly. They’d done it once before, selling Ksplice to Oracle just as fast. This wild ride has given McKellar a more diverse set of management opportunities than the average engineer ever sees—she’s been a team lead, a founder, a technical leader at a massive corporation, and today, is the manager of dozens at a rapidly growing global startup. (Oh, and on the side, she’s a major figure in the Python community.)

“When engineering management is done right, you’re focusing on three big things,” she says. “You’re directly supporting the people on your team; you’re managing execution and coordination across teams; and you’re stepping back to observe and evolve the broader organization and its processes as it grows.”

This can sound simple, McKellar says, but each of these areas comes with its own deep complexity and challenges. To boil it down, she shares the actions she’s seen create the most impact for technical leaders and the people they manage.

What it means to directly support a team

“When you’re a technical manager, your job is mostly about humans,” McKellar says. “There are two things you should always be thinking about: People’s day-to-day and their year-to-year.” You should imagine every individual is traveling on both of these tracks at the same time. And as a leader, you can shape their experience on both to help them find a trajectory that meets their goals and your needs.

“On the day-to-day front, you want to make sure that everyone is happy, productive, and engaged in their work,” she says. “This includes meeting with people regularly one-on-one and making the time and space to talk about any smaller issues they have or roadblocks in their way. It means whiteboarding a project to break it down into chunks, or walking a lead through a tricky interpersonal situation, or putting everything on pause to take a walk with someone who is having a tough day.”

You need to balance the efficiency of a structured weekly routine against having the unallocated time to give and receive feedback about the work in real-time. This alone can make you a very effective day-to-day manager.
The greater challenge is helping people devise a long-term plan for happy productivity at your company.
The greater challenge is helping people devise a long-term plan for happy productivity at your company. There are many factors that go into this, McKellar says. But to simplify, half of it is raising people’s awareness about what they want to do, and the other half is working that into everyday routines, planning, and projects.

“You have to be intentional about working career growth into your broader engineering planning and execution of projects coming down the road,” she says. The really difficult thing is that not very many people have a clear sense of what they want from their job, and even when they do, they aren’t forthcoming about it with their managers. Good leaders are experts at surfacing this kind of data and making it actionable.

“To develop a long-term relationship with an engineer, you have to learn enough about them to provide a framework to think through their career growth together,” she says. “You want them to articulate 1) the skills they want to improve, 2) the technical and non-technical experiences they want to have, and 3) how they want to increase the scope of their impact at the company.” Once they’re able to communicate these things clearly to you, you’re much more likely to find the right opportunities for them. And they’re much more likely to recognize them.”

Once a quarter, I’ll say, ‘Okay next week is career growth week,’ and that’s what we’ll talk about during one-on-ones.
Having an explicit framework for how people can grow at your company helps individuals envision their future and how you can help them get there.
“To unpack this information, you need to break things down into smaller pieces. You may want to know what someone wants to be doing in five years, but that’s a huge ask. And there’s this unspoken pressure to seem like you want to be at the same company,” says McKellar. “The only way this works is if everyone can be honest and authentic with each other. If you’re the manager you have to set this tone. Make it clear that it’s fine and safe for them to say they want to eventually go somewhere else or do something different. I try to position it as, ‘Are I and Dropbox doing the right thing to set you up to have the experiences you want to have to do what you want to do next?’”

To help people open up, McKellar says she has to first be honest about herself and her own career motivations. She usually starts these conversations by giving them an example of what she hopes to accomplish.“If I’m asking people about the next five years of their life, I should know what I want to do during that time. It’s not fair otherwise.”

In addition to transparent discussions, having an explicit framework for how people can grow at your company helps individuals envision their future and how you can help them get there. This type of structure is especially helpful when working with engineers who are used to concrete career tracks.

“Dropbox has gone through this exercise, and we do have two explicit, fully parallel tracks: One for technical contributors and one for people interested in management,” says McKellar.

It’s a shame when companies force people to move into management as the only option for career growth. It’s a clear mistake.
It’s a shame when companies force people to move into management as the only option for career growth. It’s a clear mistake.
For these tracks to work, people need to know which one they want to choose. The best way to counsel people through this is to ask them about what kind of change they want to make for the company. Separate the question from typical ideas of success or what people believe they should do. Instead, find out which problems they really want to solve.

“For engineers, one way to increase your impact is to architect and own increasingly complex technical problems—problems that have high technical risk or require novel solutions,” says McKellar. “This is the kind of person who will probably be happier as a high-ranking technical contributor, and the way to start them down that path is to just throw them into the deep end of the pool—with the right mentorship and guardrails—and have them start solving increasingly complex problems today. We can always course correct together along the way, but they have to just dive in and start having and growing through those experiences.”

Alternatively, people who enjoy the human side of the equation, coordinating efforts across teams, jumping on opportunities to mentor others and create culture and community, may be better suited for the management track. The type of problems they like solving will fall more into those buckets. They may be really passionate about recruiting or diversity or building bridges between teams that weren’t working together previously.

“A lot of companies don’t have any indicators or framework for recognizing those little things outside of someone’s main job description,” says McKellar. “It’s really important that whatever resources exist for career growth accurately account for and recognize these things. If you don’t recognize them, people won’t do them. The incentives won’t be aligned, and some people may not discover a future at your company that excites them.”

As a leader, she does her best to capture all of these smaller actions her team members take, spot patterns or trends, and develop a sense of the problem areas that interest them most. These observations form the basis of the conversations she has with the engineers on her team, allowing them to chart the future together.

Your team’s capacity = Your executional ability

Nearly all engineering managers remember their pivot—that moment when coding was no longer the number one priority. “I was an engineer and tech lead before moving into management, and I remember those early moments having to make the trade-off between writing the code myself and empowering someone else to do it,” says McKellar. “There’s something really satisfying about directly, personally architecting and writing the code that will delight users.”

There’s an inflection point when someone moves from engineer to manager, and it can feel very uncomfortable—like you’re only in meetings and not getting anything done.

But the trade-off in stepping back from the code is that you then have the time to gather broader organizational context and execute on more strategic organizational investments, she says.

“At Dropbox, I have the opportunity to zoom out and think about the way engineering is done more broadly—the way we plan, the way we’re structured organizationally, whether our tools set us up for success,” McKellar says. “Now if I spot an inefficiency, I have the time, space, and global context to fix it.”

Keep this truth top of mind: If you can help the people on your team grow their individual capacity, you’ll be able to get exponentially more done. This is all about matchmaking them with high-impact projects that align with their interests, the value they want to create, and how they want to grow. That’s when motivation becomes organic. As a manager, you first need to have the answers to these questions.
If you can help the people on your team grow their individual capacity, you’ll be able to get exponentially more done.
“Some people are really driven by speculative prototyping work that they get to iterate on really quickly even if half gets thrown away. Some people really love building a stable product that they know 300 million people will use. There’s a range of motivations. You want to figure out what people’s natural inclinations are and use that to give them a project where their work will be optimal,” she says.

Recently, McKellar worked closely with an engineer on one of the teams she managed, and they would have the best one-on-one meetings. He made many observations about the way Dropbox organized and approached engineering, and he’d bring up things he noticed about their tools that could be better.

“During one of our meetings, I just said, ‘Hey, it’s clear you really enjoy thinking about these things. What if you could think about them a lot more of the time?’ I told him that there would be a trade-off, but that it sounded like he’d enjoy stepping away from the code.” Now that engineer manages his own team of technical talent. “You could tell he was thinking like a manager already,” she says. “It was just a matter of providing a stage for him to transition into that role.”
You need to develop local experts within teams, projects, and platforms who can think deeply and guide architectural discussions.
To recognize high-caliber people who want to stick closer to the code, McKellar makes a point of empowering her tech leads to make decisions on their own. Not every organization does this because tech leads don’t necessarily have anyone reporting to them, but she believes this is crucial for companies to grow.

You need to develop local experts within teams, projects, and platforms who can think deeply and guide architectural discussions.

“I’m not in the code base anymore. It would be totally inappropriate for me to be making those types of decisions.” McKellar says. “You really need to hand over a lot of trust in order to be as effective and efficient as possible. You have to trust your tech leads to do what they need to do to scope and architect and break down and execute on complex projects. It’s really tempting to jump in—to chime in on code reviews or architecture discussions. But, really, you have to give people the space to grow into these responsibilities without having you there as a backstop. That’s the only way you can all keep sprinting.”

The pre-requisite for this kind of trust is acceptance that people can make mistakes and learn from them. Managers are responsible for creating an environment where people feel comfortable failing. Jumping into a project when things aren’t going well can break delicate trust and make everyone more anxious about failure. This should only be a last resort. Instead, there are smaller interventions to consider—for instance, managers have the power to eliminate distractions and encourage good engineering habits.
Managers are responsible for creating an environment where people feel comfortable failing.
The most transformative of these habits—especially as it relates to failure—is running instructive, actionable post mortems. “As a leader, I need to provide the time and space for the team to reflect on why a project played out the way it did,” says McKellar. “It’s not about telling people what went wrong. Let’s say we really, really missed a project deadline. We need to take that time to figure out what we can do differently next time, and what organizational or process changes could have made the difference. I’m there to facilitate the discussion and generalize it in a way that can be communicated to other teams.”

The other major thing you can do as a manager to set up strong guardrails and super-charge learning: Maintain a balance between more experienced and less experienced engineers working together and regularly sharing knowledge. You want to build in opportunities to make sure these conversations are truly bi-directional.
You want to be leveling up everyone on your team all the time. Execution will follow.
“New folks really do bring a fresh perspective and constructively question the right way to do things,” says McKellar. “New engineers don’t accept that certain things have always been broken, which is really healthy for your organization. And on the flipside, experienced engineers bring good habits and discipline to deconstructing projects.” You’ll have a certain amount of cool projects to give out all the time. Distribute them evenly between the two.

You want to be leveling up everyone on your team all the time. Execution will follow.

Accelerate people with the right tools and process

One of the reasons McKellar is excited to be at Dropbox is the size of the product and the challenges that come with it. “We’re tackling infrastructure and product questions that usually face much larger companies,” she says. “That means that every engineer at Dropbox has the opportunity for huge ownership and impact. We don’t have time to waste on things that aren’t important.”

At the same time, it means that automation, tools, and scalable practices are that much more important. This is a layered proposition for McKellar, who manages both team leads and a team of engineers herself. Planning is critical for both.

“For the team of engineers, I’m very involved in sprint-level planning for the team,” she says. “There’s a process designed to engage everyone not just about the project at hand, but about how that factors into their future too. I have very explicit conversations with the people I work with about how they want to grow as engineers. That gets written down and incorporated directly into the planning process.”

McKellar is often asked how she can possibly remember and keep tabs on everyone’s goals. Her answer: “I live and die by my calendar. I literally add calendar events about checking in on career growth for every person. That way there’s no way I can forget to check in or give it thought.”

Part of this system is taking note of the really challenging, high-impact projects that have the potential to elevate people within the company. “Ideally, you want to help everyone stretch their skill sets in a really positive way all the time. You want to find a way to assign them projects that require them to learn something new or do something differently or take on a bit more responsibility,” she says. “This can give people a ton of momentum if they have the right guardrails.”

In this context, guardrails come in the form of the right environment, regular check-ins, and organic motivation.

Environment

As a manager, providing a productive development environment entails everything from procuring the right tools to balancing new feature work against investing time in improving existing projects. It also includes a smooth onboarding process for new engineers that helps them find their bearings, defines what success means, and makes it clear how performance is measured.

“Onboarding is one of the most powerful tools at your disposal as a leader,” McKellar says. “You’re not only helping new engineers figure out what they want to do and claim ownership, you’re also giving existing employees an opportunity to mentor and share what they’ve learned.” You don’t want to lose sight of that second benefit because that’s how you identify future managers and growth trajectories.

Check-ins

“If you’re architecting a large system, you’re not doing it in a vacuum. We emphasize an architecture review process that ensures that the right stakeholders are in the room and that people are getting feedback from the right people,” McKellar says. “Before an engineer sets off on a super ambitious nine-month project, there have been multiple checkpoints validating the plan, answering the important questions, testing for feasibility.”

You want the people on your team to be getting feedback in a number of ways. “Code reviews are especially important for capturing technical feedback at a fine level of granularity. Planning discussions and architectural reviews tend to provide feedback at a higher level.”
One risk with process is that it can replace a more tailored approach to management.
You want systems that both catch when a comma is missing and get people to think more broadly about what good architecture looks like.

One risk with process is that it can replace a more tailored approach to management. If things become too automated or too reliant on scheduled check-ins, you can miss something important.

“As people level up, their needs change gradually,” McKellar says. “With new engineers, you need to be proactive about communication and finding out where they’re blocked. Experienced engineers usually know how to raise issues themselves.”

To make sure she doesn’t lose sight of these distinctions, she focuses on generalizing the areas that could benefit everyone, and using the time saved to provide personalized attention.
Transparency is a serious accelerant.
“Everyone can benefit from you removing distractions, ensuring that they have large chunks of uninterrupted ‘maker time,’ helping to debug inefficiencies in intra-team communication,” she says. “A classic example is a really long email exchange on some technical topic with no resolution. Put everyone on the thread in one room together for 10 minutes and the issue gets promptly resolved.”

Transparency is a serious accelerant, and McKellar capitalizes on it. While some leaders in the tech industry believe they need to shield their teams from things going on at the executive level to prevent distraction, there’s a fine line between productive shielding and unintentionally denying engineers important company context. You want them to feel included and invested in the direction of the company. “Not enough is communicated to engineers generally speaking, so my mentality is to surface the information I have in meetings, check-ins, reviews, whenever I can. Default to over-communicating.”

Motivation

People don’t naturally think of motivation as a tool or a so-called guardrail, but it goes a long way toward keeping people driving toward a goal. There’s no better tool for overcoming serial failure. The rub is, while managers can supply energy and do their best to keep spirits high, the most effective type of motivation springs naturally from well-matched projects and people and commitment to the company at large. This is where leaders should focus their efforts, McKellar suggests.
The most effective type of motivation springs naturally from well-matched projects and people and commitment to the company at large.
“People always get revved up about taking on the next big thing. The harder part is wrapping up that final 5% on a project you’ve been working on forever,” she says.“That’s where you want someone who is fiercely interested in the work and thoroughly understands where Dropbox is coming from. As a brand, we have this commitment to always shipping something delightful, and that takes a lot of elbow grease in that final 5%.”

To keep people charging hard toward goals and deadlines, McKellar says managers should help engineers see their work through the lens of their impact on the company. Especially if they’re someone who really values their visibility and making a difference at scale. “Half of this is about having a team on the project that really, really cares about the foundational work it’s going to take to deliver something truly great. Half of it is about recognition. No one is going to do really gritty foundational work if it never gets recognized.”

A thoughtful engineering manager recognizes all hard work, especially if it’s not super flashy.
A thoughtful engineering manager recognizes all hard work, especially if it’s not super flashy.
At Dropbox, a lot of organic motivation stems from the company’s emphasis on really high-quality, seamless user experiences. In large part, its competitive advantage is that its product is so simple, light and ‘just works.’ “This is the kind of value that makes it easier to motivate that final 5%, because that’s where the user delight comes from. That’s why people love the product.”

As a final thought for engineering leaders, McKellar says they should keep an eye out for company-wide values and tenets that have this type of operational power.

You can spot them because engineers often give them as reasons for wanting to join the company in the first place. They should speak to the kind of engineer they want to be now and in the future—the kind of engineer that has grit, that pays attention to the last detail, that wants even the code to be beautiful. Great technical managers tap into this spirit to move people to do their best work.

This post originally appeared at First Round Review.