Raylene Yung 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, I 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, as well as her own handbook for eng 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: career growth for engineers. “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 every engineer to ask themselves the right questions as they plot out their careers.
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.
By now, it’s clear to most that 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 (which she explains in more detail here):
“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.
But engineering managers unlock the negative zone of this chart. “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.”
Another observation: 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 maybe 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 this is completely normal. 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,” she says.
Here are those steps as Yung sees them:
“We’re incredibly lucky that in engineering, unlike many industries, management is not the only path to growth. Despite that, 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 and technical leader.”
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.
“It’s about asking the right 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.”
- Chasing the latest trend: “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.
Ask these questions instead:
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? “Mentors come in all shapes and sizes, 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. Adam 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 why what they’re working on matters, and why it’s important to do now,” 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,” says Yung.
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 and 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
First-time engineering managers face a steep learning curve, 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 it’s a mistake to act on them. 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:
- How healthy is my team? How high-quality and high-impact is our work? As a new manager, it’s easy to get derailed by specific challenges or buoyed by big wins. Don’t lose sight of the overall output and health of your team. “Even if you write the best performance reviews, diligently hold your 1:1s every week and go to every new manager training session, if your team isn’t showing results your impact will be lower than it should be,” says Yung. But there’s also the risk of pushing too hard for results and compromising on quality and team health. “You could be working on all the right things and driving up the metrics, but your on-call rotation is on fire and causes engineers to burn out and switch teams. The key is to invest in all aspects of your team and keep them in balance — even if some changes may seem counterproductive in the short-term, like slowing down your roadmap to invest in developer efficiency and team happiness, they’ll increase your impact over time.”
- How well can my team operate without me? “An old manager once told me that he could roughly gauge his level of experience by how long he could be away without his team getting too far off course,” says Yung. “At first it was a few days, then maybe a week. Eventually he could stretch it to a month, and then several for paternity leave. Now he aspires to be able to go away for a full year. I suspect most companies won’t let you actually be away that long, but it’s a helpful litmus test to try for yourself. Growing as a manager is not just about transferring knowledge, it’s also about building the right team and filling in the gaps. Maybe you have a team of folks who, given the right tasks, can plow through them faster than you expect and ask for more. But if they’re still relying on you to tell them what’s next and break down the next project, you’ll need someone to step in if you try to go on vacation.”
Experienced managers, don’t default to adding more engineers.
After gaining experience as a manager, concerns start to shift. You’ve mastered the art of shipping projects, but at some point you might hit diminishing returns. In Yung’s experience, one trap many managers fall into is relying too much on team expansion. “It’s easy to get on the treadmill and only think about growth and headcount,” she says. “But while adding more people might give you the illusion of progress, it could be papering over real issues and making them harder to solve.”
Adding more headcount isn’t always the cure. It often creates more problems than it solves.
To move beyond increasing headcount, ask these questions to get more out of your team:
- Why does my team exist, and why does what we work on matter? “Talk about your long-term goals and objectives, rather than only the projects on your plate today. Help your team think further ahead, and invite them to suggest different paths to your goals, or debate whether they are the right ones” says Yung. If you can’t explain why your goals and projects matter, maybe you’re working on the wrong things. Solicit feedback and don’t be afraid to change them.”
- How can I help my teammates grow, across all experience levels and scenarios? Standout engineering managers can capably manage engineers of different experience levels. The telltale sign of a less experienced manager is when they’re great for new grads, but rarely have the most senior engineers on their team — often due to a mutual unwillingness to manage or be managed by them. Yung’s advice? Instead of trying to work around the problem, tackle it head on. “One of my first team members had been working for twelve more years than I had — I was intimidated, but decided to try and learn from the experience,” she says. “In our first 1:1, I shared areas I thought I could help him with (e.g. product domain knowledge, company context), and asked for his help in others (e.g. managing senior engineers, scaling complex systems). Over the next few years, we developed a strong working relationship and learned a lot from one another.”
ADVICE FOR LEADING ORGANIZATIONS: HOW TO MANAGE IN UNCHARTED TERRITORY
“Similar to the initial transition from individual contributor to engineering manager, moving to managing multiple teams or organizations can feel like an entirely new job,” says Yung. “It becomes even easier to fall into the headcount trap, as the need for growth compounds with the number of managers on your team. On top of that, once you start managing managers it can be tempting to spot new managers everywhere. And sometimes, you’ll be most tempted to select the reluctant, those incredible technical leaders who don’t really want to manage,” she says.
Of course, there are “war times” when it’s all hands on deck and battlefield transitions might be necessary. But do it with care, Yung cautions. “Early at Stripe, I transitioned three engineers into management because we needed immediate support and were still spinning up our recruiting pipeline. Two of them grew to really enjoy the role; the third realized they were happiest when coding and providing technical leadership and switched back,” she says. “The key is to work closely to develop new managers — make sure they go into it with eyes wide open and have an opportunity to learn, but also give them the room to switch back. By keeping people in ill-suited management roles, you risk not only burning out some of your most productive team members, but are also preventing yourself from finding someone better.”
Too many leaders convince the reluctant to become or stay managers, drafting them into duty. This might be necessary in crunchtime, but keeping unwilling managers in roles for too long is a costly mistake.
Organizational leaders should ask these questions to increase their effectiveness:
- What unites your teams and why are you supporting them together? In high-growth companies, reorgs are constant and expected. There’s a perennial switch between horizontal, vertical, domain-specific, or user/product-specific matrixed team structures — which means org leads can often end up with a disparate set of groups under their wing. Done wrong, this can feel like whiplash, where new organizations feel arbitrarily grouped together and lack a broader purpose. “At one point at Stripe, I was leading teams that built applications using specific eng and product skills, such as frontend development, ML and understanding the SaaS business model. At first, it did feel almost like a grab bag of apps that were far from Stripe’s core business,” says Yung. “But after work and iteration, we tied the mission to two things: One, enhancing the core payments platform by building powerful features that might not be needed by every user, but were critical to those who did, and two, being the stewards of a new business model that could compound over time and be a meaningful company driver. This helped paint a more coherent vision and enabled people to explain what they were working on, both to themselves and to other teams.”
- Are your teams as healthy as they can be? Are they even the right teams? Don’t be afraid to take action if you can’t confidently answer why your teams fit together or if you’re working on the right things. “Think about bigger cross-team improvements to make. Maybe one team shouldn’t exist at all. Maybe other teams don’t have enough people for their most important projects. Enlist help from your manager, peers and other cross-functional partners to assess your teams and make changes,” says Yung. “I like to assess along the following axes: people (Do I have the right skill sets and leaders on the team? Are teams engaged and are people getting the development and growth opportunities they need?), projects and goals (Are we working on the highest impact things right now? Do people understand what they are and why we are working on them?) and progress (Are we moving at the right pace and investing time in a high-leverage way? What would speed us up the most, both for the short-term and long-term?)”
- Am I spending time with my teams in the right way? “In the same way that knowing the stack and technical work can help you be a good first-line manager, knowing how your managers and their teams operate day-to-day can help you grow as an org leader. Do what you can to support each team and don’t shy away from gathering first-hand knowledge. Attend team meetings as a guest observer, do skip-level 1:1s, and communicate transparently along the way,” says Yung. But don’t let gathering information take you too deeply into the weeds. “It’s easy to get caught in that awkward spot where you’re helping debug local team issues in lieu of making changes that help your org overall. You also might feel the impulse to step in and direct the groups that report to you. But now is when the ‘ask don’t tell’ approach is more important than ever. Look to your group leads to tell you what they need. Maximize your value by providing the external context they don’t have and contributing at a broader and higher level.”
Org leadership is about supporting, listening and coaching, not actively directing. Your teammates at each layer below you know strictly more about their day-to-day challenges than you will, so your meddling is low ROI.
TYING IT ALL TOGETHER
If Yung had to distill all of this advice into a simple checklist for engineers pushing for career growth, here’s what she’d say:
- Strive to be the most valuable, but least critical. Think about how long you could be away from your team and how far off course they would get. Do everything you can to close that gap.
- Focus on growth and learning at every step — not on climbing the ladder as quickly as possible. Don’t move on from a role too quickly, and try not to get caught up in chasing the latest trends.
- The best engineers can toggle back and forth between manager and IC roles. Make sure your technical foundation and fundamental skills are solid enough to pull that off.
- Do your homework before signing on to become a manager, and try your best to prepare for the emotional ups and downs coming your way.
- If you’re a new manager, focus on the health and impact of your team, not on how much code you’re personally shipping.
- Before you request additional headcount, drill down into why your team exists and how you can help every engineer level up.
- Don’t lose the forest for the trees when you’re leading a large org. Dig in enough to understand what’s going on, but focus your contributions on where they’ll matter most.
Photography by Bonnie Rae Mills. Charts courtesy of Raylene Yung.