How to Build a Culture of Ownership, and Other Engineering Leadership Tips from Plaid & Dropbox

’s engineering management philosophy can be summed up in just one word: pragmatism.

“When I was younger, I really liked the idea of building a perfect system and engineering something really perfectly. And that’s nice in the world of computer science and engineering and in the abstract, but pragmatically, you’re at a company with a budget,” says Grèze, Head of Engineering at fintech startup 

. “You have a timeline by which you need to deliver something, or your competitors will deliver something faster. You have a lot of constraints. 

And in that world, great engineering is about solving business problems faster and better than your competitors can — and that just boils down to pragmatism

Before joining Plaid, he served as Director of Engineering at Dropbox. But he’s got a theory that his pragmatism goes back even further than that. After studying computer science back in undergrad and even starting his PhD, Grèze took a sharp left turn and enrolled in law school. And while he calls his journey to becoming a lawyer a “four-year detour he probably didn’t need,” he picked up a few powerful lessons.

“What I learned from that experience is that I love building things with computers, and the worst day I have as an engineer is better than the best day I had as a lawyer,” says Grèze. “The second thing I learned in law is that I’m not that smart. Before going to law school, when I was an engineer, I was an obnoxious know-it-all, who thought he had the right answer to everything.”

That window into the legal world began to crystallize this pragmatism versus perfection ethos. “Engineering and math can make you feel like there’s one right answer to everything. But the reality is in real-world engineering, there’s no right answer. There’s always a range of answers and they have tradeoffs. What’s really important is 

convincing other people to align behind one answer

. That’s what I learned in law school,” he says.

It’s not a world of black and white — being a manager is about getting groups of people to align on a path through the gray area.

In this exclusive interview, Grèze unpacks his advice for the five biggest challenges engineering leaders face — from crafting an ownership-driven engineering culture and aligning on a single galvanizing KPI, to honing his hiring ethos. He also gets incredibly tactical on how he approaches team motivation, navigating the seismic shift to becoming a manager-of-managers, and why he prefers folks on his teams don’t have titles. Grèze pulls on threads from across his career to weave together a modern playbook for engineering leadership — and the hard-won lessons from Plaid and Dropbox that stick with him.

ENG LEADERSHIP CHALLENGE #1: HOW TO CRAFT A BOTTOMS-UP CULTURE OF OWNERSHIP FROM THE TOP.

When Grèze reflects on the commonalities across great engineering managers at both Plaid and Dropbox, one “It” factor jumps out. “Both companies shared a value of ownership. The best leaders act like no problem is outside of their purview. It doesn’t matter if it’s a business problem, a design problem, an engineering problem, or a legal problem. They push through and find a way to get groups of people to solve the thing,” he says.

And while ICs may not have that amount of cross-functional influence, Grèze is adamant that this same ownership mentality can and should be applied to their own spheres of influence. “On the IC side, I see ownership a bit differently. I think of it as a little more constrained to your immediate project — making sure everything gets done on the things that you can control,” says Grèze.

But like any cultural ethos, this doesn’t happen by accident. “It might be surprising that my most common answer to a lot of organizational issues that come up is to just say, ‘Hey, that’s great, why didn’t you tell [insert the name of the right peer] about it? You need to solve it with that person.’ I want the leaf nodes across various functions to 

figure out 90% of the more difficult things on their own,

It’s a team-wide habit he’s constantly reinforcing.

I write multiple emails a day that basically say, "Thanks for telling me, I appreciate this as an FYI, but I don’t understand why you and this other person can’t solve this on your own.

Cut through complexity from the bottom-up.

Grèze peels back the layers to why he believes so strongly in this approach for the API company. “Plaid is interesting because we have three very strong stakeholders for almost everything that we do. On one end, we have financial institutions. On the other end, we have developers. And on the third end, we have consumers. That complexity can be very costly because you generally don’t want three stakeholders for all decisions that you make. The incentives are not the same for each of those groups,” he says.

There’s one thing I believe in really strongly for Plaid right now, which is that we will succeed if we’re really bottom-up in our approach to problems.

“At the unit level, if every time someone runs into a problem it goes up to me, the cost for me to understand the specific problems with those three stakeholders, as it applies to whatever the product is, it’s ginormous. It’s just way too complicated. But for that team on the ground, they actually have all the knowledge that they need. When they push it up to me, I don’t have any additional insights. The world is just too complicated for me to chime in,” says Grèze.

He’s got a clear directive for the problems to up-level. “The only questions I want to go up to me, frankly, are questions where 

allocations of budget or people is a hard trade-off

. If we don’t have enough people to both make customer set A and B happy, that’s my job. Let me work with our CEO and figure it out. 

But otherwise, I want the units as low to the ground as possible to learn how to deal with that complexity on their own, because that’s how we’ll move fast

Scaling bottoms-up and embracing cross-functional arguments.

Grèze flags a couple potholes where he’s also seen things go sideways. “As Plaid grew, the number of things that weren’t solving themselves bottom-up kept increasing. It took us a bit of time to recognize that this stuff used to solve itself, why is it not happening now?” he says. “EDP worked really well together, but the membranes between EDP and go-to-market weren’t very fluid. People would share information, but the decisions weren’t being made,” says Grèze.

The diagnosis may surprise you. “The interesting root cause behind that actually comes from a lot of 

You kind of assume that the other side is doing the right thing and you trust them. But that means you haven’t built a muscle for arguing with them

He sketches out an example. “We have a really strong legal team, and every time legal has done anything, the quality of that work has been A+. But that also means no one’s used to asking legal if there’s a different way to approach and solve a problem,” says Grèze.

“It comes from a good place. Who doesn’t want to have strong functional identities and a lot of respect for your coworkers? These are all positive qualities, but you’ve got to see them to their logical conclusion. 

where things that are good at one stage don’t end up being good at the next one

That’s the fun part of management. You identify the problem, you talk to peers, you make a mistake, eventually you solve it, you move on — and something else becomes not as good as it should be. You keep moving forward.

ENG LEADERSHIP CHALLENGE #2: HOW TO MOTIVATE FOR TACKLING BIG PROBLEMS AT SCALE.

Grèze points to two key areas where he thinks 

: metrics and values. This yin-and-yang balances the quantitative needs of the business with the qualitative, less-tangible aspects of human nature.

“The easiest way to get clarity on impact is to have a KPI where it’s easy for people to understand how their work lines up to the KPI,” he says.

Grèze outlines an example from Plaid from the earliest days when he joined the company. “Every engineering meeting, every all hands, we talked about the percentage of users on Link,” says Grèze. “Link is part of our SDK that’s embedded in the apps, web and mobile that developers use for building on Plaid. Before, you either built your own UI or you used Link, but we realized it was better for end consumers and for developers longterm for everyone to be on Link.

Here’s why it worked: “It was really clear — 

. Every single team could look at that KPI and say, ‘Is the work I’m doing going to drive this metric? Is it going to make it easier for developers to adopt Link? If so, is it the highest ROI thing that I can do?’” he says. “Just the fact that we had that metric made it a lot easier for people to align their work. I’m not saying bad ideas weren’t generated along the way, but they could be considered. And if they weren’t the best way to do it, you had a language to talk about it: Amount of time on engineering spent to get what lift of end-users using Link.”

Create tokens that align with your values.

On the qualitative front, Grèze has seen time and time again that small gestures can have an outsized impact. “I’m a big believer in incentives that align with the culture and values. A funny one that people don’t realize can be super helpful is creating tokens — objects that you reward for a specific behavior," he says. “You can create a subculture around a new value. Humans — we love an object, we love a token.”

He pulls an example from a past team. “We had a model of the 

. It’s this cool 1920’s or 30’s vision of a future spaceship, with a red-and-white checkered pattern. Every two weeks in our managers meeting, we’d share two highlights and two lowlights. Then we’d all vote and give that spaceship to the team that had the most impact,” he says. “There was a ton of pride in being awarded that spaceship as a team, and oddly enough, the spaceship took on a life of its own as a token. When a team was going to launch a new feature, they’d try to make a splash and drive impact so they could receive the spaceship,” says Grèze.

ENG LEADERSHIP CHALLENGE #3: HOW TO BALANCE COMPANY GOALS AND EMPLOYEE GOALS.

“I came into management a little bit later into my career, and the hardest part of management is to manage the times when the expectations and hopes of individuals don’t match the expectations and hopes of the company. That’s when management gets really, really difficult,” says Grèze. Think when a report comes to you with a passion for growing their skills in a particular area — without a clear direction for how that piece fits into the larger team puzzle.

“My solution to that has always been to be very direct with people who report to me. I’m like, ‘Hey listen, Alice or Bob, this project is really important for the business. I know it’s not quite aligned with how you want to go in the next six months, but it’s the most important thing for the business, and let me show you why.’ That’s so much more trust-inducing, reasonable and clear,” he says. “If I ask you to take one for the team now, next time I’m giving you what you want. 

I always put the business first in the short-term and the employee first in the long-term

I have a speech that I give, which is: "In the moment, I will ask you to do what’s right for the business. But over time, I’ll do what’s right for you." Meaning, when there’s that misalignment, I’m not going to let that misalignment last too long.

direct line to the employee’s career goals

? “That’s a tough conversation, isn’t it? If you want to be a manager and you haven’t shown the skills, I need to lay that out: ‘I know you want to be a manager, but if you’re a manager you need to work with different personalities, or you need to deal with ambiguity and I’ve got concrete examples here where you weren’t able to do that in the last six months. I’ll meet you halfway, which could be pairing you with someone who’s good at it, and you get to learn and you get to show me that you can do it,’” he says.

One of his favorite examples is when the needs of the business and the needs of the employee finally coalesced — but it took some patience on both ends. “There was an engineer who wanted to become an ML engineer, but had no experience at all in that space. And I said, ‘Okay, you can take half a day every two weeks just to do ML on your own time, but I’ll ask you to do it at the office and keep me apprised of it.’ And after that, there was a project on the ML team that required someone really junior. It took a year and a half, but eventually they were on that team, doing ML full-time,” he says.

ENG LEADERSHIP CHALLENGE #4: HOW TO BUILD TEAMS WITH HIGH HUMILITY AND LOW EGOS.

 at Plaid, for Grèze it all goes back to the culture of ownership.

A quote from a good friend of mine says, “Great managers have an overdeveloped sense of responsibility.”

“I love that word overdeveloped, because it’s a big burden on your life to worry about a lot of things. But you don’t just stop at the boundaries of your team, you stop at the boundaries of the problem that needs to be solved for the business,” he says.

This is why in the interview process he pushes hard for candidates to give plenty of examples of when they’ve swam outside their designated lanes. Grèze’s got one other 

 that he always leans on. “I ask them to tell me about a time that they failed. I provide more context behind the question so they can be honest with me and tell me about a true failure,” he says. “

50% of people either give you a fake failure that actually makes them look good. And the other mistake I see is they point out a failure, and they clearly haven’t thought about how they would have behaved differently

 if they had a time machine and could go back in time. Basically half the people fail that question and don’t move forward in the process,” says Grèze.

“Most places I’ve worked, I have preferred not having titles,” says Grèze. His reasoning may sound familiar: “The point of a title structure is that people will use the titles internally. They’ll say, ‘Oh, so-and-so is a staff engineer, I think you need to get a principal engineer to review that.’ Or ‘Seems like you need a senior architect for a project of this size.’ Those are the behaviors that I want to stop,” he says.

The danger of titles is that the best idea doesn’t win, and it creates an internal hierarchy as to whose ideas have more merit than not.

Instead, the company assigns tech leads for specific projects. “I like it much better when the process is, ‘Hey, Alice or Bob is the expert in the system. They’re really the person who should be the primary reviewer for your tech spec, because they know a lot about this.’ It doesn’t matter what Alice or Bob’s level or title is — they’re the right person because they know the most and are going to be most helpful for that problem,” he says.

But career levels are deeply embedded in our experiences in the workplace — particularly when it comes to tracking our progress and growth. To strike the right balance, Grèze’s implemented personal, internal levels at Plaid — such as E2, E3, E4, etc. “We have levels, but they’re private to yourself. You know what you are, you can feel the accomplishment for yourself, but because other people don’t know what it is, they don’t look at you differently because of your level,” he says.

But Grèze will admit there are drawbacks. “Recruiting people who love titles becomes more difficult,” he says. And as the company grows, you’re not able to look to titles to navigate increasingly-complex orgs. “Another benefit of titles is that you know who to speak to on another team when you’re looking for somebody who’s an authority. If you have a 2,000-person engineering org, isn’t it nice to know immediately 

who’s the person on that team that I should speak to

But Grèze goes back to that pragmatic streak — and accepts that all decisions have tradeoffs. “I think with things in place like tech leads, we can have a really good 

ENG LEADERSHIP CHALLENGE #5: HOW TO TRANSITION TO BECOMING A MANAGER-OF-MANAGERS.

Grèze’s most recent stint as an IC was over seven years ago, before taking on leadership roles at Dropbox and Plaid. “It’s not just the role of management. It’s managing a bucket of teams or managing a function where you might as well be an alien to the average person on your team,” he says.

Now, the tasks that used to come as second nature don’t quite fit within his day-to-day. “

It requires very different skill sets and approaches

. Right now, if I go and read a technical spec and write comments in it — that’s a disaster waiting to happen. 

Because whatever I write, only a handful of people on the team will feel comfortable telling me that I’m an idiot, just because I’m ‘the big boss,

Over time, he’s needed to adapt his approach, including flexing his empathy muscles. “Most of the things that managers complain about their lead-of-leads or VPs not doing well, actually 

 things that their lead-of-leads and VPs aren’t doing well,” he says. “All the examples that I can think of are: ‘You didn’t communicate to me early enough about this organizational decision or change you wanted to make.’ Or ‘You didn’t provide clarity on the strategy or what I should by optimizing for, and then you’ve decided to kill the team because it’s no longer right for the business, and I feel like it came out of left field.’”

It’s really hard and it takes a huge amount of time to communicate with all your managers about everything. There’s so much context sharing. Every time I get in a situation where someone’s unhappy, I realize I could have just communicated about this more and earlier.

Stop us if his example sounds familiar: “You send an email to six people, and then you realize you forgot somebody. Now you know that if you forward the email to them or add them afterwards, you’re like, ‘Ugh it’s going to hurt their feelings or their ego because they should have been on the email initially,'” he says. “You kind of wish everybody understood the big picture, because you’re trying to do right by the big picture. So whenever you miss the communication and someone gets offended you’re like, ‘Okay, I forgot to include you, but you should understand that I’ve got 250 people to keep track of.’”

Over time, that knee-jerk defensive instinct began to fade. “You think about it for a few seconds and you realize, ‘Oh my God, no — my one and only job is to globally set everyone’s expectations correctly and to communicate to them.’ Just the fact that they’re offended reflects that, in general, you’re not doing a good job of keeping them informed such that you even had to draft the email in the first place. Or in the past you’ve made them feel not included in the conversation,” says Grèze.

Spot the right signals, and ignore the wrong ones.

Just as Grèze doesn’t call for his reports to understand all the challenges from his perch, he doesn’t expect to grasp what’s entangling those a few layers down. “It’s been a long time since I was an IC. I don’t recall that much about what was difficult or easy at that scale anymore. There are times when things don’t happen and I don’t understand why they’re not happening. But that’s because I don’t remember what it’s like to be in those positions and how difficult it is to deal with certain classes of problems. 

I’ve forgotten the problems as much as the solutions

 Grèze keeps an eye on annual goals, churn, hiring rate, pulse surveys and how the teams are trending towards KPIs. One thing he refuses to check in on? Hours spent in the office. “Is the business hitting its goals? Is it okay with how much money is being spent on engineering? And if the answer to both of those is yes, do you care how many hours people are working? I don’t care how many hours people are in the office. I don’t use GitPrime to measure productivity,” he says.

“What I look at is the percentage of our OKRs that are green, and I use a very simple feedback cycle. 

If you’re green on 90-95% of your OKRs, I would like for you to be more ambitious next time. And if you’re green on 50% of your OKRs, I would like for you to be better at estimating and more realistic about what you can do the next time around

To fill in the gaps between what the KPIs can’t tell you, Grèze leans on his management squad. “There’s a dozen metrics that I look at, but for each of my managers it better be art and not science. They need to understand the morale of their team, not just from their pulse scores, but from the 1:1s they’re having,” he says.

WRAPPING UP: WHAT’S NEXT ON THE HORIZON?

“There’s a lot of ways to create a culture in a company. 

My observation on Silicon Valley is that we’re all operating at a local maximum of what great engineering could be

“When you think about it, we’re all learning from Google, right? There’s Google managers, and then they go to Dropbox, and then the people who learn from them go somewhere else. Then you have managers from Facebook — same thing. And then you have the Amazon tree, the Microsoft tree, the Netflix tree — all these trees,” he says. “There’s these templates about how you build companies and how you build engineering teams that are passed down. But if you look at the origin of the templates, it’s just a few companies.”

Overall we’re at the infancy of how you build great software. Yeah it’s been 60, 70 years. But compared to building bridges, we’re still at the infancy of this world.

“I think it’s exciting. We’re still learning and playing with things and seeing what really works. 

There’s a lot of variety of things that need to be tried

Grèze points to an example most are plenty familiar with after the past year. “The distributed teams that are happening right now, it’s forcing people to consider different ways to make decisions that would never have happened otherwise. It’s forcing us out of our existing set of practices, and it might be for the better. You might come back to in-person and have learned a bunch of things from remote work. 

There’s a big market for being slightly more efficient at building a company

This article is a lightly-edited summary of Jean-Denis Grèze's appearance on our new podcast, "In Depth." If you haven't listened to our show yet, be sure to 

Cover image by Getty Images / Felix Cesare.

Building a Culture of Ownership — Engineering Leadership Lessons from Plaid & Dropbox

Jean-Denis Grèze has led engineering teams at Plaid and Dropbox: Here’s what he’s learned about crafting a bottoms-up culture, hiring and motivating large teams.

Plaid's Head of Engineering Jean-Denis Grèze unpacks the 5 biggest challenges engineering leaders face.

 likes to say that her path into engineering management was in some ways gradual, and in others, a wild ride full of challenges at every twist and turn. Her first taste of life as an engineering manager came at Facebook in 2011, on what she describes as a tiny team. “It was three people — including myself,” says Yung. “The day-to-day wasn’t all that different. I was still diving into code, but balancing that with learning how to recruit and hold 1:1s.”

Then the wild ride began. Yung had to strap in as her team took on more in scope, growing from three to thirty, and beyond. “I moved on from reviewing code to owning company metrics and building teams in multiple offices,” she says. By the time Yung left Facebook in 2015, she was the youngest engineering director at a public company with over 10,000 employees — several rungs up from where she had started, as a new grad at the then 700-person startup.

Yung then took on a challenge of a different sort when she joined Stripe. “I wanted to see if I had what it takes to be a great leader in a completely different environment,” she says. (Spoiler alert: she did.) In her nearly four years at Stripe as it scaled up from 200 to over 1500 people, Yung built the product management team, defined career growth and recruiting frameworks, ran the core Payments business, and spun up the company’s global engineering hub in Singapore.

Taking a front-row seat on two very different startup rides left her with a clear takeaway. “

Personal growth is compounded by company growth

. At Facebook, I focused on learning as much as I could from the experienced leaders who were joining as we grew. At Stripe, 

 was one of those leaders, tasked with figuring it out and teaching others,” Yung says. “I had to learn from piloting new internal programs, reaching out to peers and former managers for advice, and seeking out coaching and training.”

She translated this crash course into a lot of heads down writing time, producing 

Stripe’s Atlas guide to scaling engineering teams

 (which covers everything from 1:1s to performance reviews). After a decade of working at explosive growth startups, Yung left Stripe to take some much needed time off and carve out white space to continue sharing what she’s learned.

And she’d like to train her focus on one subject in particular: 

. “Most of the advice you hear is about advancing quickly, not stopping to soak up all you can,” she says. In this exclusive interview, Yung shares a collection of counterintuitive career lessons, the ones she learned the hard way. She also dives into why the IC and management tracks aren’t parallel ladders, but rather intertwined steps. Finally, she covers more specific roadblocks that can appear at every stage of your engineering career, as well as guiding questions that can serve as a gut-check as you seek to push them aside.

With both broad lessons and targeted advice for different career phases, there’s plenty of wisdom to mine here. Whether it’s the young engineer peering around the corner to get a sense of what lies ahead or a seasoned leader trying to wrap their arms around increasingly thorny technical and managerial obstacles, Yung challenges 

 questions as they plot out their careers

Looking for advice specific to your situation? Jump ahead to Yung’s career tips for new engineers, technical leads, domain experts, early engineering managers, more seasoned managers, and engineering org leaders. And get a helpful rundown of her advice here.

THREE CRITICAL LESSONS FOR BUILDING A CAREER AS AN ENGINEER:

There are some underlying themes that can carry you throughout your career — and these three lessons have been the foundation of Yung’s at every stage:

1. Strive to be the most valuable, but least critical.

Most of us would probably be thrilled to be described as “critical” to a project’s success. But in Yung’s experience, that’s dangerous territory for an engineer to be in. Take this example from her time at Facebook. Yung had cemented herself as a company expert on posting permissions, but she was quickly about to discover the drawbacks of being the lynchpin.

“I was training for my first marathon and had just finished a 20-mile run — only to discover that I was being paged for a live incident. I remember sitting in my bathtub fully clothed, somewhat delirious, with giant bottles of Gatorade in each hand and my laptop open, trying to figure out what had happened,” she says. “It was a high and a low point at the same time. I felt so important and needed, but all I wanted to do was rest and get out of the way. I vowed to immediately start transferring as much knowledge to my teammates as I could so they would have the tools to solve problems without me.”

While you’ve probably heard the common working adage to “manage yourself out of a job,” Yung finds that phrasing too simplistic

. For her, it’s less about making yourself obsolete, and more about making yourself less critical.

When you’re critical to a project, you’re playing a decisive or crucial role in the success, failure or existence of something. As leaders and engineers, we’re all in this position at some point. But you can’t stay there. 

“When you’re valuable, you’re extremely useful or important — but not a failure point," says Yung. "The best engineers and managers are great at adding value, getting the most out of the people around them, and helping the team see around corners even when they’re not there.”

2. Want to succeed as a manager? Establish an emotional equilibrium.

forcing engineers to move into management is a mistake

. The challenge for most engineers is deciding if it’s a mantle they want to take on. “Although transitions into management sometimes happen quickly, think about it deeply and prepare as best as you can. Too many engineers plunge in, without exploring lightweight ways to try the manager’s hat on first,” says Yung.

“I started by taking on more team responsibilities and onboarding new hires as a Facebook bootcamp mentor. I led a large technical project and got a feel for balancing engineering work against people leadership. By the time the project launched, I knew I wanted to invest time in becoming a good manager.”

Management is not for the faint of heart. While being a great manager is really hard, it’s incredibly rewarding — and something I’ve chosen to spend many of my waking hours trying to get better at.

Still, all the prep work in the world won’t ready you for the emotional challenge that lies ahead. “Most of the time, this is what I end up coaching new managers through,” says Yung. “As an IC, you don’t see the full picture of all the ups and downs managers have to deal with, so it’s easy to fall into the trap of thinking you’re ready — and then freaking out once you realize you’re not.” 

To help would-be managers get a better sense of what’s to come, Yung sketches out this chart on a whiteboard to give them a visual metaphor (

“As an individual contributor, your job often looks like a local hill-climbing exercise. For most projects, you steadily make progress until you don’t. You’re either done and can move on, or maybe something went awry and your project was canceled or simply failed. Either way you get to start over from zero the next time,” says Yung.

. “As an IC, I was a bit of a perfectionist. I thought in black and white, in designing systems, in exhaustively listing out all the edge cases,” she says. “As a manager, it took me a lot of time to realize you can't solve problems that way. People are not optimization problems — you have to accept there's a range of solutions and there isn't one true great answer.”

progress and feelings are no longer tightly correlated

. “As an individual contributor, generally when you were doing well on a project you were making visible progress. As an engineering manager, you can work hard on something for over a year, only to see no progress in the short-term and 

 experience a big payoff in the much longer-term,” says Yung.

All of that combined can bring your emotions down in ways you can’t predict or control. “Your mood will swing wildly. The larger your teams get, the greater the probability something is going off the rails at any given time. The crests and dips grow bigger and bigger,” she says. “The first step is being aware that 

. The second step is trying to establish more of an equilibrium so you don’t get knocked off course so easily.”

Part of what makes experienced managers great is their ability to weather storms and normalize their own emotions to somewhere closer to zero.

Yung cautions that engineering managers are also liable to develop what she calls split-brain syndrome. “You put on a mask. To your teammates or coworkers you feel this need to maintain an even, steady zero, but on the inside you’re going through these wild swings,” she says. “Don’t make the mistake of trying to handle this on your own. Some of my closest friends and mentors from work are the people I’ve been the most vulnerable with, and who have helped me become a much better leader.”

3. Focus on growth and learning at every step — not on climbing the ladder as quickly as possible.

Even though there’s a lot of industry emphasis on ladders and levels, Yung’s no longer sure that’s the best way for engineers to think about their careers. “While companies have developed ‘parallel’ ladders between IC and engineering management tracks — and I helped with this very task at Stripe — I’ve since come to think of these engineering roles more as 

progressing along a pair of joint and often intertwined steps

“We’re incredibly lucky that in engineering, unlike many industries, management is not the only path to growth. 

too many believe that it’s a binary choice, that you’re locked into a path once you’ve started on it. In reality, the skills required to succeed as a technical lead or manager are much more connected than you think.

 I’ve seen first-hand that many people switch between these roles throughout their careers or even at the same company,” she says.

“At Stripe and Facebook, I hired several ICs who were formerly managers and looking for a break from that role. The thing they all had in common was the ability to break down large problems and deliver on technical projects — everyone saw that in them, no matter what ladder they were on at the moment. That career flexibility is only possible if you’ve nailed the skills of being a great team 

Management and IC careers aren’t strictly parallel paths — in practice, they criss-cross all over the place. But it’s only possible to toggle back and forth later on in your career if you put in the work early on. Push for the manager track prematurely and your technical lead chops may not be sharp enough to pull it off.

In Yung’s experience, many engineers are focused on moving up the ranks as quickly as possible, asking questions such as, “How can I become a people manager?’ or “I’ve been here for a year, what’s next?” or “How can I get more headcount on my team?” to skip ahead.

“Those are all questions centered around a desire to climb that ladder even faster. But that can be a rigid path to set yourself on, one that limits your options and flexibility in the future,” she says. Instead, Yung recommends engineers engage in serious introspection to deeply understand what motivates and excites them before moving on to the next step. 

 questions, the ones that keep you focused on growth and learning, not on moving up

. My best teammates have been the ones who constantly pushed themselves to identify their weaknesses, systematically learn from their mistakes and get better,” she says.

The best career advice I have for young engineers is to focus on learning instead of worrying about tracks and career ladders. That way, no matter what path you take as an IC, domain expert, engineering manager or even PM, you’ll only get better over time.

In the sections that follow, Yung walks us through each of these career steps to provide tailored advice, outlining common mistakes that are all too easy to make, as well as the more productive questions engineers should be asking instead. Drawing on examples from her own journey, she guides us along the path from early engineer to the transition into management to the most complex and senior roles an engineer can hold.

ADVICE FOR EARLY ENGINEERS AND ICs: HOW TO SET YOURSELF ON THE RIGHT PATH

Many new grads (or those who came to software engineering later on) have eagerness, drive, hunger — and impatience — in spades. But that impatience can have unintentional consequences if it’s not channeled in the right direction, says Yung.

In her experience, these three moves can knock early engineers off-course:

Skipping engineering fundamentals to pivot into other roles prematurely:

 “I’ve seen people lose focus on their engineering work too soon, in hopes of becoming a manager or switching into another role like product management. Building a great foundation early on is critical in your career, no matter what function you ultimately want to end up in,” she says. “Don’t rush through the fundamentals at the beginning. There’s no real substitute for time spent with your hands on the keyboard.”

Moving on from a team or company too quickly:

 “As a hiring manager, I’m skeptical of candidates who say some variation of ‘I’ve worked at X company for over a year, and I’ve learned everything I can so it’s time to move on.’” she says. “

Sometimes the most interesting challenges only become tractable to you after a few years — you might be overlooking massive learning opportunities that come with staying in your current role

. The best engineers are those who’ve taken the time to deeply understand a system or product and can apply their experience to a new problem.”

: “I get a lot of ‘How can I learn more about [insert cool technology here]?’ questions from early engineers,” says Yung. “Technology continuously evolves, and while it’s important to be informed about the latest frameworks and best practices, learning this at the cost of developing fundamental skills is a bad tradeoff. At both Facebook and Stripe, you can interview in the language you feel most comfortable in, on the belief that if you’re a good engineer, your skills will help you pick things up as needed,” she says. “You also don’t need to over-index on the new and shiny because what’s old can become new again. For example, when the Android platform first came out, no one really knew how to be a ‘good Android developer.’ Product teams were actually bootstrapped from infrastructure Java developers who were recruited over,” she says. “As it turns out, experience with parallelism and multi-threaded applications was far more applicable to Android than the single-threaded, asynchronous request patterns being used in the main Facebook web app.”

Frameworks come and go, but core programming fundamentals — thinking through edge cases, debugging, the ability to learn new languages — are what stand the test of time.

Instead of plotting future functional pivots, jumping ship after a year, or spending too much time on the framework du jour, Yung recommends leaning on these two tactical, guiding questions:

How can I make every code change a great one? 

“This might seem super tactical, but every commit is a building block in software engineering, and if you build confidence with every code review, you’ll move more quickly and take on larger challenges,” she says. “Conversely, if every pull request is a chore and you continue to make common mistakes, it’s hard to build credibility with your team. One of the most common pieces of practical advice I give to new grad engineers is to always review your own code before you submit it to others. Catch your own mistakes and quickly learn to not make them again.”

How can I be as good at [X] as [this person] on my team? 

, and are always around you — identify what they’re best at and try to absorb their superpowers,” says Yung. Take this example from her first year as a new grad engineer: “I had two teammates with a lot more experience than me. 

 came from a graphics background and was quiet in meetings, but wrote amazing code and reviews. He always spotted the flaw in my designs. Mark came from a product and business focused background. He spent less time on design but was an incredibly fast coder and thought through every edge case. I wanted to be as good at design and code review as Adam, and as good at product as Mark, so I vowed to get as much code reviewed as I possibly could by the former and get all my user-facing changes reviewed by the latter.”

Technical leads, soak up all you can to build a strong foundation regardless of your future path. 

After a few years of mastering the fundamentals, engineers are ready to move on up, earning titles such as Senior Engineer or Technical Lead. But as she alluded to earlier, in Yung’s experience, often engineers rush to move to the next level or switch into management.

Instead, lean on these four growth-focused questions to make sure the technical lead well you’ve drilled is deep enough to support future moves:

Do I deeply understand the systems I work on, and how they can break or be improved? 

“This goes beyond knowing the ins and outs of the systems or products you own,” says Yung. “Let’s say you're building some new infrastructure used to launch your product in one country today. Not only do you need to think about maintainability now, but you need to think about what’s next. What if we need to launch in ten new countries? A hundred countries? What would break? How would your current design change? Pushing yourself to think through a wide range of scenarios helps you not only deepen your understanding of the here and now, but also helps you strategically steer into the future.”

How do I know we are working on the right things? 

“Being a technical lead is not just about seeing around corners and solving problems with well-designed, scalable and well-tested solutions. Some of the best technical leads I know are the ones who can also tell you 

 what they’re working on matters, and why it’s important to do 

,” says Yung. “This doesn’t mean you’ll always get it right, and some of the best ones will stop themselves when they go down the wrong path.”

How can I build better people leadership skills? 

Regardless of whether you want to become a manager in the future, there are many ways to build team and people skills that will help you in your engineering career. “Start to own projects more holistically, taking into account not only the technical challenges but also the people side — understand who’s working on what and why, and how people work together,” says Yung. “Help less experienced engineers grow by mentoring interns and new team members. Work cross-functionally and think of your PMs and partners as your teammates. If you do want to become a manager later, this will help give you a much stronger sense of whether you’ll enjoy making the switch.”

Domain experts, double check to make sure you aren’t getting trapped.

Some engineers relish the opportunity to become deep-domain experts, particularly by staying in one part of the company or technical system. But especially as the years go by, check in to make sure you’re still growing and learning. “If you stop learning, you can become complacent and rely on your deep background to solve problems the way you ‘just know’ is right because you’ve seen it before. 

Not only have you stopped growing, but even worse, you may have stopped building the best solutions

As you advance in your engineering career, you’ll become an expert in a particular domain and feel as though you’re the “only one” who can handle it. That may be true, but if you’re burning out, it’s really not worth it — and you’re probably selling your teammates short.

If you find yourself at this point in your engineering career, ask these questions to make sure your deep expertise isn’t holding you — or your teammates — back:

How do I keep learning and stay challenged? 

Look out for signs that your growth is stalling and push yourself to find new sources of inspiration from other people, teams or systems. “After years of working on privacy at Facebook, I knew how to do precise surgery on the existing infrastructure, but didn’t have any big new ideas on how to make things better,” says Yung. “Looking back, that was a red flag. The feeling of being essential, of being needed for my expertise had masked that gap. It wasn’t until we merged with another team that was working on an entirely different approach that I felt like I was learning again. This led to a great renaissance and a complete re-invention of our entire system.”

How do I continue to show value when I’m starting over in a new area? 

Another barrier to growth is the fear that you’ll never reach the same level of impact by doing something different. “It’s true that it will take time to transition, but if you’ve become an expert in one area you’re likely capable of doing it again 

 you’ll be able to go deeper faster next time using the skills you bring with you,” says Yung. One rule of thumb for onboarding very experienced hires is that for every year they spent in their last role, they need one month of slow initial onboarding time; once ramped up, their impact accelerates quickly.

How can I transfer knowledge to the people around me and lay out a strategy for future generations? 

Think about how you can transfer knowledge to even more people, at a deeper level of complexity and a higher level of efficiency. “If you find yourself explaining something to one person at a time, find a better way to do it. Develop documentation, training programs, or reusable components and infrastructure to pass knowledge on at scale,” says Yung. “Stripe has a strong culture of information sharing and discovery, where anyone can search across shared emails and documents. But, even in such an information-rich environment, engineers who were deeply knowledgeable about a system were often less impactful than those who could also communicate about it in a usable and digestible way.”

ADVICE FOR ENGINEERS MOVING ALONG THE MANAGEMENT TRACK: HOW TO BETTER SUPPORT YOUR TEAM

, with added pressure to still set a good technical example for the team. To top it off, you can’t measure your new people responsibilities work in a way that’s as satisfyingly concrete or objective as writing code was. 

An easy mistake to make is to try and work around this by clinging on to your coding time, even if it means doing it at night after your “day job” as a manager is done.

Instead, Yung advises making peace with this shift. “Not feeling productive and overcompensating with technical work can be unbelievably stressful. It can make you wonder if transitioning to management was a mistake. These emotions can last for a while — but 

. Ride it out for at least six months to a year if you can, and then look back to evaluate how you feel,” she says.

Instead of worrying about your own contributions, ask these questions as a new engineering manager:

All of our Engineering articles

How to Build a Culture of Ownership, and Other Engineering Leadership Tips from Plaid & Dropbox

The Engineer’s Guide to Career Growth — Advice from My Time at Stripe and Facebook

Why This Engineering Leader Thinks You Shouldn’t Aim for Zero Regrettable Attrition

How to Size and Assess Teams From an Eng Lead at Stripe, Uber and Digg

Empathy-Driven Development: How Engineers Can Tap into This Critical Skill

How This Head of Engineering Boosted Transparency at Instagram

My Lessons from Interviewing 400+ Engineers Over Three Startups

Veteran CTO (with Multiple Successful Exits) Answers Your Top Startup-Building Questions

Make Stronger Offers to Engineering Candidates and Boost Your Closes

How Instagram Co-founder Mike Krieger Took Its Engineering Org from 0 to 300 People

Track and Facilitate Your Engineers’ Flow States In This Simple Way

Making Engineering Team Communication Clearer, Faster, Better