I remember reading about novelist Haruki Murakami writing his first novel in English first, then translating it back to Japanese as a way of shaping the style of his expression. He notes, "I could only write in simple, short [English] sentences. Which meant that, however complex and numerous the thoughts running around my head, I couldn't even attempt to set them down as they came. The language had to be simple, my ideas expressed in an easy-to-understand way."

At the micro-level, I keep a document called "what is stephen doing?" that drives my work on the hour-by-hour granularity. There's one main section for the current week and some reminders for future weeks. Every Monday, I start over unstarted items from the previous week get deleted and few survive to the next week.

That delete-by-default intention ends up helping me keep focused and not feel too strewn out. For a long time, I tried to groom a back-burner list of things to do but it mostly had the effect of stressing me out. Most back-burner items would end up deleted and incomplete anyways, a month later.

A quote I love from Seneca is "Luck is what happens when preparation meets opportunity."

[...] first to write the promotion case well before I was sure I was ready for the promotion. This allows you to see where there might be gaps and can give you very tangible things to work on.

Having better alignment with leadership makes a lot of things much easier.

Another thing that's helped is having mentors. Specifically I like mentors who are constructively antagonistic. What I mean by that is that they throw me into things that utterly terrify me but they're certain I'm ready for. They've helped push me way beyond what I thought was possible for me.

I always try to model the lessons I learned about customer service from that experience in every interaction I have with folks at work: be available, be humble, and focus on really hearing and understanding people's needs.

I think a lot of what gets someone to Staff is noticing problems and acting on solving them proactively, instead of letting them go.

Trusting other people and giving them the freedom to make technical decisions (even ones that you disagree with!), understanding other people's motivations, learning to give difficult feedback, knowing when to pick your battles — these are all useful skills to have.

Staff-plus is all about enabling other people to do better work to be a force multiplier.

I help get other people to care about the same things, like I'm going to start pairing with more engineers on API reviews. While I do the reviews, I try to help teach others what I'm looking at, and be encouraging through the processes and conversations.

He told me to write my performance review in the third person. The idea being that you're more likely to praise others, and be less critical, when giving them a review.

It's always a rewarding feeling if I can end the work day and feel like I've helped my peers get unblocked and maintain momentum.

I spent a good amount of time building passive internal customer and business context. I'd occasionally read merged pull requests for repos that I didn't maintain; I'd read tech specs and proposals that are shared publicly; I'd occasionally attend various internal presentations from the data science and analyst teams where they presented projects they completed or ideas they're exploring.

That means being intentional about creating opportunities for your team's individual contributors to grow their skills, get visibility, and access to others across the company.

I spend most of my time on hard, specific questions that don't have an easy, generic answer. Figuring out the right approach requires a lot of situational context that someone outside the situation won't have much insight into.

The most useful general learning for me was becoming comfortable with uncertainty. Sustained success in senior roles depends on your ability to adapt and grow as the needs of the organization change.

Another aspect of building leverage as a product engineer is creating processes and systems to manage "product debt." Folks often talk about "technical debt," but equally important is the "product debt" caused by supporting old versions of your product, and much of the difficulty of product engineering at scale is related to managing product debt and product drift (that is, products that need to operate with each other moving in different directions) over time.

Thinking back, a potentially-surprising important factor for me was (and is) my imposter syndrome. It made me extraordinarily open to feedback; to learning and growing and to taking responsibility for anything remotely related to my work. It made me proactively seek out feedback on everything from the validity of my comments on PRs to how I ran a particular meeting. If something was broken (whether it was technical or organizational), I felt unsettled and was deeply, intrinsically motivated to go learn about it and to fix it. No part of Stripe's product was "not my problem." This developed into two superpowers that are perhaps even more important to have as a Staff-plus Engineer than technical superpowers are:

1. Truly listening to and empathizing with others.
2. A deep care for solving all types of problems.

If two people asked the same question, we immediately added it to a FAQ that we kept. We took everyone's feedback and questions very seriously and put the burden of proof on ourselves. Finally, we worked to be fully transparent in our work, even creating a decision log that anyone at the company could use to follow our progress. Each entry in the decision log concisely describes a product or technical decision, documents who was involved in the decision, and links to detailed supporting technical design documents that generally contain the full problem statement and evaluation of alternatives.

I expect any sufficiently-ambitious design project to continue even when I am no longer on the team. An important part of making this work was writing everything down.

The right narrative gets the negotiation done and does it without generating a negative signal about your motivations.

The three most important things to understand before you start interviewing are:

1. What are the interview formats, including what are they evaluating for?
2. Do any of the interviews require specific preparation?
3. Who are the interviewers?

Folks who don't practice take that stance because they've decided that a company who cares about fast programming is likely to misuse its Staff-plus engineer.

Folks who've seen your presentations, read your blog posts, or nodded in agreement at your tweets are more likely to become your proactive sponsor in the interview process and later during promotion discussions.

The easiest sponsors to find are folks who you've worked with before. The flying wedge pattern of one senior leader joining a company and then bringing on their previous coworkers is a wellknown and justifiably-despised pattern that relies on this built-in referrer-as-sponsor, but it doesn't have to be toxic if done sparingly.

Some ways to explore during your interview process to help distinguish these mindsets:

- Companies with rigid compensation bands and who actually stick to them tend to be run by Proceduralists. Those that willingly eschew their bands are Meritocrats.
- Companies that create one-off roles for individuals to get them on board tend to be run by Meritocrats. Those that hire to their planned roles are Proceduralists.
- Companies with ad-hoc or unstructured interview processes looking to get your "feel," particularly for senior roles, tend to be run by Meritocrats. More structure means Proceduralists.
- Companies that perform ad-hoc conjurations of new, rubric-less interviews tend to be run by Meritocrats. Those that evaluate you rigidly, even if they don't let you shine, tend to be Proceduralists.

I don't know anyone who regrets taking a sabbatical. However, bear in mind that it's only the folks who took six-month-plus sabbaticals who felt reborn by the experience. Folks taking shorter stints have appreciated them but often come back only partially restored.

The interview are process also brings an automatic sponsor with it-the hiring manager-whose incentives will never be more aligned with yours than in the interview process.

You can always have more visibility within your organization, but at some point, increasing your visibility is likely reducing the opportunities for others to create visibility for themselves.

Compared to an exclusively internal focus, one advantage of building an external presence is that there's a lot more room to create a niche and name for yourself. Internal efforts often end up competing for attention with your peers in a way that external efforts simply don't.

- Write and distribute more long-lived documents, like architecture docs or technical specification.
- Lead (and, to a lesser extent, participate in) company forums like architecture reviews, company all hands, and learning circles.
- Be a cheerleader for your team's and peers' work on Slack.
- You can also cheerlead via email instead of Slack.
- Share weekly notes of your work to your team and stakeholders in a way that other folks can get access to your notes if they're interested.
- Contribute to your company's blog.
- Attend, or potentially even host, office hours for your team or org.

One of the most effective ways to get luckier is to be more visible within your organization.

It's important to remember that while there are infinite rooms to be in, there's no room where the work actually happens. You'll be most impactful if you're selective on which rooms you stay in.

Effective groups are formed from individuals who are willing to disagree and commit.

Volunteer for low-status tasks. If someone needs to take notes, raise your hand. If someone needs to follow up on action items, be available. Prioritize being useful, especially when it isn't the most exciting work.

Keep in mind that it's your obligation to be understood, not the obligation of everyone else to understand you.

[...] it's important to remember there's no single "room" to enter. Getting into the right room isn't a one-time challenge to be faced. Entering rooms will be an ongoing, iterative career challenge. That means it's worth getting good at!

If you keep getting answers like, "Work on larger, high impact technical projects," then you're asking in the wrong way, the wrong questions, or the wrong person.

Whether your company does ad-hoc promotions or uses a calibration process, promotions are a team activity and as Julia Grace, then of Slack, advised me once during job search, "Don't play team games alone, you'll lose."

For traversing towards your Staff-plus promotion, a general template format that's useful is:

- What are your Staff projects? What did you do? What was the project's impact (including a well-defined goal)? What made this project complex? Keep it very short and then link out to supporting design documents.
- What are the high-leverage ways you've improved the organization?
- What is the quantifiable impact of your projects? (Did you increase revenue by $10 million? Did you reduce year-on-year customer support tickets by 20%?)
- Who have you mentored and through what accomplishments?
- What glue work do you do for the organization? What's the impact of that glue work?
- Which teams and leaders are familiar with and advocates for your work? What do they value about your work? One sentence, include data (e.g. survey data) when possible.
- Do you have a real or perceived skill or behavior gaps that might hold you back? For each, how would you address the concern? One sentence each.

If you're motivated to help your team grow and succeed, then go ahead and do it; if you're only doing it for yourself, then don't.

I still enjoy both shipping code and running teams, and I think the ability to do both at a high level is critical for long-term engineering success. Charity Majors has a fantastic blog post on this topic that I recommend reading: "The Engineer/Manager Pendulum". Charity argues that "manager career path vs engineering career path" is a false dichotomy, and taking time to alternate between both roles makes you better at both. This maps to my own experience. I'm a better manager because I know how terrible it is to be an IC on a poorly planned project, and I'm a better IC because I know how and when to sound an alarm when a project is going poorly.

One inconvenient reality you'll encounter in pursuit of a Staff role is that opportunity at any given company is unevenly distributed.

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.

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.

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 arguments, 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 arguments within each group by descending importance. At that point, you're done.

If you go into the meeting to change their mind, you'll probably come across as inflexible. Go into the meeting to understand how you can align with their priorities.

[...] if you've reached this paragraph and really want to build a network but just aren't sure how to get started, I'll share what's worked 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 subsequently 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.

The only way to remain a long-term leader of a genuinely successful company is to continually create space for others to take the recognition, 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.

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.

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 feedback and involve folks in the decision-making process so they can see the trajectory of your thinking in addition to the final output.

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 decisions rather than simply being directed by them.

[...] there are a few techniques that I've found helpful in creating more space in discussions:

- Shift your contribution towards asking questions.
- If you see someone in the meeting who isn't participating, pull them into the discussion.
- Be the one to take notes.
- 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.

As you follow these more and more faithfully, your speaking in meetings will shrink, and your impact on the organization will grow.

A good discussion 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.

One of the best measures of your long-term success as a Staff-plus engineer is that the organization around you increasingly benefits from, but doesn't rely upon, your contributions.

[...] more complex projects get derailed by personal conflict than by technical complexity, and this is a repeatable way to replace tension with partnership. It feels like it's slow because it can take longer to get started, but ultimately it's fast because you're more likely to complete the work without disruption.

If you ever find yourself in a conversation with an unclear goal, then define the purpose. Take a moment to ask if your understanding of what the group hopes to accomplish is correct.

In a potentially contentious meeting, ask three good questions before you share your perspective, and you'll see the room shift around you.

Good questions are asked with the desire to learn, and they are specific. They sharpen the conversation. They free the answerer fend their position.

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.

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.

To become a senior technical leader, you must build a deep perspective 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.

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

[...] contined 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.

Make your feedback explicitly non-blocking. This can be classifying a code review comment as an "optional nit," but it can also be writing up detailed feedback but delivering it to someone mentioning that you wanted to share your perspective rather than necessarily change their approach.

[...] 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.

If you only see the gap without acting 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, arbitrary, and inefficient. Combining both with some luck is likely to take you a long way in your career, and these are characteristics common in folks I've worked with who successfully navigate the transition into Staff-plus engineering or senior management roles.

The way I think about leadership has evolved a bit over the last few years, though, coming to focus on two specific attributes. First, leaders have a sufficiently refined view of how things ought to work such 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 narrowing actions.

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.

Having a clear sense of how things ought to work sharpens your judgment and enables you to act proactively.

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.

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.

To remain effective within a Staff-plus role, you have to learn the art of staying aligned with organizational authority.

Slowly build towards something that genuinely works, even if it means weathering accusations of not moving fast enough. When it comes to complex systems and interdependencies, moving quickly is just optics. It's methodical movement that gets the job done.

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.

[...] it's important to establish a thoughtful approach that balances the benefits of exploration against the benefits of standardization.

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 instance.
- 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?

The desire to measure in software engineering has generally outpaced our state of measurement.

Most misalignment comes from missing context, and these are the organizational leverage points to inject context into decision-making.

Take everything you've learned, and pull it into a technical specification 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.

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.

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

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.

Effective interfaces decouple clients from the encapsulated implementation. Durable interfaces expose all the underlying essential complexity and none of the underlying accidental complexity. Delightful interfaces are Eagerly discerning, discerningly eager.

[...] 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.

[...] the worst sin of performance engineering is applying effort to unproven problems.

There are many other practices I'd love to advocate for (who hasn't spent a career era advocating for better internal documentation), but I don't trust my intuition like I once did.

Genuine best practice 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 version control, trunk-based development, CI/CD, and production observability (including developers on-call for the systems they write), and working in small, atomic changes.

A rushed process is a failed process.

When you're rolling out a new practice, remember that a good process is evolved rather than mandated.

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 organizational and leadership maturity that takes some time to develop.

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.

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.

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.

As we dig into this toolkit of approaches, remember to pick the cheapest, 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.

At a well-run and successful company, most of your previous technical decisions won't meet your current quality threshold. Rather than a failure, closing the gap between your technical quality is a routine, essential part of effective engineering leadership.

Don't measure vision by the initial excitement it creates. Instead, measure 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.

Force yourself to write something compact, and reference extra context by linking to other documents for the want the full details.

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 illustrative rather than declarative, giving a taste of the future's flavor rather than offering a binding commitment.

Visions should be ambitious, 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 major setbacks. Don't write what you think would be possible with infinite resources.

Showing your work builds confidence in the first version of a document, but even more importantly, by showing your work, you make it possible for others to modify and extend your work as the underlying context shifts.

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.

Specific statements create alignment; generic statements create the illusion of alignment.

Write until you start to generalize, and then stop writing.

you've just got to dive in and start writing. Waiting for missing information doesn't work: every missing document is missing for a good reason.

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.

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?

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.

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.

Before getting far into the process, collect input from folks with relevant perspectives, particularly those who will rely on the output of your design document.

[...] design documents have what bad strategies lack: detailed specifics grounded in reality.

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 numerous future projects. You should also write design documents for projects that meaningfully impact your users. You should write a document for any work taking more than a month of engineering time.

A good design document describes a specific problem, surveys possible solutions, and explains the selected approach's details.

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 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.

To write an engineering vision, write five engineering strategies, and forecast their implications two years into the future. That's your engineering vision.

To write an engineering strategy, write five design documents, and pull the similarities out. That's your engineering strategy.

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

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.

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.

What are priorities 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?

Taking the time to understand the status quo before shifting it will always repay diligence with results.

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.

For mentorship 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.

In the long-term, companies either learn to explore, or they fade away; this isn't an ignorable challenge. Simply assigning a team that's mastered hill-climbing to do exploratory work is far from a sure thing, so many companies take a different approach. They find a couple of trusted individuals with broad skills, allocate some resources, and check back in a few months later to see what they've discovered. One of those engineers is often a Staff engineer.