Operating at Staff

One of the best pieces of advice that someone gave me, and that I make sure to pass on to other staff engineers, is that there’s a misconception that you become a Staff Engineer and then you’ll be in control of the work you do, and everyone will listen to you and do what you want them to do. That’s absolutely the opposite of what happens! ‐ Katie Sylor‐Miller

Many engineers become focused on the Staff‐plus career path because the engineering manager path has too many meetings or requires too much collaboration with other coworkers, and yikes, are you going to be surprised if you begin a Staff‐plus with that mindset. Although Staff Engineer roles are generally positioned as the sequential step be‐ yond Senior Engineer, it’s genuinely a different role, and you’ll increas‐ ingly spend your time doing sorts of work that you previously did in‐ frequently or not‐at‐all.

There is a significant learning curve in Staff‐plus roles that initially trip most folks up. Part of the challenge is that much of the work you’re do‐ ing has a much slower feedback cycle. The delayed feedback can ini‐ tially feel quite demoralizing as you replace the visceral coding REPL with the uneven progress of mentorship, relationship building, and strategy.

This chapter is about overcoming that learning curve, learning to op‐ erate as a Staff Engineer, and finding the parts of the role which are personally fulfilling and organizationally transformative.

Topics

In the interviews for this book, as well as my own experience leading and coaching Staff‐plus engineers, a handful of topics kept coming up as keystones of personal development. They aren’t everything you’ll do in the role, but they are the places where you’re most likely to have an outsized impact or accidentally commit a career‐limiting move.

1. Work on what matters to make the most of the working hours you have, particularly as you get further along in your career and life’s commitments expand.

2. Write an engineering strategy to guide your organization’s ap‐ proach to supporting your company’s business objectives with its architecture, technology selection, and organizational struc‐ ture.

3. Curate technical quality to maintain the quality of your com‐ pany’s architecture and software as it grows and tacks over time.

4. Stay aligned with authority to remain an effective leader over time. Technical leadership roles rely on proxied authority from another (usually, managerial) leader, and continued access to that authority depends on staying aligned, trustworthy, and pre‐ dictable.

5. To lead, you have to follow. Having a vivid sense of how things ought to work is a powerful leadership tool, but it’s also essential to learn to blend your vision with the visions from your peers and leadership.

6. Learn to never be wrong shift away from being right and towards understanding and communication. Stop spending your social capital repairing relationships frayed by conflict, and learn to collaborate with folks with different priorities and perspectives. This also comes with the added benefit of fewer folks complaining about you to your manager.

7. Create space for others so that your team grows stronger than your contribution.

8. Build a network of peers to vet difficult decisions and to give you honest feedback when your role’s authority starts to temper feedback.

An astute reader will notice two critical themes discussed in What do

Staff engineers actually do? are missing from this topic list: the first is “mentorship and sponsorship,” and the second is “being glue.” Both concepts are essential to the success of Staff‐plus engineers, but ulti‐ mately, I think the canonical pieces on these topics already exist, and you’re better served by reading those than my watery rehash. For men‐ torship and sponsorship, spend some time with Lara Hogan’s What Does Sponsorship Look Like?, and for being glue, spend time with Tanya Reilly’s piece that bore the phrase, Being Glue.

As you deliberately practice in each of these areas, you’ll slowly progress from a newly minted Staff Engineer to a trusted organiza‐ tional leader. That said, these won’t cover everything you do. At times you’ll find your role surprisingly similar to that of an Engineering Director, and at other times strangely familiar to previous work in your career.

That vast remit is part of what makes describing these roles challeng‐ ing. If there’s a particular topic you’re focused on that’s missing, check out the Additional resources for learning appendix.

Work on what matters

I’ve taken to using the word “energized” over “impactful.” “Impactful” feels company‐centric, and while that’s important, “energized” is more inwards‐looking. Finding energizing work is what has kept me at Stripe for so long, pursuing impactful work. ‐ Michelle Bu

We all have a finite amount of time to live, and within that mortal countdown, we devote some fraction towards our work. Even for the most career‐focused, your life will be filled with many things beyond work: supporting your family, children, exercise, being a mentor and a mentee, hobbies, and so the list goes on. This is the sign of a rich life, but one side‐effect is that time to do your work will become in‐ creasingly scarce as you get deeper into your career.

If you’re continuing to advance in your career, then even as your time available for work shrinks, the expectations around your impact will keep growing. You can try sleeping less or depriving yourself of the non‐work activities you need to feel whole, but you’ll inevitably find that your work maintains an aloof indifference to your sacrifice rather than rewarding it. Only through pacing your career to your life can you sustain yourself for the long‐term.

Indeed, pacing yourself becomes the central challenge of a sustained, successful career: increasingly senior roles require that you accom‐ plish more and more and do it in less and less time. The ledge between these two constraints gets narrower the further you go, but it remains walkable if you take a deliberate approach.

First, a discussion on a few common ways to get tripped up: snacking, preening, and chasing ghosts. Then we’ll get into the good stuff: how do you work on what really matters?

Avoid snacking

Hunter Walk recommends that folks avoid “snacking” when they prioritize work. If you’re in a well‐run organization, at some point, you’re going to run out of things that are both high‐impact and easy. This leaves you with a choice between shifting right to hard and high‐impact or shifting down to easy and low‐impact. The latter choice–easy and low‐impact–is what Walk refers to as snacking.

When you’re busy, these snacks give a sense of accomplishment that makes them psychologically rewarding. Still, you’re unlikely to learn much from doing them, others are likely equally capable of complet‐ ing them ( and for some of them, it might be a good development oppor‐ tunity), and there’s a tremendous opportunity cost versus doing some‐ thing higher impact.

It’s ok to spend some of your time on snacks to keep yourself motivated between bigger accomplishments, but you have to keep yourself hon‐ est about how much time you’re spending on high‐impact work versus low‐impact work. In senior roles, you’re more likely to self‐determine your work, and if you’re not deliberately tracking your work, it’s easy to catch yourself doing little to no high‐impact work.

Stop preening

Where “snacking” is the broad category of doing easy and low‐impact work, there’s a particularly seductive subset of snacking that I call “preening.” Preening is doing low‐impact, high‐visibility work. Many companies conflate high‐visibility and high‐impact so strongly that they can’t distinguish between preening and impact, which is why it’s not uncommon to see some companies’ senior‐most engineers spend the majority of their time doing work that’s of dubious value, but that is frequently recognized in company meetings.

If you’re taking a short‐term look at career growth, then optimizing for your current organization’s pathologies in evaluating impact is the optimal path: go forth and preen gloriously. However, if you’re think‐ ing about developing yourself to succeed as your current role grows in complexity or across multiple organizations, then it’s far more impor‐ tant to strike a balance between valued work and self‐growth.

This is also an important factor to consider when choosing a company to work at! Dig into what a company values and ensure it aligns with your intended personal growth. If a company’s leadership consists entirely of folks who focus their energy on performative urgency or acts of fealty, don’t be surprised when your success in the company depends on those activities.

Worse, to be a successful preener requires near invulnerability to crit‐ icism of your actual impact, and your true work will suffer if your en‐ ergy is diverted to preening. Typically this means you need to be a van‐ ity hire of a senior leader or to present yourself in the way a company believes leaders look and act. If that isn’t you, then your attempt to ex‐ change your good judgment for company success will end up failing anyway: you’ll get held accountable for the lack of true impact where others who match the company’s expectation of how a leader appears will somehow slip upward.

Stop chasing ghosts

Many folks would assume that companies, rational optimizers that they are, avoid spending much time on low‐impact high‐effort projects. Unfortunately, that isn’t consistently the case. It’s sur‐ prisingly common for a new senior leader to join a company and immediately drive a strategy shift that fundamentally misunderstands the challenges at hand. The ghosts of their previous situation hold such a firm grasp on their understanding of the new company that they misjudge the familiar as the essential.

As a senior leader, you have to maintain a hold on your ego to avoid in‐ vesting in meaningless work on a grand scale. This can be surprisingly challenging when during your hiring process, you’ve been repeatedly told that you’ve been hired to fix something deeply broken–you’re the newly‐hired savior. Of course, your instincts are right! Taking the time to understand the status quo before shifting it will always repay dili‐ gence with results.

I had a recent discussion with someone who argued that new senior leaders deliberately push for major changes even though they suspect the efforts will fail. Such changes make the organization increasingly dependent on the new leader and also ensures anything that does go well gets attributed to the new leader directly rather than their team. If this is your approach to leadership, please know that you’re awful and take the time to work on yourself until the well‐being and success of an entire company matter to you more than being perceived as essential.

Existential issues

Now that you’re done snacking, preening, and chasing ghosts, it’s time to to start thinking from the other direction: what should you work on? The first place to look for work that matters is exploring whether your company is experiencing an existential risk. Companies operate in an eternal iterative elimination tournament, balancing future success against surviving until that future becomes the present. If you’re about to lose one of those rounds, then always focus there.

Running out of money, like my experience at Digg, can be the most obvious issue, but not every existential issue is financial, like Twitter’s fail whale stability challenges or adapting to the shifts caused by the Covid‐19 pandemic.

If something dire is happening at your company, then that’s the place to be engaged. Nothing else will matter if it doesn’t get addressed.

Work where there’s room** **and attention

Existential issues are usually not the most efficient place to add your efforts, but efficiency isn’t a priority when the walls are crashing down around you. You should swarm to existential problems, but if a prob‐ lem isn’t existential, then you should be skeptical of adding your ef‐ forts where everyone’s already focused. Folks often chase leadership’s top priority, but with so many folks looking to make their impact there, it’s often challenging to have a meaningful impact.

Instead, the most effective places to work are those that matter to your company but still have enough room to actually do work. What are pri‐ orities that will become critical in the future, where you can do great work ahead of time? Where are areas that are doing ok but could be doing great with your support?

Sometimes you’ll find work that’s worthy of attention but which an or‐ ganization is incapable of paying attention to, usually because its lead‐ ership doesn’t value that work. In some companies, this is developer tooling work. In others, it’s inclusion work. In most companies, it’s glue work.

There is almost always a great deal of room to do this sort of work that no one is paying attention to, so you’ll be able to make rapid initial progress on it, which feels like a good opportunity to invest. At some point, though, you’ll find that the work needs support, and it’s quite challenging to get support for work that a company is built to ignore or devalue. Your early wins will slowly get eroded by indifference and misalignment, and your initial impact will be reclaimed by the sands of time.

Does this mean you shouldn’t do inclusion work? No, that’s not the con‐ clusion I want you to take away from this. Sometimes an area that an organization doesn’t pay attention to is so important that you’re going to want to advocate for it to start paying attention. Teaching a company to value something it doesn’t care about is the hardest sort of work you can do, and it often fails, so you should do as little of it as you can, but no less. As a senior leader, you have an ethical obligation that goes be‐ yond maximizing your company‐perceived impact, but it’s important to recognize what you’re up against and time your efforts accordingly.

Foster growth

One area that’s often underinvested in (e.g., lots of room to work in) while also being highly leveraged is growing the team around you. Hir‐ ing has a lot of folks involved in it, usually in terms of optimizing the hiring funnel, but onboarding, mentoring, and coaching are wholly neglected at many companies despite being at least as impactful as hiring to your company’s engineering velocity.

If you start dedicating even a couple of hours a week to developing the team around you, it’s quite likely that will become your legacy long after your tech specs and pull requests are forgotten.

Edit

A surprising number of projects are one small change away from suc‐ ceeding, one quick modification away from unlocking a new oppor‐ tunity, or one conversation away from consensus. I think of making those small changes, quick modifications, and short conversations as editing your team’s approach.

With your organizational privilege, relationships you’ve built across the company, and ability to see around corners derived from your ex‐ perience, you can often shift a project’s outcomes by investing the smallest ounce of effort, and this is some of the most valuable work you can do.

It’s particularly valuable because it’s quick, it’s easy, it’s highly moti‐ vating for both you and the person you help, and it’s hugely impactful when done well. (Also, it’s highly demotivating when done poorly, so your approach matters!)

Finish things

One special sort of editing is helping finish a project that just can’t quite close itself out. Often you’ll have a talented engineer earlier in their career who is already doing the work but can’t quite create buy‐ in or figure out how to rescope their project into finishable work. It’s surprisingly common that coaching a teammate on how to tweak a project into something finishable and then lending them your privi‐ lege to budge the right friction points will transform a six‐month slog into a two‐week sprint with almost an identical impact.

We only get value from finishing projects, and getting a project over the finish line is the magical moment it goes from risk to leverage. Time spent getting work finished is always time well spent.

What only you can

The final category of work that matters is the sort that you’re uniquely capable of accomplishing. Sure there’s work that you’re faster at or better at than some other folks, but much more important is the sort of work that simply won’t happen if you don’t do it.

This work is an intersection of what you’re exceptionally good at and what you genuinely care about. It might be writing your company’s technology strategy that folks will actually follow, it might be convinc‐ ing a great candidate to join, it might be changing your CEO’s mind on how you pay down tech debt, it might be crafting a discerning API.

Whatever it is, things that simply won’t happen if you don’t do them are your biggest opportunity to work on something that matters, and it’s a category that will get both narrower and deeper the further you get into your career.

Why it matters

Suppose you’re interviewing for a new role twenty years into your ca‐ reer. Will the folks interviewing you understand your real impact on any of your previous projects or companies? No, I guarantee they won’t. Instead, you’ll find yourself judged by a series of surprisingly subjective measures: your accumulated prestige, the titles you’ve had and companies you’ve worked at, your backchannel reputation, and how you present in your interview process.

You can’t escape subjective interview practices, but you can deliber‐ ately accumulate expertise from doing valuable work. Indeed, that’s the only viable long‐term bet on your career: focus on work that mat‐ ters, do projects that develop you, and steer towards companies that value genuine experience.

Writing engineering strategy

I kind of think writing about engineering strategy is hard because good strategy is pretty boring, and it’s kind of boring to write about. Also I think when people hear “strategy” they think “innovation” ‐ Camille Fournier

Few companies understand their engineering strategy and vision. One consequence of this uncertainty is the industry belief that these documents are difficult to write. In some conversations, it can feel like you’re talking about something mystical, but these are just mundane documents. The reality is that good engineering strategy is boring and that it’s easier to write an effective strategy than a bad one.

To write an engineering strategy, write five design documents, and pull the similarities out. That’s your engineering strategy. To write an engineering vision, write five engineering strategies, and forecast their implications two years into the future. That’s your engineering vision.

If you can’t resist the urge to include your most brilliant ideas in the process, then you can include them in your prework. Write all of your best ideas in a giant document, delete it, and never mention any of them again. Now that those ideas are out of your head, your head is cleared for the work ahead.

Durably useful engineering strategy and vision are the output of iter‐ ative, bottom‐up organizational learning. As such, all learning con‐ tributes to your organization’s strategy and vision, but your contribu‐ tion doesn’t have to be so abstract. Even if you’re not directly responsi‐ ble for that work, there are practical steps that you can take to advance your organization’s strategy and vision, starting right now.

When and why

Before diving into the recipe for creating effective strategies and visions, a good starting question is, “When and why should I actually create them?” Strategies are tools of proactive alignment that em‐ power teams to move quickly and with confidence. Strategies allow everyone–not just the empowered few–to make quick, confident decisions that might have otherwise cost them a week of discussion. Strategies are also the bricks that narrow your many possible futures down enough that it’s possible to write a realistic vision. If you realize that you’ve rehashed the same discussion three or four times, it’s time to write a strategy. When the future’s too hazy to identify investments worth making, it’s time to write another vision. If neither of those sound like familiar problems – move on to other work for now and return later.

Write five design docs

Design documents describe the decisions and tradeoffs you’ve made in specific projects. Your company might call them RFCs or tech specs. Stranger names happen, too; Uber bewilderingly called them DUCKS until they later standardized on RFC. A good design document describes a specific problem, surveys possible solutions, and explains the selected approach’s details. There are many formats to pick from; a few places to start your thinking are Design Docs, Markdown, and Git, Design Docs at Google, and Technical Decision‐Making and Alignment in a Remote Culture.

Whether a given project requires a design document comes down to personal judgment, but I’ve found a few rules useful. You should write design documents for any project whose capabilities will be used by numerous future projects. You should also write design documents for projects that meaningfully impact your users. You should write a design document for any work taking more than a month of engineer‐ ing time.

A batch of five design docs is the ideal ingredient for writing an effec‐ tive strategy because design documents have what bad strategies lack: detailed specifics grounded in reality. It’s easy for two well‐meaning engineers on the same team to interpret an abstract strategy in differ‐ ent ways, but it’s much harder to stay misaligned when you’re imple‐ menting a specific solution.

A few recommendations as you write:

• Start from the problem. The clearer the problem statement, the more obvious the solutions. If solutions aren’t obvious, spend more time clarifying the problem. If you’re stuck articulating the problem, show what you have to five people and ask them what’s missing: fresh eyes always see the truth.

• Keep the template simple. Most companies have a design doc‐ ument template, which is a great pattern to follow. However, those templates are often expanded to serve too many goals. Overloaded templates discourage folks from writing design documents in the first place. Prefer minimal design document templates that allow authors to select the most useful sections and only insist on exhaustive details for the riskiest projects.

• Gather and review together, write alone. It’s very unlikely that you personally have all the relevant context to write the best de‐ sign document on a given topic. Before getting far into the pro‐ cess, collect input from folks with relevant perspectives, particu‐ larly those who will rely on the output of your design document. However, be skeptical of carrying that collaborative process into writing the design document itself. Most folks are better writers than they are editors. This means it’s usually harder to edit a group document into clear writing than to identify one author to write a clear document. Gather perspectives widely but write alone. Just be careful not to fall in love with what you’ve written until after you’ve reviewed it with others.

• Prefer good over perfect. It’s better to write a good document and get it in front of others than it is to delay for something marginally better. This is particularly valuable to keep in mind when giving feedback on other folks’ designs; it’s easy to fall into the trap of expecting their designs to be just as good as your best design. Particularly as you become more senior, it’s toxic to push every design to meet the bar of your own best work. Focus on pushing designs to be good, rather than fixating on your own best as the relevant quality bar.

It takes a lot of practice to write great design documents. If you want to improve yours, my best advice is to reread your designs after you’ve finished implementing them and study the places where your imple‐ mentation deviated from your plan–what caused those deviations? Oh, and of course, just keep writing more of them.

Synthesize those five design docs into a strategy

After your organization has written five design documents, sit down and read them all together. Look for controversial decisions that came up in multiple designs, particularly those that were hard to agree on. A recent example of mine was getting stuck debating whether Redis was appropriate as durable storage or only as a cache. Rather than starting from zero in each design document review, wouldn’t it be easier if we reviewed our recent decisions about using Redis, reflected on how we made those decisions and wrote them down as a strategy?

Good strategies guide tradeoffs and explain the rationale behind that guidance. Bad strategies state a policy without explanation, which decouples them from the context they were made. Without context, your strategy rapidly becomes incomprehensible–why did they decide this?–and difficult to adapt as the underlying context shifts. A few interesting strategies to read while thinking about writing your own are A Framework for Responsible Innovation and How Big Technical Changes Happen at Slack.

If you’re a Good Strategy, Bad Strategy convert–and that book has wholly transformed how I think about strategy–then you’ll note this definition of strategy is the “diagnosis” and “guiding policies” sections, deferring “coherent action” to the design documents.

My best advice for writing a strategy document is:

• Start where you are. Working on strategy, it’s easy to be para‐ lyzed by the inherently vast ambiguity we work in, but you’ve just got to dive in and start writing. Waiting for missing infor‐ mation doesn’t work: every missing document is missing for a good reason. Whatever you write will need to change, and if you write something particularly bad, you’ll quickly realize the need to change it. Where you are now is always the best place to start.

• Write the specifics. Write until you start to generalize, and then stop writing. If you can’t be specific, wait until you’ve written more design documents. Specific statements create alignment; generic statements create the illusion of alignment.

• Be opinionated. Good strategies are opinionated. If they aren’t opinionated, then they won’t provide any clarity on decision making. However, being opinionated on its own isn’t enough. You also need to show your work.

• Show your work. In math classes growing up, you had to show your work to get full credit. Here too, you must show the ra‐ tionale behind your opinions. Showing your work builds con‐ fidence in the first version of a document, but even more impor‐ tantly, by showing your work, you make it possible for others to modify and extend your work as the underlying context shifts.

Some of the best strategies you write may at the time feel too obvious to bother writing. “When should we write design documents?” is a strat‐ egy worth writing. “Which databases do we use for which use cases?” is a strategy worth writing. “How should we stage our migration from monolith to services?” is worth writing, too. As we leave behind the idea of strategy as demonstrations of brilliance, we can start to write far more of them, and we can write them more casually. If it ends up not being used, you can always deprecate it later.

Extrapolate five strategies into a vision

As you collect more strategies, it’ll become increasingly challenging to reason about how the various strategies interact. Maybe one of your strategies is to Run less software and rely more on cloud solutions, but another one of your strategies is to prefer offloading complexity to the database whenever possible. How do you reconcile those strategies if you identify a database that would allow you to offload a great deal of complexity, but that isn’t offered by your cloud vendor?

Take five of your recent strategies, extrapolate how their tradeoffs will play out over the next two to three years. As you edit through the contradictions and weave the threads together, you’ve written an engi‐ neering vision. The final version will give you what Tanya Reilly calls a robust belief in the future, which makes it easier to understand how your existing strategies relate to each other and simplifies writing new strategies that stand the test of time.

For a useful vision, a few things to focus on are:

• Write two to three years out. Companies, organizations, and technology all change quickly enough that thinking too far into the future is fraught. It also doesn’t work if you write a vision that expires in six months–how many strategies would you re‐ alistically write within that six‐month window? Try to focus on two to three years out; you can expand that horizon a bit if you’re a fairly established company.

• Ground in your business and your users. Effective visions ground themselves in serving your users and your business. That tight connection keeps the vision aligned with your lead‐ ership team’s core values–users and business. Bad visions treat technical sophistication as a self‐justifying raison d’être–a view that is never shared by your company’s leadership.

• Be optimistic rather than audacious. Visions should be ambi‐ tious, but they shouldn’t be audacious. They should be possible, but the best possible version if possible. Do write what you could accomplish if every project is finished on time and without ma‐ jor setbacks. Don’t write what you think would be possible with infinite resources.

• Stay concrete and specific. Visions get more useful as they get more specific. Generic statements are easy to agree with but don’t help reconcile conflicting strategies. Be a bit more detailed than you’re comfortable with. Details in visions are often illus‐ trative rather than declarative, giving a taste of the future’s flavor rather than offering a binding commitment.

• Keep it one to two pages long. The reality is that most people don’t read long documents. If you write something five or six pages long, readers will start dropping off without finishing it (or will skim it very rapidly without engaging with the details). Force yourself to write something compact, and reference extra context by linking to other documents for the subset of folks who want the full details.

After you finish writing your vision, the first step folks usually take is sharing it widely across the engineering organization. There is so much work behind the vision–five design docs for each strategy, five strategies for one vision–it’s hard not to get excited when you’re done. So excited that it’s easy to get discouraged, then, when the response to your strategy will almost always be muted. There are a few reasons for the muted response. First, the core audience for your vision is folks writing strategies, which is a relatively small cohort. Second, a great vision is usually so obvious that it bores more than it excites.

Don’t measure vision by the initial excitement it creates. Instead, mea‐ sure it by reading a design document from two years ago and then one from last week; if there’s marked improvement, then your vision is good.

Managing technical quality

I feel particularly impactful when I can help improve a proposal that’s well‐intentioned and solves a real need, but the team that drafted it lacks either experience or context to write a good plan to capture the opportunity. In such cases, having a well‐structured plan can help substantially reduce the scope while getting to most of the value, and thus demonstrate impact sooner. ‐ Dmitry Petrashko

If there’s one thing that engineers, engineering managers, and tech‐ nology executives are likely to agree on, it’s that there’s a crisis of tech‐ nical quality. One diagnosis and cure is easy to identify: our engineers aren’t prioritizing quality, and we need to hire better engineers or re‐ train the ones we have. Of course, you should feel free to replace “en‐ gineers” with “product managers” or “executives” if that feels more comfortable. It’s a compelling narrative with a clear villain, and it con‐ veniently shifts blame away from engineering leadership. Still, like most narratives that move accountability towards the folks with the least power, it’s both unhelpful and wrong.

When you accept the premise that low technical quality results from poor decision‐making, you start looking for bad judgment, and some‐ one at the company must be the culprit. Is it the previous CTO? Is it that Staff Engineer looking at you with a nervous smile? Is it everyone? What if it’s none of those folks, and stranger yet isn’t even your fault either?

In most cases, low technical quality isn’t a crisis; it’s the expected, normal state. Engineers generally make reasonable quality decisions when they make them, and successful companies raise their quality bar over time as they scale, pivot, or shift up‐market towards enter‐ prise users. At a well‐run and successful company, most of your pre‐ vious technical decisions won’t meet your current quality threshold.

Rather than a failure, closing the gap between your current and target technical quality is a routine, essential part of effective engineering leadership.

The problem

As an engineering leadership team, your goal is to maintain an appropriate technical quality level while devoting as much energy as possible towards the core business. You must balance quality across multiple timeframes, and those timeframes generally have conflicting needs. For example, you’ll do very different work getting that critical partnership out the door for next week’s deadline versus building a platform that supports launching ten times faster next quarter.

Just as your company’s technical quality bar will shift over time, your approach to managing technical quality will evolve in tandem:

1. fix the hot spots that are causing immediate problems

2. adopt best practices that are known to improve quality

3. prioritize leverage points that preserve quality as your software changes

4. align technical vectors in how your organization changes soft‐ ware

5. measure technical quality to guide deeper investment

6. spin up a technical quality team to create systems and tools for quality

7. run a quality program to measure, track and create accountabil‐ ity

As we dig into this toolkit of approaches, remember to pick the cheap‐ est, most straightforward tool likely to work. Technical quality is a long‐term game. There’s no such thing as winning, only learning and earning the chance to keep playing.

Ascending the staircase There’s a particular joy in drilling into the challenge at hand until you find a generalized problem worth solv‐ ing. However, an equally important instinct is solving the current situation quickly and moving on to the next pressing issue.

As you think about the right quality improvements to make for your team and organization, it’s generally most effective to start with the lightest weight solutions and only progress towards massive solutions as earlier efforts collapse under the pressure of scale. If you can’t get teams to adopt proper code linting, your attempts to roll out a compre‐ hensive quality program are doomed. Although the latter can be more effective at scale, they’re much, much harder to execute.

So, do the quick stuff first!

Even if it doesn’t work, you’ll learn more and more quickly from failing to roll out the easy stuff than failing to roll out the hard stuff. Then you’ll get to an improved second iteration sooner. Over time you will move towards comprehensive approaches, but there’s no need to rush. Don’t abandon the ease, joy, and innocence of early organizations for the perils of enterprise‐scale coordination without proper need.

It’s convenient to present these phases as a linear staircase to be ascended, but that’s rarely how real organizations use them. You’re more likely to fix a quality hot spot, roll out a best practice, start running an architecture review, abolish that architecture review, and go back to hot‐spotting for a bit. Premature processes add more friction than value and are quick to expose themselves as ineffective. If something isn’t working, try for a bit to make it work, and then celebrate its demise.

Hot spots

When confronted by a quality problem, the first instinct is often to identify a process failure that necessarily requires a process solution.

If a deployment causes an outage, it’s because the author didn’t cor‐ rectly follow the code test process, so now we’re going to require tests with every commit – that’ll teach those lazy developers!

There’s the old joke about Sarbannes‐Oxley: it doesn’t reduce risk; it just makes it clear who to blame when things go wrong. Unfortunately, that joke applies without humor to how many organizations roll out processes. Accountability has its role, but it’s much more important to understand the problem at hand and try to fix it directly than to create process‐driven accountability.

Process rollout requires humans to change how they work, which you shouldn’t undertake lightly. Rather than reaching for process improvement, start by donning the performance engineer’s mindset. Measure the problem at hand, identify where the bulk of the issue occurs, and focus on precisely that area.

The previous example of an untested deploy might benefit from giving direct feedback to the deploying engineer about changing their testing habits. Alternatively, maybe you’re better served by acknowledging that your software design is error‐prone and adopting the “define er‐ rors out of existence” approach described in A Philosophy of Software Design.

If you have a development velocity problem, it might be optimizing test runtimes, moving your Docker compile step onto a RAM disk, or using the techniques described in Software Design X‐Rays to find the specific files to improve.

Systems thinking is the most transformative thinking technique I’ve encountered in my career. Still, at times it can be a siren beckon‐ ing you towards fixing a current system you may be better discarding. Sure, you can roll out a new training program to teach your team how to write better tests, but alternatively, maybe you can just delete the one test file where 98% of test failures happen. That’s the unreason‐ able effectiveness of prioritizing hot spots and why it should be the first technique you use to improve technical quality.

At some point, you’re likely to find that your organization is creating quality problems faster than you’re able to fix hot spots, and that’s when it’s time to move on to adopting best practices.

Best practices

I once worked at a company that didn’t have a team planning process. Over time the head of engineering was increasingly frustrated with the inability to project target dates and mandated that we use Scrum. After the mandate, a manager wrote the Scrum process on a wiki. There was an announcement that we were using Scrum. Managers told their teams to use Scrum. Mission accomplished!

Of course, no one started to use Scrum. Everyone kept doing what they’d done before. It’s awkward to acknowledge mistakes, so the head of engineering declared adoption a major win, and no one had the heart to say differently.

This sad tale mirrors how many companies try to roll out best prac‐ tices, and it’s one of the reasons why best practices have such a bad reputation. In theory, organizations would benefit from adopting best practices before fixing quality hot spots, but I recommend practices after hot spotting. Adopting best practices requires a level of organi‐ zational and leadership maturity that takes some time to develop.

When you’re rolling out a new practice, remember that a good pro‐ cess is evolved rather than mandated. Study how other companies adopt similar practices, document your intended approach, experi‐ ment with the practice with a few engaged teams, sand down the rough edges, improve the documentation based on the challenges, and only then roll it out further. A rushed process is a failed process.

Equally important is the idea of limiting concurrent process rollouts.

If you try to get teams to adopt multiple new practices simultaneously, you’re fighting for their attention with yourself. It also makes it harder to attribute impact later if you’re considering reverting or modifying one of the new practices. It’s a bit draconian, but I’ve come to believe that you ought to limit yourself to a single best practice rollout at any given time. Channel all your energy towards making one practice a success rather than splitting resources across a handful.

Adopting a single new practice at a time also forces you to think care‐ fully about which to prioritize. Selecting your next process sounds easy, but it’s often unclear which best practices are genuinely best practice and which are just familiar or famous. Genuine best prac‐ tice has to be supported by research, and the best source of research on this topic is Accelerate.

While all of Accelerate’s recommendations are data‐driven and quite good, the handful that I’ve found most helpful to adopt early are ver‐ sion control, trunk‐based development, CI/CD, and production observ‐ ability (including developers on‐call for the systems they write), and working in small, atomic changes. There are many other practices I’d love to advocate for (who hasn’t spent a career era advocating for bet‐ ter internal documentation), but I don’t trust my intuition like I once did.

The transition from fixing hot spots to adopting best practices comes when you’re overwhelmed by too many hot spots to cool. The next tran‐ sition, from best practices to leverage points, comes when you find yourself wanting to adopt a new best practice before your in‐progress best practice is working. Rather than increasing your best practice adoption‐in‐progress limit, move on to the next tool.

Leverage points

In the Hotspotting section, we talked about using the performance en‐ gineer’s mindset to identify the right problems to fix. Optimization works well for the issues you already have, but it’s intentionally inap‐ plicable to the future: the worst sin of performance engineering is ap‐ plying effort to unproven problems.

However, as you look at how software changes over time, there are a small handful of places where extra investment preserves quality over time, both by preventing gross quality failures and reducing the cost of future quality investments.

I call those quality leverage points, and the three most impactful points are interfaces, stateful systems, and data models.

Interfaces are contracts between systems. Effective interfaces decou‐ ple clients from the encapsulated implementation. Durable interfaces expose all the underlying essential complexity and none of the under‐ lying accidental complexity. Delightful interfaces are Eagerly discern‐ ing, discerningly eager.

State is the hardest part of any system to change, and that resistance to change makes stateful systems another critical leverage point. State gets complex faster than other systems and has an inertia that makes it relatively expensive to improve later. As you incorporate business obligations around security, privacy, and compliance, changing your stateful systems becomes even more challenging.

Data models are the intersection of the interfaces and state, constrain‐ ing your stateful system’s capabilities down to what your application considers legal. A good data model is rigid: it only exposes what it gen‐ uinely supports and prevents invalid states’ expression. A good data model is tolerant of evolution over time. Effective data models are not even slightly clever.

As you identify these leverage points in your work, take the extra time to approach them deliberately. If it’s an interface, integrate half a dozen clients against the mocked implementation. If it’s a data model, represent half a dozen real scenarios. If it’s stateful, exercise the failure modes, check the consistency behaviors, and establish performance benchmarks resembling your production scenario.

Take everything you’ve learned, and pull it into a technical specifica‐ tion document that you socialize across your team. Gather industry feedback from peers. Even after you begin implementation, listen to reality’s voice and remain open to changes.

One of the hidden powers of investing in leverage points is that you don’t need total organizational alignment to do it. To write a technical vision or roll out a best practice, you need that sort of buy‐in, which is why I recommend starting with leverage points. However, if you’ve exhausted the accessible impact from leverage points, it may be time to move on to driving broader organizational alignment.

Technical vectors

Effective organizations marshal the majority of their efforts towards a shared vision. If you plot every technical decision as a vector on a grid, the more those vectors point in the same direction, the more you’ll accomplish over time. Conversely, some of the most impressive engineers I’ve worked with created vectors with an extraordinary mag‐ nitude but a misaligned direction. Ultimately those engineers harmed their organizations in their attempts to lead it.

One sure‐fire solution to align technical direction is to route all related decisions to the same person with Architect somewhere in their title. This works well but is challenging to scale, and the quality of an ar‐ chitect’s decisions degrade the further they get from doing real work on real code in the real process. On the other extreme, you can allow every team to make independent decisions. But an organization that allows any tool is an organization with uniformly unsupported tooling. Your fundamental tools for aligning technical vectors are:

• Give direct feedback. When folks run into misalignment, the first answer is often process change, but instead, start with simply giving direct feedback to the individuals who you believe are misaligned. As much as they’re missing your context, you’re missing theirs, and a quick conversation can often prevent years of unnecessary process.

• Refine your engineering strategy from tech spec, to strategy, to vision.

• Encapsulate your approach in your workflows and tooling. Documentation of a clear vision is helpful, but some folks simply won’t study your document. Deliberate tools create workflows that nurture habits far better than training and documentation. For example, provisioning a new service might require going to a website that requires you to add a link to a technical spec for that service. Another approach might be blocking deploys to production if the service doesn’t have an on‐call setup established, with someone currently on‐call, and that individual must also have their push notifications enabled.

• Train new team members during their onboarding. Changing folks’ habits after they’ve formed is quite challenging, which is frustrating if you’re attempting to get folks to adopt new prac‐ tices. However, if you get folks pointed in the right direction when they join, then that habit‐momentum will work in favor of remaining aligned.

• Use Conway’s Law. Conway’s Law argues that organizations build software that reflects their structure. If your organiza‐ tion is poorly structured, this will lead to tightly coupled or tangled software. However, it’s also a force for quality if your organization’s design is an effective one.

• Curate technology change using architecture reviews, invest‐ ment strategies, and a structured process for adopting new tools. Most misalignment comes from missing context, and these are the organizational leverage points to inject context into decision‐making. Many organizations start here, but it’s the last box of tools that I recommend opening. How can you provide consistent architecture reviews without an articulated vision? Why tell folks your strategy after they’ve designed something rather than in their onboarding process?

Regardless of the approaches you use to align your technical vectors, this is work that tends to happen over months and years. There’s no world where you write the vision document, and the org immediately aligns behind its brilliance. Much more likely is that it gathers dust until you invest in building support.

Most companies can combine the above techniques from hot‐spot fix‐ ing to vector‐alignment into a successful approach for managing tech‐ nical quality, and hopefully, that’s the case for you. However, many find that they’re not enough and that you move towards heavier ap‐ proaches. In that case, the first step is, as always, measurement.

Measure technical quality

The desire to measure in software engineering has generally outpaced our state of measurement. Accelerate identifies metrics to measure ve‐ locity, which are powerful for locating process and tooling problems, but these metrics start after the code’s been merged. How do you mea‐ sure your codebase’s quality such that you can identify gaps, propose a plan of action, and evaluate the impact of your efforts to improve?

There are some process measurements that correlate with effective changes. For example, you could measure the number of files changed in each pull request on the understanding that smaller pull requests are generally higher quality. You could also measure a codebase’s lines of code per file, on the assumption that very large files are generally hard to extend. These could both be quite helpful, and I’d even recommend measuring them, but I think they are at best proxy measurements for code quality.

My experience is that it is possible to usefully measure code quality, and it comes down to developing an extremely precise definition of quality. The more detailed you can get your definition of quality, the more useful it becomes to measure a codebase, and the more instructive it becomes to folks hoping to improve the quality of the area they’re working on. This approach is described in some detail in Building Evolutionary Architectures and Reclaim unreasonable software.

Some representative components to consider including in your quality definition:

• What percentage of the code is statically typed?

• How many files have associated tests?

• What is test coverage within your codebase?

• How narrow are the public interfaces across modules?

• What percentage of files use the preferred HTTP library?

• Do endpoints respond to requests within 500ms after a cold start?

• How many functions have dangerous read‐after‐write behavior? Or perform unnecessary reads against the primary database in‐ stance?

• How many endpoints perform all state mutation within a single transaction?

• How many functions acquire low‐granularity locks?

• How many hot files exist which are changed in more than half of pull requests?

You’re welcome to disagree that some of these properties ought to ex‐ ist in your codebase’s definition of quality: your definition should be specific to your codebase and your needs. The important thing is de‐ veloping a precise, measurable definition. There will be disagreement in the development of that definition, and you will necessarily change the definition over time.

After you’ve developed the definition, this is an area where instrumen‐ tation can be genuinely challenging, and instrumentation is a require‐ ment for useful metrics. Instrumentation complexity is the biggest friction point for adopting these techniques in practice, but if you can push through, you unlock something pretty phenomenal: a real, dy‐ namic quality score that you can track over time and use to create a clarity of alignment in your approach that conceptual alignment can‐ not.

With quality defined and instrumented, your next step is deciding be‐ tween investing in a quality team or a quality program. A dedicated team is easy to coordinate and predictable in its bandwidth and is gen‐ erally the easier place to start.

Technical quality team

A technical quality team is a software engineering team dedicated to creating quality in your codebase. You might call this team Developer Productivity, Developer Tools, or Product Infrastructure. In any case, the team’s goal is to create and preserve quality across your company’s software.

This is not what’s sometimes called a quality assurance team. Al‐ though both teams make investments into tests, the technical quality team has a broader remit from workflow to build to test to interface design.

When you’re bootstrapping such a team, start with a fixed team size of three to six folks. Having a small team forces you to relentlessly priori‐ tize their roadmap on impact and ensures you’ll maintain focus on the achievable. Over time this team will accumulate systems to maintain that require scaling investment, Jenkins clusters are a common exam‐ ple of this, and you’ll want to size the team as a function of the broader engineering organization. Rules of thumb are tricky here, but maybe one engineer working on developer tooling for every fifteen product engineers, in addition to your infrastructure engineering investment.

It’s rare for these teams to have a product manager, generally one‐or‐ more Staff‐plus engineers, and the engineering manager partner to fill that role. Sometimes they employ a Technical Program Manager, but typically that is after they cross into operating a Quality program as described in the next section.

When spinning up and operating one of these teams, some fundamen‐ tals of success are:

1. Trust metrics over intuition. You should have a way to measure every project. Quality is a complex system, the sort of place where your intuition can easily deceive you. Similarly, as you become more senior at your company, your experience will no longer reflect most other folks’ experiences. You already know about the rough edges, and you’ll be the first person in line to get help if you find a new one, but most other folks don’t. Met‐ rics keep you honest.

2. Keep your intuition fresh. Code and process change over time, and your intuition is going stale every week you’re away from building product features. Most folks find that team embedding and team rotations are the best way to keep your instincts rel‐ evant. Others monitor chat for problems, as well as a healthy schedule of 1:1 discussions with product developers. The best folks do both of those and keep their metrics dashboards handy.

3. Listen to and learn from your users. There is a popular idea of

“taste level,” which implies that some folks simply know what good looks like. There is a huge variance in folks who design effective quality investments, but it isn’t an innate skill. The best folks focus on deeply understanding what their users are trying to accomplish and prioritize user needs over implementation constraints.

Adoption and usability of your tools are much more important than raw power. A powerful tool that’s difficult to use will get a few power users, but most folks will pass it by. Slow down to get these details right. Hide all the accidental complexity. Watch an engineer try to use your tool for their first time without helping them with it. Improve the gaps. Do that ten more times! If you’re not doing user research on your tools, then you are doomed as a quality investment team. 4. Do fewer things, but do them better. When you’re building for the entire en‐ gineering organization, anything you do well will accelerate the over‐ all organization. Anything you do poorly, including something almost great with too many rough edges, will drag everyone down. Although it’s almost always true that doing the few most important things will contribute more than many mediocre projects, this is even more true in cases where you’re trying to roll out tools and workflows to your entire organization (the organizational process‐in‐progress limits still apply here!). 5. ** Don’t hoard impact.** There’s a fundamental ten‐ sion between centralized quality teams and the teams that they sup‐ port. It’s often the case that there’s a globally optimal approach pre‐ ferred by the centralized team, which grates heavily on a subset of teams that work on atypical domains or workloads. One representa‐ tive example is a company writing its backend servers in JavaScript and not allowing their machine learning engineers to use the Python ecosystem because they don’t want to support two ecosystems. An‐ other case is a company standardized on using REST/HTTP2/JSON for all APIs where a particular team wants to use gRPC instead. There’s no perfect answer here, but it’s important to establish a thoughtful ap‐ proach that balances the benefits of exploration against the benefits of standardization.

A successful technical quality team using the above approaches will be unquestionably more productive than if the same number of engineers were directly doing product engineering work. Indeed, discounted de‐ veloper productivity (in the spirit of discounted cash flow) is the theo‐ retically correct way to measure such a team’s impact. Only theoreti‐ cally, because such calculations are mostly an evaluation of your self‐ confidence.

Even if you’re quite successful, you’ll always have a backlog of high‐ impact work that you want to take on but don’t have the bandwidth to complete. Organizations don’t make purely rational team resourcing decisions, and you may find that you lack the bandwidth to complete important projects and likewise can’t get approval to hire additional folks onto your team.

It’s a good sign when your team has more available high‐impact work than you can take on: if you aren’t selective about which projects to take on, then you’re not thinking broadly enough. This means you shouldn’t necessarily try to grow your technical quality team if you have a backlog. However, if you find that there is critical quality work that you can’t get to, then it may be time to explore starting a quality program.

Quality program

A quality program isn’t computer code at all, but rather an initiative led by a dedicated team to maintain technical quality across an orga‐ nization. A quality program takes on the broad remit of achieving the organization’s target level of software quality. These are relatively un‐ common, but something similar you’ve probably encountered is an incident program responsible for a company’s incident retrospectives and remediations.

The technical components of running a quality program are the sorts of things discussed above, so here we’ll focus on managing a program effectively. Your first step is to find a technical program manager who can co‐lead the program and operate its mechanics. While you can make considerable progress on an organizational program’s informa‐ tional aspects without a technical program manager; however, it’s a trap. You’ll be crushed by the coordination overhead of solo‐driving a program in a large organization.

Operating organizational programs is a broad topic about which much has been written, but the core approach is:

1. Identify a program sponsor. You can’t change an organization’s behavior without an empowered sponsor. Organizations behave the way they do because it’s the optimal solution to their current constraints, and you can’t shift those constraints without the ad‐ vocacy of someone powerful.

2. Generate sustainable, reproducible metrics. It’s common for folks running a program to spend four‐plus hours a week main‐ taining their dataset by hand. This doesn’t work. Your data will have holes in it, you won’t be able to integrate your data with automation in later steps, and you’ll run out of energy to do the work to effect real change; refreshing a metrics dashboard has no inherent value.

3. Identify program goals for every impacted team and a clear path for them to accomplish those goals. Your program has to identify specific goals for each impacted team. For example, re‐ ducing test flakiness in their tests or closing incident remedia‐ tions more quickly. However, it’s essential that you provide the map to success! So many programs demand participation from other teams without providing clear directions on how they can accomplish their part. The program owner is the subject mat‐ ter expert, don’t offload your strategy to every team to indepen‐ dently reinvent.

4. Build the tools and documentation to support teams towards their goals. Once you’ve identified a clear path for teams to ac‐ complish your program goals, figure out how you can help them make those changes! This might be providing “golden examples” of what things ought to look like, or an example pull request refactoring a challenging section of code into the new pattern. It might be providing a test script to verify the migration worked correctly. It might be auto‐generating the conversion commit to test, verify, and merge without having engineers write it them‐ selves. Do as much as you possibly can to avoid every team hav‐ ing to deeply understand the problem space you’re attempting to make progress in.

5. Create a goal dashboard and share it widely. Once you have your program goals communicated to each team, provide dashboards that help them understand their current state, their goal state, and that give reinforcing feedback on their (hopeful) progress along the way. The best dashboard is going to be both a scorecard for each team’s work and also provide breadcrumbs for each team on where to focus their next efforts.

There are three distinct zoom‐levels that your dashboard should support. The fully zoomed‐out level helps you evaluate your pro‐ gram’s impact. The fully zoomed‐in level helps an individual team understand their remaining work. A third level between the two helps organizational leaders hold their teams account‐ able (and supports your program sponsor in making concrete, specific asks to hold those leaders accountable).

6. Send programmatic nudges for folks behind on their goals.

Folks are busy. They won’t always prioritize your program’s goals. Alternatively, they might do an amazing job of making your requested improvements but backtrack later with depre‐ cated practices. Use nudges to direct the attention of teams towards the next work they should take towards your program’s goals. Remember, attention is a scarce resource! If you waste folks’ time with a nudge email or ping, they won’t pay attention to the next one.

7. Periodically review program status with your sponsor. Pro‐ grams are trying to make progress on an organizational priority that doesn’t naturally align with the teams’ goals. Many teams struggle to break from their local prioritization to accomplish global priorities. This is where it’s essential to review your over‐ all progress with your sponsor and point them towards the teams that prioritize program work. Effectively leveraging your spon‐ sor to bridge misaligned prioritization will be essential to your success.

In a lot of ways, a program is just an endless migration, and the tech‐ niques that apply to migrations work for programs as well.

If you get all of those steps right, you’re running a genuinely great pro‐ gram. This might feel like a lot of work, and wow, it is: a lot of pro‐ grams go wrong. The three leading causes of failed programs are:

1. running it purely from a process perspective and becoming de‐ tached from the reality of what you’re trying to accomplish,

2. running it purely from a technical perspective and thinking that you can skip the essential steps of advocating for your goal and listening to the folks you’re trying to motivate,

3. trying to cover both perspectives as a single person–don’t go it alone!

A bad program is a lot like an inefficient non‐profit: the goal is right, but few funds reach the intended goal. No matter how you decide to measure technical quality, the most important thing to always remem‐ ber when running your quality program is that the program isn’t the goal. The goal is to create technical quality. Organizational programs are massive and build so much momentum that inertia propels them forward long after they’ve stopped working. Keep your program lean enough to cancel, and remain self‐critical enough to cancel if it ceases driving quality creation.

Start small and add slowly

When you realize your actual technical quality has fallen considerably behind your target technical quality, the natural first reaction is to panic and start rolling out a vast array of techniques and solutions. Dumping all your ingredients into the pot, inevitably, doesn’t work well, and worse, you don’t even know which parts to keep.

If you find yourself struggling with technical quality–and we all do, frequently–then start with something small, and iterate on it until it works. Then add another technique, and iterate on that too. Slowly build towards something that genuinely works, even if it means weath‐ ering accusations of not moving fast enough. When it comes to com‐ plex systems and interdependencies, moving quickly is just optics. It’s methodical movement that gets the job done.

Stay aligned with authority

In my role, we’ll often go weeks without being in the same room together, but I still have to operate as if I’m his direct proxy. So I go into a room and think, “What would Matthew do here? What is the question he would want to ask? What guidance has he given on this problem?” Because I can’t always run back to him for clarification, it’s essential to develop and maintain a deep understanding of his world view. That’s essential for me to retain the very deep trust required to be his representative and effectively carry out his strategy and vision. People need to be confident that I’ll always give the same answer that Matthew would give if he were there. ‐Rick Boone

It’s a common misconception that authority makes you powerful. Many folks aspiring towards more senior roles assume they’ll finally get to do things their way. They believe that the title inherently cre‐ ates flexibility and autonomy. They believe that the friction holding them back will burst into a whirl of butterflies that scatter into the wind.

The reality is a bit more nuanced.

Titles come with the sort of power called organizational authority, and that variety of authority is loaned to you by a greater organizational authority. What’s bestowed can also be retracted, and retaining or‐ ganizational authority depends on remaining deeply aligned with the bestowing sponsor, generally your direct manager. To remain effec‐ tive within a staff‐plus role, you have to learn the art of staying aligned with organizational authority.

Beyond the safety net

Retire your remaining expectations that the company is designed to set you up for success. Now you are one of the people responsible for setting the company, your team, and your manager up for success.

Most mature technology companies succeed in creating a predictable promotion pipeline from folks joining early in their careers up through attaining the Senior Engineer title. The process of getting a Staff title is generally more complex than preceding titles but usually navigated with the support of your engineering manager. Throughout this pipeline, you may become comfortable with your manager guiding your development and providing a safety net for your continued success. After reaching a Staff role, your safety net will cease to exist, or at best, the safety net will be short enough that you’re quite capable of jumping past it and into the awaiting chasm. This will be increasingly true as you go further into Senior Staff and Distinguished Engineer roles.

Staff‐plus roles are leadership roles, and in leadership roles, the sup‐ port system that got you here will fade away. Often abruptly, you’re now expected to align the pieces around you for your own success.

Serving at the pleasure of the President

When Rick Boone described his role as Strategic Advisor to the Vice‐ President of Infrastructure at Uber, he compared his role to Hand of the King in Game of Thrones, and Leo McGarry from The West Wing who frequently remarked, “I serve at the pleasure of the President.” In both those examples, authority flows from the tight association with greater authority, and it’s a great mental model for operating in a Staff‐plus role. This can be a difficult transition from previous roles where your authority primarily accumulated through your personal actions and impact over time.

If you and your manager have worked together for years, then you’ve already performed a subtle, subterranean sort of alignment over that time. In other cases, a new executive will join who is familiar with sup‐ porting these roles and will bring a deliberate map to how they want to work together. However, both of those circumstances are largely out of your control, so it’s valuable to develop your own approach to aligning upward with your manager.

To align with your manager, some areas to focus on are:

• Never surprise your manager. Nothing destroys trust faster than surprising your manager. Steering a large organization often involves juggling several projects and problems in your head at once, and surprises threaten the juggler’s rhythm. Large or frequent surprises also call into question whether a leader is truly taking responsibility for their organization. In general, treat each time you surprise your manager as an incident to be learned from and endeavor to prevent repeats.

• Don’t let your sponsor surprise you. Most folks have extremely high expectations of their managers, assuming, for example, that they will always remember to relay information relevant to your current work. Managers try to do this, some of them are excellent at it, and others are not particularly good. If your manager isn’t great at this, you should certainly give them feedback, but you should also take proactive action to facilitate information flow. This might be weekly email updates or a Slack thread within your team’s channel sharing your focuses for the week. During 1:1s, dig for the feedback! Ask if there are other areas you should be focused on and how your current priorities align with your manager’s. If you continue to surprise each other, then identify the controls you’ll use to partner together.

• Feed your manager’s context. If the first step is avoiding sur‐ prising your manager with your own actions, the next step is to help your manager not get surprised by the wide organization. If teams are frustrated by a new policy or your internal tools aren’t scaling with needs, proactively feed that to your manager. Be clear that you’re not bringing them a problem to solve, rather conveying information you believe will be useful. Opinions are helpful, but even more helpful is data when you can find it.

Sometimes you’ll hear someone disparage a colleague, saying that they’re excellent at “managing up.” There are certainly destructive ways to manage up where someone controls information to hide problems or misrepresent circumstances, but at its core, managing up is about increasing bandwidth and reducing friction between you and your manager. Cultivating a deliberate partnership with your manager will go far further than practicing disappointment when they don’t meet your expectations.

Influencing without too much friction

Part of growing as a leader in developing your own perspective on how the world should work, and you can’t reach the Staff‐plus level without that perspective. Having a clear sense of how things ought to work sharpens your judgment and enables you to act proactively. As you reach this next step of leadership, you increasingly have to merge your vision with those held by more senior organizational leaders.

Your first approach to solving this problem might be replacing your vision with another leader’s vision, and that approach works for some, but for many, it means stepping away from the perspective that facili‐ tated their success as a proactive leader with strong judgment. Instead, I recommend sharpening your awareness of the value distinctions be‐ tween those that you hold and those that the organization operates under and find a way to advocate for them without getting kicked out of the room.

People can only change so quickly, and organizations are made of peo‐ ple. If you’re deliberate in your approach, you’ll be able to influence your organization’s leaders immensely over time, but you’ll only get that time if you learn to remain in tight alignment at each step along the way.

To lead, you have to follow

It’s about taking that global thinking and applying it locally. That means aligning your team’s (technical) initia‐ tives/roadmaps to the Engineering–wide technical strategy; and being intentional about when you veer off of that path to serve the needs of your team’s immediate stakeholders. That means collaborating with your team’s managers in adopting successful practices in hiring, onboarding, and production operations from other teams; and sharing practices from your team that would be beneficial for others. That means taking context from company‐wide business/product strategy and translating that to how it impacts your team’s immediate projects ‐ Ras Kasa Williams

Years ago, the company I was working with hired a new Director of En‐ gineering, and the CTO was talking about why the new Director was an amazing hire. The new Director’s clinching accomplishment? The best ever explanation of the distinction between leadership and man‐ agement. This turned out not to be a particularly effective way to eval‐ uate hires, but it is an interesting topic.

Defining leadership and management is such heavily trodden terrain that it’s hard to add much to it, but roughly management is a specific profession, and leadership is an approach one can demonstrate within any profession.

The way I think about leadership has evolved a bit over the last few years, though, coming to focus on two specific attributes. First, lead‐ ers have a sufficiently refined view of how things ought to work that they can rely on their distinction between how things are and how they ought to be to identify proactive, congruent actions to narrow that gap. Second, they care enough about the gap to actually attempt those nar‐ rowing actions.

If you only see the gap without acting on it, you might be a visionary, but you’re inert. If you take action without a clear view of the goal, many will consider you a leader, but your impact will be random, ar‐ bitrary, and inefficient. Combining both with some luck is likely to take you a long way in your career, and these are characteristics com‐ mon in folks I’ve worked with who successfully navigate the transition into staff engineering or senior management roles.

But this sort of leadership can only take you so far, and personally, it took me years of blundering to understand why my approach to lead‐ ership created so much early success for me when first joining a com‐ pany but slowly eroded how my contribution was received over time. The lesson that I slowly learned was that you couldn’t be an effective long‐term leader until you learn how to follow.

I think this is the most important lesson I’ve learned over the past few years: the most effective leaders spend more time following than they do leading. This idea also comes up in the idea of the “the first follower creates a leader,” but effective leaders don’t split the world into a leader and follower dichotomy, rather they move in and out of leadership and follower roles with the folks around them.

There are many ways to put this approach into practice.

1. Be clear with yourself what your true priorities are, and don’t dilute yourself across everything that comes up. If there’s some‐ thing you disagree with but only in a minor way, let others take the lead figuring it out. A helpful question here is, “Will what we do here matter to me in six months?” If it won’t, take the oppor‐ tunity to follow.

2. Give your support quickly to other leaders who are working to make improvements. Even if you disagree with their initial ap‐ proach, someone trustworthy leading a project will almost al‐ ways get to a good outcome. If someone trustworthy is leading a project, and you’re still uncomfortable letting them move for‐ ward, consider why you lack confidence in your ability to influ‐ ence them and if you’re bad at giving feedback.

3. Make your feedback explicitly non‐blocking. This can be clas‐ sifying a code review comment as an “optional nit,” but it can also be writing up detailed feedback but delivering it to some‐ one mentioning that you wanted to share your perspective rather than necessarily change their approach.

If this is something you’ve struggled with, I’m sympathetic. I’ve strug‐ gled with it too. When you have a strong enough worldview to lead, you’ll start to collect others around you who rely on you maintaining that world’s physics, and tolerating any deviation from your vision can feel like you’re letting them down. But this is the epitome of some‐ thing that’ll get you to one level of success but block the next: contin‐ ued growth requires learning to incorporate your worldview into the worldviews of those around you, accelerating overall progress around you even if it means tolerating a detour from your vision.

What you can accomplish alone is far from what you can accomplish by creating leaders. To be a great leader, take your time learning to follow.

Learn to never be wrong

I present what I think is the best case for us, and people can disagree with that. And, you know, they often do. I’m steering and influencing more than saying, “I’ve got the authority to just tell you what to do.” I’ve never seen that style work well. ‐ Keavy McMinn

Most folks have worked with someone who thinks they’re never wrong. In each discussion, they lean in, broaden their shoulders and breach their way into the role of the decider. They’ll continue debating until their perspective wins the day or time runs out. They are often right, but right in a way that sucks the oxygen out of the room. As their tenure at a company increases, they may fancy that they’ve become very persuasive, but frequently it’s a form of persuasion characterized by the resignation of their peers.

A few of the technical leaders that I’ve worked with have found a way to never be wrong without dominating the room. To be right while creating space for others. Someone who has always embodied this approach for me is Franklin Hu, who I’ve seen reliably disarm con‐ tentious discussions with his commitment to finding the best outcome for everyone, willingness to leave his starting position and the default assumption that there’s always an additional piece of context that rec‐ onciles seemingly conflicting perspectives into a unified view.

To become a senior technical leader, you must build a deep perspec‐ tive on technology and architecture. To operate as such a leader, you must then develop an equally deep pragmatism and agnosticism to technical religion to remain skeptical of yourself. This can feel like a paradox, but it’s the line you’ll need to walk every day.

Listen, clarify and read the room

A lot of times, you’ll see engineers go into a discussion confident that their perspective is right and with the goal of getting other folks in the room to agree with their approach. This mentality turns each meeting into a zero‐sum debate. Even in the “best case” that their approach is agreed upon, they didn’t get to learn from anyone else in the room, and it’s unlikely that the rest of the room is leaving energized.

The most effective engineers go into each meeting with the goal of agreeing on the problem at hand, understanding the needs and perspectives within the room, and identifying what needs to happen to align on an approach. They approach each meeting as one round within the broader context of the project and their relationships with the folks in the room. If the room is ready to agree and move forward on a solution, they land the team on that approach. If the room isn’t ready, they don’t force it to happen.

To get good at this, you need to master three approaches: listen through questions, define the purpose, and know how to read the room.

Listening through questions is a form of active listening with the goal of understanding the rest of the room’s perspectives. The act of ask‐ ing good questions with good intent opens up a conversation, creating space and safety for others to ask their own questions. Good questions are asked with the desire to learn, and they are specific. They sharpen the conversation. They free the answerer from the obligation to de‐ fend their position. In a potentially contentious meeting, ask three good questions before you share your perspective, and you’ll see the room shift around you.

Good meetings start from a clear purpose and agenda, but many meet‐ ings don’t meet that definition of a good meeting, particularly ad‐hoc discussions. If you ever find yourself in a conversation with an un‐ clear goal, then define the purpose. Take a moment to ask if your understanding of what the group hopes to accomplish is correct. This works best as a statement wrapped in a clarifying question along the lines of, “Just to check, our goal here is to decide whether to postpone launching the project by two weeks?”

Note that defining the purpose can be disruptive if it’s used too fre‐ quently. Rather than helping to clarify the conversation, in that case, it creates conversational churn. For the most part, try to avoid using it if someone else has already made an attempt. Meetings with multiple failed reframings almost always end with scheduling another meet‐ ing.

Finally, in each meeting, you have to read the room. Oftentimes folks get frustrated with a conversation and try to force agreement, which creates so much pressure on the discussion that it’s unlikely to con‐ clude well. If the folks in the room are too far apart, then identify a subgroup who are able to spend more time digging into it together or identify an appropriate party to escalate to outside of the room. If there’s simply too much stuff in the drawer, stop trying to shove it shut.

How to practice

If these behaviors don’t come naturally to you, that’s okay; the oppor‐ tunity to practice is all around. Every comment on a document is an opportunity. Every meeting is an opportunity. Every pull request is an opportunity.

Start each week by picking one of these skills you want to explicitly use in the meetings you head into. If you have a particularly difficult meeting come up, spend some time practicing in your head or with a peer on how you might use these approaches to facilitate forward progress despite the challenges.

Jerks

The above approach works well most of the time, but not always, and one of the notable exceptions is when you’re dealing with a jerk. In this case, a jerk is someone who withholds their consent from the group, isn’t willing to compromise, or doesn’t listen. This is someone who hasn’t learned that their career depends more on being easy to involve than being technically correct.

The two most effective ways to deal with jerks are:

1. including someone they can’t be a jerk to in the meeting (like their manager or the CTO)

2. investing heavily into aligning with them before the meeting, so they feel heard and are less likely to derail the discussion

Both of these can feel ridiculous to spend your time on, but they’re what tends to work best, especially if it’s a jerk you interact with in‐ frequently. If it’s someone in an area that you’re responsible for or someone you work with frequently, then you have a somewhat differ‐ ent set of obligations. In that case, give them the feedback as kindly as you can while still being honest. Give it a second time. Document both, and if you don’t see an improvement, then communicate the concerns to their manager, including the specific documentation, in a face to face or video discussion.

It’s also useful to recognize that the authority created by your title shel‐ ters you from many of these folks, so whoever you’re experiencing is being less of a jerk to you than they are to others. If the behavior feels borderline for you, it’s potentially more egregious for others.

How it helps

This approach is powerful because more complex projects get derailed by personal conflict than by technical complexity, and this is a repeat‐ able way to replace tension with partnership. It feels like it’s slow be‐ cause it can take longer to get started, but ultimately it’s fast because you’re more likely to complete the work without disruption.

In addition, longevity as a senior leader is just as much about main‐ taining your relationships as it is about standout successes. You’ll see a bunch of folks who burn bright for a while but later lack the support to make forward progress. If you want to avoid that fate, learn to never be wrong and never stop practicing.

Create space for others

At this point, I spend less time advocating for specific technolo‐ gies or programs and more time empowering others to advocate for the technologies and programs that they think are impor‐ tant. I also try to be a source of knowledge and support that people can reach out to for feedback, especially on cross‐cutting product decisions and on presentation of ideas to the rest of the organization. ‐ Michelle Bu

One of the best measures of your long‐term success as a Staff‐plus en‐ gineer is that the organization around you increasingly benefits from, but doesn’t rely upon, your contributions. Because many folks reach their first Staff‐plus role by being the “go‐to” person for the organiza‐ tion, it can be a difficult transition from essential to adjacent.

This transition requires learning to deliberately create space for the team around you and comes down to actively involving them in discus‐ sions, decisions, and ultimately substituting sponsorship for repeat‐ ing the successes that got you to Staff in the first place.

Discussions

When you’re focused on maximizing your personal impact, a good dis‐ cussion is one that ends quickly with a reasonable answer, alignment among the participants, and positive feelings among the participants. When you start thinking about creating space, the definition of a good meeting expands quite a bit!

In this broader definition, a good meeting depends on getting more folks involved and getting to a good set of decisions without much of your own personal contribution. A good meeting is, in this new world, one that it turns out you didn’t need to attend. When you make a key contribution, feel good about it, and then think about what needs to happen for someone else to make that contribution next time.

Along with the shift in mindset, there are a few techniques that I’ve found helpful in creating more space in discussions:

• Shift your contribution towards asking questions. Asking the right questions helps avoid missteps, but also makes it easier for more folks to contribute

• If you see someone in the meeting who isn’t participating, pull them into the discussion. It works best to pull exactly one person at a time into the discussion. It gets confusing when you open it up broadly to everyone or even just try to pull two or three people at once

• Be the one to take notes. This helps destigmatize note‐taking as “low status” and also frees up an alternative would‐be notetaker to contribute more instead. It also gives you something to focus on other than speaking!

• If you realize someone’s missing from the discussion who should be there, be the person to pull them into the next occurrence of the meeting. Talk with the meeting coordinator to let them know why it’s valuable to include them

As you follow these more and more faithfully, your experience in meet‐ ings will shrink, and your impact on the organization will grow.

Decisions

For so much of your career, success is making the right decision, and it takes a while to realize that at a certain point making the decisions isn’t the work. Ritu Vincent described that transition well,

It was also on that project where my manager helped me under‐ stand that my first impulse as a tech lead didn’t scale. Initially, I was thinking, “I’ll break it into twenty pieces, assign out eigh‐ teen pieces, and keep the two hardest for myself,” and my man‐ ager pushed me to delegate the hard pieces to the team to stretch

and develop them.

On the other hand, it’s hard to transfer your judgment to someone else, particularly around complex decisions. Fortunately, it’s possible to take an incremental approach to shift increasingly complex and im‐ portant decisions to your wider team.

• Write it down. There’s a well‐worn model of genius encapsu‐ lated in the Feynman algorithm: “1) Write down a problem. 2) Think very hard. 3) Write down the solution.” This mystical view of genius is both unapproachable and discouraging. It’s also un‐ realistic, but it’s hard for folks to know it’s unrealistic if we don’t write down our thinking process for others to follow. By writing down the process of finding an answer, as well as the rationale for the answer, folks around us can begin to learn from our deci‐ sions rather than simply being directed by them

• Circulate early, and do it before you’ve crystallized on a decision. Most folks struggle to walk back from a formed opinion, and by gathering feedback early, it’s much easier to incorporate feed‐ back and involve folks in the decision‐making process so they can see the trajectory of your thinking in addition to the final output

• Separate style from substance, and stop giving style feedback on other folks’ decisions. If a piece of feedback won’t meaning‐ fully change a project’s success, then consider not giving it. If it’s useful but not critical, potentially make a private suggestion rather than pulling a meeting into your orbit

• Don’t try to show value. Some senior folks feel like they need to weigh in on everything to justify their seniority. Others require each decision to exactly mirror a similar decision they once made. Both of these center insecurity over impact and prevent others from growing as leaders

• Change your mind. One of the biggest signs of respect for your coworkers is listening to them and then changing your mind af‐ terward. If senior leaders don’t change their mind, then soon everyone will correlate bluster with success

Involving folks in decisions you make and sharing your decision‐ making approach is a valuable component of growing the team around you, but what about making the decisions theirs?

Sponsorship

By including folks in your discussions and decisions, you involve them in your work. This is a great way to grow, involve, and learn from those around you, but at some point, you have to take the next step.

Instead of involving them in your work, make the work theirs.

This final step is sponsoring others for the kind of work that got you to a Staff‐plus role. When critical work comes to you, your first ques‐ tion should become, “Who could be both successful with and grown by this work?” See if you can get them to lead the work, and then work with them to scaffold the project for their success. What would your approach be? What are some initial concerns they might want to think through? Who are the stakeholders they should discuss the problem with early?

When you identify new critical work, perhaps identifying a gap in your tooling or process, think about who else could be generating that work and then sit down with them to have them put together the proposal you planned to write. Then build support for their proposal just as you would have for your own.

Importantly, when the work becomes theirs, you have to let it be theirs. Council, give advice, provide context, but ultimately sponsorship in‐ cludes letting them take an approach that you wouldn’t. It might end up going poorly, and they’ll learn from that – just like you’ve learned from your mistakes over your career. It might end up going very well, and then you’ll learn something instead.

While sponsorship should become your default approach to problems, it shouldn’t be your only tool. Most Staff‐plus engineers find it’s impor‐ tant to remain directly involved in some projects to retain their con‐ text of how their software, tooling, and organization work in practice. If you need a rule of thumb, keep a sponsorship journal and ensure you’re sponsoring others at least a few times a month – if you find your‐ self sponsoring less frequently than that, dig into what’s stopping you. Conversely, if you look back and can’t think of anything you’ve worked on directly in the past few months, that’s worth course‐correcting too.

What if you don’t?

If you’ve cemented the final cobblestones to a Staff‐plus role by becom‐ ing the “go‐to person” for a key company leader, then you’ve learned that solving an urgent problem for an organizational leader is one of the surest paths to recognition. If you’ve become the technical vision‐ ary whose ideas saturate the company’s architecture roadmap, then you’ve learned how powerful it feels to operate the gate to your com‐ pany’s technical future.

It’s hard to give those up.

However, the best case for this model is a company that thrives tem‐ porarily until that individual leaves. The far more common worst case is a company constrained by your personal limitations, and the only company that can tolerate being constrained by you is a company that doesn’t grow.

The only way to remain a long‐term leader of a genuinely successful company is to continually create space for others to take the recogni‐ tion, reward, and work that got you to where you’re currently sitting. It can be surprisingly uncomfortable, but don’t worry: there will always be new work for you anyway.

Build a network of peers

As I talk to more and more Staff‐plus engineers about career advice, the most consistent recommendation was to develop a personal net‐ work of peers doing similar work. Not every person emphasized this approach, but more than half mentioned it, and for those who did, it tended to be their first and strongest recommendation.

Ritu Vincent said,

What’s been most impactful for me is having a lot of people who I think of as mentors, usually friends, former managers, and folks that I’ve worked with. I have a decent number of recurring monthly lunches, coffee chats, and dinners with people who’ve worked with me in the past, know me, and I trust. It’s those con‐ versations about career challenges and growth that have gotten me to where I am in my career.

Keavy McMinn mentioned her network as an important way to get hon‐ est feedback,

The thing that springs to mind is to find your peers or support network. Just like management, it gets lonely the higher up you go, and it’s important to find peers that will still challenge you, and you can brainstorm ideas with. It doesn’t even matter if they’re in your similar area of work or even are in different com‐ panies.

Nelson Elhage similarly shared,

It’s also been really valuable for me to cultivate a good personal network of other senior engineers. I chat with them informally about whatever it is that we’re working on and thinking about. When you have personal connections, you can get very unvar‐ nished views of the problems people are seeing and the solutions they’re considering.

While it’s helpful to know you should build a network, some folks strug‐ gle to figure out how to do it. Among the various tactics to build your network, the two most common strategies are: being easy to find and networking internally.

Be visible

There is so much pent‐up demand for community among Staff‐plus en‐ gineers that the easiest way to build your network is being easy to find as a Staff‐plus engineer. One effective approach is contributing to the discussion around Staff‐plus engineering itself, like Joy Ebert’z What a Senior Staff Software Engineer Actually Does or Keavy McMinn’s Thriv‐ ing on the Technical Leadership Path. Although there are a good num‐ ber of folks who’ve written up their view on the Staff‐plus role, each one brings a new, valuable perspective. There’s room for your words on the topic.

If writing isn’t your jam, there’s room for your voice, and speaking at tech conferences is another effective way to become visible in the broader community. Keavy McMinn described her motivation for con‐ ference speaking as,

Mostly, I enjoyed the people I met at conferences. Later the speaker networks led to job opportunities for me.

If those both feel high‐stakes, even starting a Twitter account or join‐ ing a couple of related Slacks (for example, #staff‐principal‐engineering in the Rands Leadership Slack) can be a good start.

Internal networks, too

Rather than focusing on public speaking and writing, Katie Sylor‐ Miller ’s networking advice was to build your internal network within your current company,

Networking, networking, networking, networking… You have to be really cognizant of who you’re talking to and make sure that you have connections across multiple teams and multiple groups to leverage those networks.

Although it’s easy to think of networking as something that only hap‐ pens externally, it’s often easier to do at the company you’re already in, happening semi‐organically and semi‐deliberately over the course of your work. This approach has the added advantage of directly improv‐ ing your day‐to‐day work as well. Longer‐term, those folks will eventu‐ ally leave and spread across the industry, bootstrapping your broader network. This works really well when you’re at a decently large or pres‐ tigious company and is a bit less effective as your current company gets smaller or less prestigious.

Ambient networks

Among the folks who didn’t mention developing a personal network, most mentioned creating an ambient network of learning based on keeping current with industry books and following industry leaders on social networks, particularly Twitter.

Diana Pojar’s comment was

I use Twitter extensively, but I’m mostly a consumer and follow many people in tech. I usually follow people that I saw talking at conferences, or I worked with, and I find their content relevant to me. Here’s a couple, in no specific order: Camille Fournier,Lara Hogan, Josh Wills, Vicki Boykis, David Gasca, Julia Grace, Holden Karau, John Allspaw, Charity Majors, Theo Schlossnagle, Jessica Joy Kerr, Sarah Catanzaro, Orange Book.

Damian Schenkelman mentioned,

I try to follow people on Twitter who I think are doing interest‐

ing things and from who I can learn. There are so many peo‐ ple doing interesting things and so much to learn! Some of the names that come to mind: [including Aphyr, Tanya Reilly, and David Fowler].

If the idea of building a network this way feels uncomfortable, then building an ambient network can be a good starting step in the right direction. That said, you’ll find the personal network more impactful, and finding an authentic way to build one is an important step towards reaching and remaining impactful in senior roles over the long arch of your career.

Quality over quantity

A coworker once told me the story of someone determined to make their name in Business Development, who would fly from SF to NYC with a list of people they wanted to meet. They’d look for tweets and Foursquare check‐ins for where those people might be that night, go there, buy a drink, and pretend to serendipitously meet them. On a good night, they’d try to meet six or more new connections this way.

It goes without saying that you shouldn’t do that – it’s a total violation of boundaries. Further, doing this doesn’t even make sense: when it comes to building a network of peers, the volume doesn’t matter. In‐ stead, focus on slowly building with folks you genuinely trust, respect, and are inspired by. That’s what’ll create a truly powerful network to help you solve the hardest problems and trickiest situations that come your way.

Finally, if you’ve reached this paragraph and really want to build a net‐ work but just aren’t sure how to get started, I’ll share what’s worked for me as an introvert who struggled to craft an authentic approach. Find someone you respect and send them a short 1‐2 paragraph email or DM with a specific question asking for advice. If they reply, thank them and send another question in six to twelve months. If they sub‐ sequently ask you for a favor or question, do what you can to help. If they don’t reply, don’t worry about it; just move on without comment. This works surprisingly well, and the worst thing that can happen is totally fine: they’ll just never reply.

Present to executives

Have you presented to company executives about a key engineering initiative, walking into the room excited and leaving defeated? Maybe you only made it to your second slide before unrelated questions de‐ railed the discussion. Maybe you worked through your entire presen‐ tation only to have folks say, “Great job,” and leave without any useful debate. Afterward, you’re not quite sure what happened, but you know it didn’t go well.

Early in your career, you probably won’t interact with company exec‐ utives frequently. Sure, if it’s a small enough company, you might, but it isn’t the norm. As you get further into your career, though, increas‐ ingly, your impact will be constrained by your ability to influence ex‐ ecutives effectively. While staying aligned with authority is a prereq‐ uisite to influencing executives, there are also some new communica‐ tion skills for you to develop.

Why this is hard

Everyone has worked with a terrible executive at some point in their career, but most executives aren’t awful. Almost all executives are out‐ standing at something; it’s just that often that something isn’t the topic you’re communicating about with them. When you combine that lack of familiarity with your domain with limited time for the topic at hand, communication is a challenge.

Those are garden‐variety communication challenges, though, and communicating with executives can be unexpectedly difficult for a less apparent reason: the executive has become accustomed to consuming reality preprocessed in a particular way.

Any given executive is almost always uncannily good at one way of consuming information. They feel most comfortable consuming data in that particular way, and the communication systems surrounding them are optimized to communicate with them in that one way. I think of this as preprocessing reality, and preprocessing information the wrong way for a given executive will frequently create miscommuni‐ cation that neither participant can quite explain.

For example, some executives have an extraordinary talent for pattern matching. Their first instinct in any presentation is to ask a series of detailed, seemingly random questions until they can pattern match against their previous experience. If you try to give a structured, aca‐ demic presentation to that executive, they will be bored, and you will waste most of your time presenting information they won’t consume. Other executives will disregard anything you say that you don’t con‐ nect to a specific piece of data or dataset. You’ll be presenting with confidence, knowing that your data is in the appendix, and they’ll be increasingly discrediting your proposal as unsupported.

In most other scenarios, miscommunication creates latency rather than errors. Still, when you’re communicating with executives, you’ll often not get a second chance to discuss a given topic before the rele‐ vant decision is made. Invest ahead of the discussion to avoid lamen‐ tations afterward.

How to communicate effectively

The foundation of communicating effectively with executives is to get a clear understanding of why you’re communicating with them in the first place. You might be used to communicating with folks to change their mind or inform them about your project, but that’s probably not the case here. When you’re communicating with an executive, it’s al‐ most always one of three things: planning, reporting on status, or re‐ solving misalignment.

Although these are distinct activities, your goal is always to extract as much perspective from the executive as possible. If you go into the meeting to change their mind, you’ll probably come across as in‐ flexible. Go into the meeting to understand how you can align with their priorities. You’ll come across as strategic and probably leave with enough information to adapt your existing plan to work within the ex‐ ecutive’s newly articulated focuses or constraints.

The best way to extract their perspective is by writing a structured doc‐ ument. Writing forces you to think comprehensively about your be‐ liefs and data. The structure ensures you focus the reader on what’s important. Barbara Minto, whose The Pyramid Principle is the most influential work on effective business communication, is also a big fan of structure:

Controlling the sequence in which you present your ideas is the single most important act necessary to clear writing. The clear‐ est sequence is always to give the summarizing idea before you give the individual ideas being summarized. I cannot empha‐ size this point too much.

There are many structures that can work, but I’d particularly recom‐ mend every document’s opening paragraph follow the SCQA format:

• Situation: what is the relevant context? Example: We’ve been falling behind our competition in shipping product features for two years. Last year, we doubled our engineering team but shipped fewer features than the year before.

• Complication: why is the current situation problematic? Exam‐ ple: We plan to double our engineering team again this year, but based on last year’s experience, we think that will decrease ve‐ locity further while significantly increasing our organizational budget.

• Question: what is the core question to address? Example: Should we keep moving forward with our plan to double engineering this year?

• Answer: what is your best answer to the posed question? Exam‐ ple: We should stop hiring for the next six months and focus on gelling our existing team. Based on progress at that point, we should refresh our hiring plan for the remainder of the year.

In many discussions, a well‐structured opening paragraph is enough to spark an important conversation. Although in those cases, you might not discuss the rest of your document, the process of writing the document is still an important step in refining your thinking.

Relatively few folks employ a formal structure for the entirety of their document, but there is at least one popular format that some folks find valuable: Minto’s Pyramid Principle from the aforementioned book. Start by brainstorming your proposal into a series of arguments that support your answer. Once you’ve written them all down, group them into related arguments. Shape those groups into three top‐level ar‐ guments, with up to three sub‐arguments supporting each of those top‐level arguments. Recursively apply this approach, ensuring each argument summarizes its at‐most‐three sub‐arguments. Order the ar‐ guments within each group by descending importance. At that point, you’re done.

Although I personally found SCQA immediately useful, I’ll admit that when I first tried to follow the Pyramid Principle, it gave me the same emotional response as staring at Brutalist architecture. It’s grown on me with practice, but I’d still recommend most folks start by adopting SCQA as a core practice and only adopt the entirety of the Pyramid Principle if you get feedback that your presentations are hard to follow.

After you’ve written your structured document, gather feedback on it from your peers and stakeholders. Aligning with stakeholders before your presentation, sometimes called nemawashi, is extremely effec‐ tive at reducing surprises. Some of your peers should have experience presenting to the executives and will have useful feedback on improve‐ ments.

For the presentation itself, set a clear agenda, but don’t focus on rote conformance. A great meeting with executive leadership is defined by engaged discussion, not addressing every topic on the agenda. Some will consider this a controversial position, preferring to measure every meeting by its action items, but this ignores the often more valuable re‐ lationship establishment and development aspects of these meetings.

Mistakes to avoid

Even if you do a great job preparing for your execution presentation, these things sometimes go wrong. There’s nothing you can do that will avoid every bad path, but you can avoid most of the anti‐patterns that routinely sink these meetings.

Never fight feedback. It’s very common for an executive to have a criti‐ cal piece of feedback but to not quite have the right framing to commu‐ nicate it within the moment. You want them to deliver the feedback anyway, not hold it back and probably forget to give it later. If you show up as resistant to feedback, then they’ll start swallowing their comments, and you’ll get relatively little out of the meeting. Focus on gathering feedback; don’t worry about whether you agree with it until you have more time afterward. If there’s a decision that needs to be made that you disagree with, then you should inject one or two pieces of relevant data that might change their mind, but afterward, let it go. You’ll be more effective by reflecting on the feedback and changing their mind later than continuing to push back within the meeting.

Don’t evade responsibility or problems. Many folks try to hide issues from their leadership, and this always goes poorly. Successful folks look at informing executives as absolution: once it’s on the table, you can move towards solving it rather than hiding it. This is particularly true if an executive sniffs out a problem during a meeting. Lean into the feedback, don’t evade it. You will create more credibility by agree‐ ing with their perspective and following up with more data later. You will harm your credibility by arguing with them about it.

Don’t present a question without an answer. A frequent piece of advice given to new leaders is to “never bring your manager a problem without a solution.” That’s not generally great advice, but if you present a problem to an executive without a proposed answer, then in the back of their mind, they’re wondering if they need to hire a more senior leader to supplement or replace you. You can’t create alignment in the room unless you have a proposal for folks to align behind.

Avoid academic‐style presentations. The way you’re taught to present about topics in school is more‐or‐less the entirely wrong approach for presenting to executives. The Minto Pyramid Principle will steer you in the right direction if you follow its scripture.

Don’t fixate on your preferred outcome. It’s very common for folks to get so caught up on the outcome that they want that they spend their energy resisting the clear, unavoidable signs that it isn’t going to hap‐ pen that way. It’s very easy to get frustrated about the “wrong” decision getting made, but it’s helpful to keep in mind that there is a great deal of context that you’re missing. There is no such thing as a permanent decision: almost every decision will be reconsidered multiple times over the next two years.

Presenting to executives can be intimidating, and this might be more advice than helpful. If you want to boil it all down to one concise tip: send an early draft to an executive attending the meeting and ask them what to change. If you listen to and apply that feedback, you’ll figure out the other pieces as you go.