Why do we need engineers who can see the big picture?

Any engineering organization is constantly making decisions. We might be choosing a programming language for a new system, prioritising the needs of one internal customer over another, weighing up the risks of deprecating a component, or choosing which shared platforms to invest in. Some of these decisions have clear owners, and the consequences are easy to predict. Others are the kinds of foundational architectural choices that will affect every other system, and no one person or even one team can claim to know exactly how the changes will play out.

Good decisions need context. For all we might enjoy taking sides in arguments on the internet, experienced engineers know that the answer to most technology choices is, “it depends”. What are you trying to do? How much time, money, and patience do you have? Are there prior art, risk tolerance and scaling considerations? What other problems could you or your team be solving if you didn’t have to spend time on this one? What decisions are other teams making that could change your available options? No matter how thoroughly the pros and cons of a technology or path are documented, you need to know the local details of any situation before deciding whether the “obviously best” choice is actually the right one. That’s the context of the decision.

Gathering context takes time and effort. Individual teams, focused on solving their own problems, will tend to optimise for their own interests, and an engineer on a single team is likely to be laser-focused on achieving that team’s goals. But often decisions need to cross multiple teams, or even multiple organizations. Even decisions that seem to belong to one team can have consequences that extend far beyond their own team boundaries. This is particularly the case when you’re changing or replacing a system component that has tendrils in every other component, or embarking on the kind of architectural restructuring that will let you keep growing your company for another next five years. The local maximum, the best decision for a single group, might not be anything like the best decision when we take a broader view.

Suppose a team is choosing between two pieces of software, A and B. Both have the necessary features, but A is significantly easier to set up: it just works. B is a little harder: it will take a couple of sprints of wrangling to get it working, and nobody’s enthusiastic about waiting that long.

From the team’s point of view, A is a clear winner. Why would they choose anything else? But if they take a broader view they’ll see that other teams would much prefer that they choose B: it turns out that A will make ongoing work for the legal and security teams, and it has some authentication needs that mean the IT and platform team will have to treat it as a special case forever. By choosing A, the team is unknowingly choosing a solution that’s a much bigger time investment for the company overall. B is only slightly worse for the team, but much better overall. Those extra two sprints will pay for themselves within a quarter, but this is only obvious when the team has someone who can look with a wider lens.

Figure 1-1. : local maximum vs better decision.

To avoid local maxima, we need decision-makers (or at least decision-influencers) who can take an outsider view, who can consider the goals of multiple teams at once and choose a path that’s best for the whole organization or the whole business, rather than just one team. Chapter 2 will focus on this ability to zoom out. We’ll look at building the big picture of your organization, and about knowing things, one of the more esoteric skills that a good Staff engineer brings to their job.

Just as important as seeing the big picture of the situation now is being able to think long term and anticipate how your decisions will play out in future. A year from now, what will we regret? Three years from now, what will we wish we’d started doing now? If we want groups going in the same direction, we’ll need some sort of technical strategies, with decisions about which technologies to invest in, which platforms to standardise on, how to balance team autonomy against duplicated solutions, and so on. All of these decisions need business context so that we can understand what problems need to be solved and what opportunities can be opened up, and set the technical direction that will lay the foundations for future decisions.

Big decisions can end up being subtle, and they’re often controversial, so just as important as making the decision is being able to explain it. We need to be able to share context and tell the story of the decision in a way that makes sense to other people. Chapter 3 will be all about making big decisions and writing technical strategy.

So, if we want to make broad, forward-looking decisions, we need a set of people who can see the big picture. But why can’t that be managers? Most engineering organizations already have managers to support and guide teams, and a large proportion of engineering managers used to be engineers. Why can’t they make all of the decisions? And why can’t the CTO just know all of the “business things”, translate them into technical outcomes, and just pass on what matters?

On some teams, they can. On a small team, a manager can often function as the most experienced technologist, and can own major decisions and technical direction. In a small company, a CTO can stay deeply involved in the gory details of every decision. These companies probably don’t need Staff engineers. But managing other humans is itself a full time job, and as the team grows, managers will have less available time to dig into deeply complex decisions, much less to spend days in meetings whiteboarding out the nuances of various strategic directions. Someone who’s investing in being a good people manager will have less time left over to stay up to date with technical developments, and anyone who is managing to stay deeply “in the weeds” will be less able to meet the needs of their reports. Sometimes that’s fine: some teams don’t need a lot of attention to continue on a successful path. But as the number of reports grows, or when there’s tension between the needs of the team and the needs of the technical strategy, a manager has to choose where to focus. Either the team’s members or its technical direction get neglected.

That’s one reason that many organisations add specialization in their roles and separate out technical leadership and people leadership paths. Some teams formalize this further by assigning teams a “technical lead” (TL), as well as an Engineering Manager (EM). As Joe Beda, founder of Heptio and Principal Engineer at VMware, wrote on Twitter: “The TL owns the technical outcome and design. Sets and helps maintain the technical culture on the team. Supports and grows the tech skills of the team. Manager helps drive career growth and coaches team. Split of duties can be somewhat fluid if the TL/EM form good partnership.”

As a company grows, we’ll find that different decisions are best made at different levels in the organizational hierarchy. If you have more than a few engineers, it’s inefficient – not to mention disempowering – if every decision needs to end up on the desk of the CTO or a senior manager. We’ll have better outcomes and designs if experienced engineers have the time to go deep and build the context and the authority to set the right technical direction.

That doesn’t mean engineers set technical direction alone. Managers, as the people responsible for assigning headcount to technical initiatives, need to be part of major technical decisions. We’ll talk about maintaining alignment between engineers and managers later this chapter, and again when we’re talking strategy in Chapter 3.

Why do we need engineers who lead projects that cross multiple teams?

When a project falls neatly inside the purview of a single team, communication and ownership is straightforward: everyone talks to everyone else, and the team’s sprint planning or other work allocation mechanism keeps everyone on a steady course towards the goals. Unfortunately, no matter how carefully your organisation has laid out your team topology, most software projects are likely to cross multiple teams or to have dependencies on other teams’ work. And that’s when it gets difficult.

In an ideal world, the teams in an organization should interlock like jigsaw pieces, covering all aspects of any project that’s underway. In this same ideal world, though, everyone’s working on a beautiful new green-field project, with no prior constraints or legacy systems to work around, and each team is wholly dedicated to that project, or has it as a top priority. Team boundaries are clear and uncontentious: the joins between the jigsaw pieces line up exactly where the project already needed an API or a clear contract. In an even more perfect world, we’re starting out with what the Thoughtworks tech consultants have dubbed an Inverse Conway, a set of teams that correspond exactly with the components of the architecture we’d love to end up with. The difficult parts of this utopian project are difficult only because they’ll involve deep and fascinating research and invention, and their owners are eager for the technical challenge and professional glory of solving them.

I want to work on that project, don’t you? Unfortunately, the reality is somewhat different. It’s almost certain that the teams involved in any cross-team project already existed before the project was conceived and are working on other things, maybe things that they consider more important. They’ll discover unexpected dependencies on other teams mid-way through the project. The boundaries between the various groups are messy: there are overlaps and gaps. Two teams’ responsibilities line up right in the middle of a component of the desired architecture, and the project leads are inclined to create two components instead to make it easier to work side by side, even though that makes no sense when looking at the architecture from a high level. And the murky and difficult parts of the project are not fascinating algorithmic research problems: they’re difficult because they’ll involve spelunking through legacy code, divining the intentions of engineers⁴ who left years ago, and negotiating with busy teams who rely on the behavior of existing bugs and don’t want to change anything.

A project like this can be so murky that even understanding what needs to change is a complex problem in itself, and not all of the work can be known at the start. If you look closely at the design documentation, you might find that it’s postponing or hand-waving the decisions that need most alignment–but these are the choices that will be core to every other aspect of the project.

That’s a more realistic project description. No matter how carefully we overlay teams onto a huge project, we’ll find that some responsibilities end up not being owned by anyone, and others end up being claimed by two teams. Information fails to flow, or gets mangled in translation and causes conflict. Teams make excellent local maximum decisions, as we discussed in the previous section, decisions that end up being a problem when looked at with a wider lens. And software projects get stuck.

One way to keep the project moving is to have someone who feels ownership for the whole thing rather than any of its individual parts. Even before the project kicks off, that person can scope out the work and build a proposal for what needs to happen and who needs to be involved. Once the project’s underway, they’re likely to be the author or co-author of the high-level system design, and a main point of contact for it. They’re maintaining a high engineering standard, using their experience to anticipate risks and ask hard questions, informally mentoring or coaching – or just setting a good example – for the leads of individual parts of the project. As part two of this book will discuss, they bridge the gaps between the teams, making sure the big decisions get made, resolving conflicts before they fully arise, and noticing when there are aspects of the system that don’t make sense, or that haven’t been accounted for. Outside the project, they’re telling the story of what’s happening and why, selling the vision to the rest of the company, explaining what the work will make possible, perhaps delivering tech talks to educate other engineers and let them understand how the new project affects them.

Why can’t Technical Program Managers (TPMs) do this consensus-building and communication? There is definitely some overlap in responsibilities. TPMs are often allocated to projects to ensure effective delivery⁵ and to be, as Michael Lopp says, “chaos-destroying machines.” Ultimately though, TPMs are responsible for delivery, not design, and not engineering standards. When a project has a TPM, they’ll usually share the load in scoping and communicating about the work and removing blockers. They’ll notice the gaps between projects and make sure everyone’s sharing information with each other. They make sure the project gets done.

But the most senior engineers on the project make sure it’s done with high engineering standards. They’re responsible for ensuring the resulting systems are robust and operable, and fit well with the technology landscape of the company. They are wary of technical debt, or anything that will be a trap for future maintainers of those systems. It would be unusual for TPMs to write technical designs or set project standards for testing or code review, and we wouldn’t expect them to do a deep dive through the guts of a legacy system to make a call on which teams will need to integrate with it.

That’s why we get so much value from having a very senior engineer attached to a cross-team project. A Staff Engineer as a lead sets a high standard. They can see the big picture clearly enough to make big decisions, bring their experience to the design, and act as a mentor to other engineers across all of the teams, particularly the leads of each team. When a Staff Engineer and TPM work well together on a big project, their partnership can be a dream team.

Why do we need engineers who are a good influence?

Software matters. The software we build is increasingly important. The behaviour of software systems can affect people’s wellbeing and their income. We’ve learned from plane crashes, ambulance system failures, and malfunctioning medical equipment that software bugs and software outages can kill people⁶. As we increase the use of software in systems that are critical to saving lives, sustaining livelihoods, and maintaining democracy, it would be naive to assume there won’t be more and bigger software-related tragedies coming in our future. There’s a perennial argument online about whether software engineering is really an engineering discipline⁷. There are reasonable arguments on both sides, but I think this much is true: there are many cases where we need to bring engineering rigor to our work. We need to take software seriously.

Even when the stakes of our projects are lower, we’re still making software for a reason. With a few R&D-ish exceptions, engineering organisations usually don’t exist just for the sake of building more technology. We’re setting out to solve an actual business problem, or to create something that people will want to use. We’d like to achieve that with some acceptable level of quality, efficient use of resources, and a minimum of chaos.

Unfortunately, quality, efficiency and order are far from guaranteed, particularly when there are deadlines involved. When doing it ‘right’ means going slower, teams that are eager to ship may skip testing, cut corners, or rubber-stamp code reviews instead of digging into how well the code works. Without someone who’s worked on huge projects before and has seen what succeeds and what fails, teams are likely to start coding without a plan or without talking to each other. Without a model for resolving technical disagreements, conflicts can result in people entrenching and projects getting deadlocked.

In companies that only emphasize delivering features, that’s going to set the tone for the software: the software may look good, but it’ll be built on a shaky foundation. We need a counter-balance: senior people who will always be pragmatic about doing what’s right for the business, but who take responsibility for producing a high quality product or architecture.

Writing good software isn’t easy. We get better at it the more we do it. We learn a ton every time we successfully complete a project, and we learn even more from our own mistakes, but each of us only has a finite number of our own experiences to reflect on. That means that we need to learn from each other’s mistakes and successes too. Team members who are quite junior might never have seen good software being made, or might see producing code as the only important skill in software engineering. We need more experienced engineers to lead the way.

Staff engineers can set both implicit and explicit standards for their organisations. These standards go beyond technical influence: they’re cultural too. The implicit standards come from acting as a role model. Software teams and organizations are a community, and the actions of the most senior members of the community set the convention for how people treat each other. When senior people vocally celebrate each others’ work, treat each other with respect, and ask clarifying questions, that makes it easier for everyone else to do that too. When you respect someone as the kind of engineer you want to “grow up” to be, that’s a powerful motivator to act like they do. Chapter 7 is all about being a (maybe reluctant) role model, and being aware of the influence you’re having throughout your organization. Chapter 8 will look at more deliberate influence, such as creating guidelines and best practices, leaving thoughtful comments on code and documents, and having a high bar for what gets deployed.

Why can’t managers be a good influence and create these standards? They can! Managers are definitely responsible for setting culture on their teams and are often called upon to act as an agent of the company in enforcing behavior and ensuring standards are met. Managers can insist that the team has higher test coverage, or better incident response discipline; if the manager doesn’t value cooperation or velocity, the team might not be incentivized to value them either. But, engineering norms are set by the behavior of the most respected engineers on the project. No matter what the standards say, if the senior engineers don’t write tests then you’ll never convince the juniors to do it.

Standards and best practices will sometimes be created by managers but, just as with big picture thinking and project delivery, Staff engineers often have more dedicated time and more relevant experience. Code review guidelines, architectural best practices, or the kinds of tooling that make everyone faster are all time-consuming projects. They’re more likely to come from practitioners who have more time for technical specialization.

Why do these need to be Staff engineers?

All of this kind of work can be done, and often is, by Senior-level engineers, or often even by enterprising mid-level engineers. But all of it takes time. While you’re writing strategy, reviewing project designs, or setting standards, you’re not coding, or architecting new systems, or doing a lot of the work a software engineer might be evaluated on. This kind of technical leadership needs to be part of the job description of the person doing it, to encourage them to take the time to do it well, rather than rushing it so they can get back to the work that’s more clearly valued by the organisation. It needs to be clear that this isn’t a distraction from the job: this is the job.

But it’s not just about time. As we’ve seen, this work needs technical depth and technical judgement too. Our strategies have to be sound, our solutions must actually solve the problems, and the technical culture we create needs to make code and designs better. Our decisions and directions need to be informed by deep technical knowledge and experience. When our most experienced engineers lend their knowledge to this kind of work, we’ll have better technical outcomes and a better engineering culture. In fact there’s a high opportunity cost if they don’t: if we have our most senior, most expensive engineers just write code all day, we’ll see the benefit of their skills in the codebase, but we’re missing out on the things that only they can do.

You’re not a manager, but you are a leader

First things first: staff engineering is a leadership role. If you look at your company’s career ladder, there’ll be some notion of managers and engineers at the same level. A staff engineer often has the same seniority as a line manager. A senior staff engineer might be equivalent to a senior manager. A Principal engineer often has the seniority of a director. As a Staff+ engineer, you’re the counterpart of a manager at the same level, and expected to be as much of a “grownup in the room” as they are. You may even find that you’re more senior and more experienced than some of the managers in your organization, and may find yourself acting as a leader to them too. Whenever there’s a feeling of “someone should do something here”, there’s a reasonable chance that the someone is you.

Do you have to be a leader? I’ve occasionally had mid-level engineers ask me if they really need to get good at “all of that squishy human stuff” to go further. Aren’t technical skills enough? I do empathise with the question! If you’re the sort of person who got into software engineering because you wanted to do technical work and don’t love talking to other humans, it can feel unfair that your vocation runs into this wall. But, unfortunately, if you want to keep growing, being deep in the technology can only take you so far. Accomplishing larger things means working with larger groups of people and that needs a wider set of skills.

When we talk about the impact of an engineer, we’re referring to their ability to get things done and get them done well. As your compensation increases and your time becomes more and more expensive for the company, the work you do is expected to be more valuable. Your impact is expected to be greater. That means that technical judgement will need to include the reality of the business, and an understanding of whether the work is worth doing at all. As you increase in seniority, you’ll take on bigger projects, projects that can’t succeed without collaboration, communication and alignment: your brilliant solutions are just going to cause you frustration if you can’t convince the other people on the team that they’re the right path to take. And whether you want it or not, you’ll be a role model: more junior engineers in the company will look to those with the big job titles to understand how to behave. So usually, by the time an engineer reaches Senior level, they’ll need some ability in big picture thinking, project execution and good influence on others. By Staff level, you can’t avoid being a leader.

Staff engineering leadership manifests in a different way from management. A Staff engineer usually⁸ doesn’t have direct reports or formal authority over the people on their team or teams. While they’ll be involved and invested in growing the technical skills of the engineers around them, they’re not responsible for anyone else’s career growth, or managing anyone’s performance. They’re definitely not responsible for approving vacation or expenses. They can’t fire anyone, or promote them – though local team managers should value their opinions about other team members’ skills and output. Staff engineers have a huge impact on the technical culture and capabilities of the team or teams they work with, but they are responsible for technical outcomes, not people.

Leadership comes in lots of forms that you might not immediately recognise as being a leader. It can come from designing ‘happy path’ solutions that protect other engineers from common mistakes. It can come from reviewing other engineers’ code and designs in a way that improves their confidence and skills, or highlighting design proposals that don’t meet a genuine business need. All forms of teaching–whether that’s pair programming, writing a document, or creating clear reference implementations other people can learn from–are forms of leadership too. Finally, a reputation as a stellar technologist may inspire followership whether you mean to have it or not: if other people buy in to your plans for architecture or refactoring just because they trust you, then guess what: you’re a leader. I’ve seen excellent staff engineers who would never describe themselves as leaders but who raise everyone’s game as they quietly set the direction for their technical area.

You’re in a “technical” role

Staff engineering is a leadership role but it’s also a deeply specialized one. It needs technical background, and the kinds of skills and instincts that come from engineering experience. To be a good influence, you need to have high standards for what excellent engineering looks like, and model it when you build something. Your reviews of code or designs should be instructive for your colleagues and should make your codebase or architecture better. When you’re making technical decisions, you need to understand the tradeoffs of the various options, and communicate them using mental models that help other people understand them too. You need to be able to dive into the details where necessary, ask the right questions, and understand the answers. When arguing for a particular course of action, or a particular change in technical culture, you need to make sense and you need to be right. So, for all that this role needs leadership, communication and business awareness, you have to have a solid foundation of technical skills.

This doesn’t necessarily mean you’ll write a lot of code though. At this level, your goal is to solve problems efficiently, and coding will be only one of the tools in your toolbox–and maybe not the first one you reach for. When your project has multiple engineers but only one of you, programming will often not be the best use of your time. It may make more sense for you to take on the design or leadership work that only you can do and let others handle the programming. Staff engineers often take on ambiguous, messy, difficult problems and do just enough work on them to make them manageable by someone else. Once the problem is tractible, it becomes a growth opportunity for less experienced engineers (with support from the Staff engineer!).

For some Staff engineers, deep diving through codebases will still remain the most efficient tool to solve many problems. For others, writing documents might get better results, or becoming a master of data analysis, or having a terrifying number of 1:1 meetings. What matters is that the problems get solved, not how. This is why I’m not a fan of giving experienced Staff engineers coding interviews, by the way: if you’ve made it to this level, either you can code well, or you’ve learned to solve technical problems using your other muscles. The outcomes are what matters. We’ll talk more about interviewing in Chapter 9 too.

You aim to be autonomous

When you were a junior or midlevel engineer, your manager probably told you what to work on and how to approach it. At Senior level, maybe your manager advised you on which problems were important to solve, and left it to you to figure out what to do about it. At Staff+ levels, your manager should be bringing you information and sharing context, but you should be telling them what’s important just as much as the other way around. As Sabrina Leandro, Principal Engineer at Intercom said in her StaffPlus Live talk So You’re Staff+, Now What, “So you know you’re supposed to be working on things that are impactful and valuable. But where do you find this magic backlog of high impact work that you should be doing, that you should be working on? You create it!”. Part of your job now is to notice problems and opportunities, to evaluate what needs attention and to make sure you’re working on the right things. With senior roles comes this unfortunate truth: if you do an amazing job on something that wasn’t a good use of your time, you didn’t actually do an amazing job.

As a senior person in the organization, it’s likely that you’ll be pulled in multiple directions, and that there’ll be a lot of available work. It’s up to you to defend and structure your own time. There are a finite number of hours in the week. You get to choose how to spend them. If there’s so much work that you or your team can’t do everything, you’ll be the one responsible for making sure that the least important things are deliberately dropped. If your calendar’s been so fragmented by meetings that there’s no time to do proactive work, it’ll be up to you to cancel some times, move meetings around, or otherwise make time. You are not a small boat being buffeted around by winds outside your control: you need to steer your own ship.

That doesn’t mean you’re alone on the ocean though! You’re still working with other people, and maintaining good relationships, and that means you’ll take other people’s opinions into account when making your decisions. If someone asks you to work on something, you’ll bring your own expertise to the decision. You’ll weigh the priority, the time commitment, and the benefits–including the relationship you want to maintain with the person who asked you for help–and you’ll make your own call. Autonomy only goes so far: if your CEO or other local authority figure tells you they need something done, you’ll give that appropriate weight. But autonomy demands responsibility. If the thing they asked you to work on turns out to be harmful, that’s not just their bad judgement call, it’s yours.

As a leader in the company, you have a responsibility to speak up, even if it’s to the CEO, when you see a decision that’s a risk to the business. Calling out a risk doesn’t mean that the decision will change–the other person might weigh tradeoffs differently than you do, or they could just have more (or different) information–but don’t silently let a disaster unfold.

We’re back to “someone should do something”. If you’re the person who sees a problem that nobody else sees, you should point it out. Of course, if you want to be listened to, you’ll have worked at building up a reputation for being right, and having the gravitas to be trusted.

You set technical direction

As a technical leader, part of your role is to make sure the organisation is making technical decisions and has a good technical direction. What’s technical direction? Underlying the product or service your org provides is a host of technical decisions: your architecture, your internal APIs, the platforms or underlying infrastructure you use, the languages you’re writing in, the tools and frameworks you use, your approach to paying down technical debt, how you build and release code, how you decide which problems to solve, and so on.

Some of these questions need to be answered at a team level. Others need alignment across multiple teams, whole organizations or your entire engineering department. Part of your job is to make sure that these decisions get made, that they get made well, and that they get written down.

That doesn’t mean you’ll be making these decisions on your own, handing down pronouncements from your ivory tower. Having an effective direction is a manager’s responsibility too – you’ll note that by director level, it’s the literal job title. The managers around you will have opinions, and often strong ones, about where your technology should be going. Good ideas will also come from engineers who are more junior than you and from peers whose area of interest overlaps with yours. The job is not to come up with all (or even necessarily any!) of the aspects of the technical direction, but to ensure there is an agreed, well-understood path forward that solves the problems it sets out to solve. This might mean that you’re setting technical direction by enthusiastically throwing your weight behind someone else’s good ideas. I’ll talk more about writing vision and strategy in Chapter 3.

You communicate often and well

Everything we’ve talked about so far has a key skill in common. It all needs communication. The more senior you become, the more you will rely on strong communication skills. Whether you’re aligning with your director on a technical strategy, convincing the teams in your organisation to change to a new system, asking a question on a Slack channel, or pointing out the risks in an architectural design, almost everything you do will involve conveying information from your brain to one or more other people’s brains. The better you are at being understood, the easier your job will be.

Communication covers a multitude of skills, like:

• framing an idea by taking a bunch of facts and telling a story about them

• writing or speaking for an audience, building mental models of what they already understand, so you can meet them where they are

• explaining technical concepts to people who don’t work in tech without their eyes glazing over

• choosing an appropriate tone, formality, altitude and level of technical detail for an email

• being brief and balancing your audience’s attention span against including all of the information you want to give them

• writing with precision, removing points of confusion or ambiguity

• listening to something someone else tells you, asking whatever questions you need to ask to understand it, and reflecting it back to make sure you got it right

• getting your point across in a meeting without being ignored, being a jerk, or going on too long

• supporting someone else’s point in a meeting without taking over

• being persuasive when persuasion is needed

• being descriptive when description is needed

• knowing when you should stop talking

These skills are all learnable! I’ll have advice on communication in Chapter 3, Chapter 4 and, okay, most of the rest of this book. Communication underlies just about everything.

Where in the organization do you sit?

Our industry hasn’t standardised on any model for how Staff+ engineers report into the rest of the engineering organisation. Some companies have their most senior engineers report to a Chief Architect or Office of the CTO, others assign them to directors of various orgs, to managers at various levels of the organisation, or to a mix of all of the above. I’ve seen Principal engineers who report to “leaf node” line managers, sometimes far more junior than they are. I’ve also seen Staff engineers who report to the head of engineering. There’s no one right answer here, but there can be a lot of wrong answers, depending on what you’re trying to achieve.

Your work will be influenced by who you report to and where you’re located in the organizational chart. Reporting chains will affect the level of support you receive, the information you’re privy to and, in many cases, how you’re perceived by engineers outside your group.

Figure 1-2. Staff+ engineers reporting in at different levels of the org hierarchy. Even if these engineers are all at the same level of seniority, A will find it much easier to be in director-level conversations than D will.

What’s your scope?

This topic of aligning with your manager brings us on to understanding your scope: the domain, team or teams that you pay close attention to and have some responsibility for. It’s the domain where you’re expected to feel knowledgeable and cast influence every day. You may not hold any formal leadership role in this domain, but this is the group of people and the group of projects that should feel your influence strongly.

Inside that scope, you should have some influence on short term and long term goals. You should be aware of the major decisions being made. You should have opinions about the changes that will affect people in that scope, and should represent more junior people who don’t have the leverage to prevent poor technical decisions that affect them. You should be thinking about how to cultivate and develop the next generation of senior and staff engineers, and should notice and suggest projects and opportunities that would help them grow. As we’ll discuss in Chapter 9, identifying the people who can learn to take over your job is a key step in helping you achieve your own goals.

Your scope will usually be shaped by your reporting chain. In some cases, it will be equivalent to your manager’s scope: your manager might expect that you devote the majority of your skills and energy to solving problems that fall within their team’s domain. In other cases, a team may just be a home base as you spend some portion of your time on fires or opportunities elsewhere in the org. If reporting to a director, there may be an implicit assumption that you operate at a high level and tie together the work of everything that’s happening in the org, or you might be explicitly allocated to some subset of the director’s teams or technology areas. Be clear about which it is.

A startup or small company might only have one very senior engineer, and in that case their scope is probably the entire company; they’ll be involved in every major decision and may influence every other engineer. At a bigger company, a Senior, Staff or Principal engineer might be scoped to a particular team; be part of one team but influence surrounding teams; or be attached to an organisation but not affiliated with any particular team in that org. In companies that are large enough to have really specialised horizontal functions, an engineer’s scope might be all teams and projects that work with a particular technology across the company. For example, their work may affect every software engineer working in some language, or every project that needs to model some kind of data.

A defined scope gives you some bounds on the part of the universe you need to care deeply about. It gives you some pre-computed decisions about where your day-to-day responsibility begins and ends. You should be prepared to ignore your scope when there’s a crisis: when the site is down, for example, there is no such thing as “not my job”. You should also have a level of comfort with stepping outside your day-to-day experience, taking a lead when a lead is needed, learning what you need to learn and fixing what you need to fix. Part of the value of a Staff engineer is that you don’t stay in your lane, and that you’re not constrained by what your job is.

Nonetheless, I do recommend that you have that day-to-day job and that you’re very clear on what it is. I think engineers at all levels should have some sort of scope, even if it’s temporary and subject to change, even if it’s explicitly “everything related to technology for the entire company”. If your scope is too broad (or undefined!), there are a few possible failure modes.

What do you enjoy doing?

While your reporting chain and your scope are likely to be assigned to you, there’s another factor that will influence the shape of your role: you. In most cases, you’ll be able to choose some aspects about how you work. While more junior roles may have more prescriptive expectations about what you do on any given day, by Staff level you’ll usually just be expected to produce results. So long as it’s generally agreed that your work is impactful, you should have a lot of flexibility around how you do it. That includes a certain amount of defining what your own job is.

I’m not going to say what your role should be, but to get you thinking about what you want, here are a few questions to ask yourself:

What’s your current mission

So we’ve discussed your scope and your reporting chain: the rough boundaries of the part of the organisation you’re operating inside, and where in the organisation you sit. We’ve also looked at your aptitudes: how you like to work and what kinds of skills you’re drawn to. But even if you understand all of that and have a clear map of the shape of your role, there’s one question left: what are you going to work on?

As one of the most senior engineers in the company, a Staff engineer tends to be in demand. Your expertise is valuable on projects. Your endorsement of a path carries weight. Longevity in the role and seniority in the organisation just amplifies this.

As you grow in influence, you’ll find that more and more people want you to care about things, and you need to take the time to decide whether you do. Someone’s putting together a best practices document for how your organisation does code review, someone else wants agreement across engineering to be more deliberate about library updates, your group’s doing a hiring push and needs to decide what to interview for, a system you used to work on is hitting its scaling limit, and there’s a deprecation that would be making more progress if it had more senior sponsorship. And that’s Monday morning. What do you do?

In some cases, your manager or someone they report to will have strong opinions about what your mission should be, or will even have hired you specifically to solve a particular problem. Most of the time though, you’ll have some amount of autonomy in deciding what’s most important, and this will increase as you become more senior.

While a few companies may have a glut of senior people who are looking around for things to do, it’s more common that there’s more difficult work available than there are senior people to take it on. That means that every time you choose what to work on, you’re choosing what not to do as much as you’re choosing what to do. You need to be deliberate and thoughtful about what missions you take on.