Quotes From The Book - part 4 - The Staff Engineer's Path¶
Over the past two years I had the chance to read a bunch of data-related books on the O'Reilly learning platform: what follows is a collection of quotes from "The Staff Engineer's Path" by Tanya Reilly that captured my attention or hit hard because they were highly relatable.
The Staff Engineer's Path¶
1. What Exactly Would You Say You Do Here?¶
The work that’s most important will often be the work that nobody else sees.
A scope too narrow
When you started out as an 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.
Maybe now you’re convinced that engineers should do this big-picture, big-project, good-influence stuff, but here’s the problem: they can’t do it on top of the coding workload of a senior engineer. Any hour you’re writing strategy, reviewing project designs, or setting standards, you’re not coding, architecting new systems, or doing a lot of the work a software engineer might be evaluated on. If a company’s most senior engineers just write code all day, the codebase will see the benefit of their skills, but the company will miss out on the things that only they can do. This kind of technical leadership needs to be part of the job description of the person doing it. It isn’t a distraction from the job: it is the job.
Why Do We Need Engineers Who Lead Projects That Cross Multiple Teams?
huge decisions can end up being subtle, and they’re often controversial, so essential to making the decision is being able to share context and help others make sense of it
Job ladders vary from company to company, enough that it’s given rise to a website, levels.fyi, that compares technical track ladders across companies.
2. Three Maps¶
If your organization has published a statement of values or principles, that can help you see what the leaders care most about. But these values are aspirational: the real values of the company are reflected in what actually happens every day.
Engineers sometimes dismiss organizational skills as “politics,” but these skills are part of good engineering: considering the humans who are part of the system, being clear about the problem you’re solving, understanding long-term consequences, and making trade-offs about priorities.
3. Creating the Big Picture¶
the process of nemawashi, one of the pillars of the Toyota Production System. It means sharing information and laying the foundations so that by the time a decision is made, there’s already a consensus of opinion.11 If there’s someone who’ll need to give a thumbs-up to your plan, you’ll want those people to show up to any decision-making meeting already convinced that the change is the right thing to do. I’ve always framed this as “Don’t call for a vote until you know you have the votes,” but I was delighted to learn that there’s a word for it.
But the key is that you decide not to decide. You add “make no decision (status quo)” to your list of options and deliberately choose it. You don’t just throw up your hands and walk away.
One of the best ways I’ve seen to clarify trade-offs is to compare two positive attributes of the outcome you want. I’ve heard these called even over statements. When you say “We will optimize for ease of use even over performance” or “We will choose long-term support even over time to market,” you’re saying, (to quote “The Agile Manifesto”), “While there is value in the items on the right, we value the items on the left more.” This framing makes the trade-offs clear.
Interviewing has another benefit: it shows the interviewees that you value their ideas and intend to include them in what you write. You’ll hear about problems that you hadn’t considered and new opinions about problems you already know about. Other people may disagree with you about what the biggest problems are. Have an open mind and take their thoughts seriously
When you’re choosing between Option A and Option B, there’s an implicit third option, C: don’t decide. People often default to Option C, because it lets them stay on the fence and not upset anyone. This is the worst thing you can do.
a tactic from the Internet Engineering Task Force (IETF), whose principles of decision making famously reject “kings, presidents, and voting” in favor of what they call “rough consensus,” positing that “lack of disagreement is more important than agreement.” In other words, take the sense of the group, but don’t insist that everyone must perfectly agree. Rather than asking, “Is everyone OK with choice A?” ask, “Can anyone not live with choice A?”
some techniques for actually creating your vision, strategy, or other broad document.
Here’s a checklist to consider before starting to create a technical vision or strategy.
if there are senior people around, most likely there are already plenty of good ideas. The gap is getting everyone to agree on what to do.
getting people to agree isn’t a chore that stands in between you and the real work of solving the problem: the agreement is the work.
RESOURCES FOR WRITING A TECHNICAL STRATEGY
RESOURCES FOR WRITING A TECHNICAL VISION
4. Time, Energy, and Other Things You Wish You Didn’t Have to Think About¶
The available hours may even decrease. As Will Larson says in one of my favorite of his articles, “Work on What Matters”, “Even for the most career-focused, your life will be filled by 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 increasingly scarce as you get deeper into your career.”
You won’t succeed unless you can defend your time. The number of demands on it will increase and the number of available hours will stay the same, so be deliberate about what you prioritize.
saying no is the price of high-quality work: if you do too many things, you won’t be able to do them well
If you find yourself taking on work that undermines your needs, though, make sure you understand why.
If you have been very clear about your needs and are still unable to make a change, that might be a signal that you’re in the wrong team or the wrong company.
a 2 x 2 graph to map impact against effort (see Figure 4-13), and warns against the quadrant of low effort and low impact, describing such work as “snacking.” Since this work tends to be quick and useful (and feels good), it can be easy to justify doing a lot of it. But, as Traynor notes, “It feels rewarding and can solve a short-term problem, but if you never eat anything of substance you’ll suffer.
If there’s a skill you want to hone, the easiest way to practice it will be to take on projects that need that skill.
When you work with great people, it’s almost impossible to avoid becoming greater yourself.
The skills resource behaves a little differently from the others, because it’s always slowly decreasing
what causes a loss of credibility, one of the big themes was absolutism: if you’re a fan of some technology and advocate for it in every single situation, people will stop believing you know what you’re talking about.
Know how many hours you want to work on an average week, how many you’re comfortable spiking to, and at what point you’ll stop being able to handle the load and fall over.
5. Leading Big Projects¶
if you’re ambiguous, you’re making more work for everyone else as they try to figure out how much the thing you’ve asked for matters. Be explicit about what you want people to do.
you’ll have a better time if you go into the project assuming something is going to go wrong—you just don’t know yet what it will be. This attitude can help you be more flexible, so you’ll find it sort of interesting when the roadblock arrives, rather than being frustrated by it. Reframe these diversions as an opportunity to learn and to have an experience you wouldn’t have had otherwise.
since it’s much easier to discuss a trivial issue than a difficult one, that’s where teams tend to spend their time
a few pitfalls I often see in design documentation
here are the headings that I put in every RFC, and that I think should be included at an absolute minimum.
But it’s a better use of your time to be wrong or controversial than it is to be vague. If you’re wrong, people will tell you and you’ll learn something, and you can change direction if you need to. If you’re trying out a controversial idea, you can find out early whether your colleagues will pull against your approach
Connecting an abstract idea back to something I understand well removes some of the cognitive cost of retaining and describing the idea
The difficulty is the point. I find that I can handle ambiguity when I internalize that this is the nature of the work. If it wasn’t messy and difficult, they wouldn’t need you. So, yes, you’re doing something hard here and you might make mistakes, but someone has to. The job here is to be the person brave enough to make—and own—the mistakes. You wouldn’t have gotten to this point in your career without credibility and social capital. A mistake will not destroy you. Ten mistakes will not destroy you. In fact, mistakes are how we learn. This is going to be OK.
6. Why Have We Stopped?¶
You don’t just need to tell people that the solution exists: you need to keep telling them.
The Agile Alliance proposes setting a definition of done, the criteria that must be true before any user story or feature can be declared finished
Celebrate landings, not launches
Aggregating the facts that go into the rollup is a great way to build your knowledge and make sure you understand what’s going on. But writing it all down also might mean you synthesize new information that nobody had articulated before. Perhaps Alex says, “The new library will give us authentication for this end point.” And later Meena tells you, “We won’t be able to upgrade to the new version of the library until Q3.” You can write down both facts, but also the interpretation, “We won’t have authentication until at least Q3.”
That conclusion might seem obvious with all of the context, but if nobody has reached it before, it may come as a shock to some
A good Three Bullets and a Call to Action email contains (at most) three bullet points detailing the issue at hand, and one—and only one—call to action. That’s it, nothing more—you need to write an email that can be easily forwarded along. If you ramble or put four completely different things in the email, you can be certain that they’ll pick only one thing to respond to, and it will be the item that you care least about. Or worse, the mental overhead is high enough that your mail will get dropped entirely
lack of planning on your part is not an emergency on mine
7. You’re a Role Model Now (Sorry)¶
The degree to which other people want to work with you is a direct indication of how successful you’ll be in your career as an engineer. Be the engineer that everyone wants to work with.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand
Don’t become a single point of failure where the team can’t get anything done when you’re not available. It’s not sustainable. It hides problems.
As the business changes, your priorities will change. Be OK with that. It’s inevitable. Growth, acquisition, new markets, or a change in fortunes will mean that your goals may get thrown out as the company pursues a new direction or even a new culture. If you don’t like that or it doesn’t fit your values, you might no longer be in the right place. But if you just resent change, you’ll spend your time being unhappy. Expect it, and you’ll embrace it as a new challenge instead.
Sometimes a faster solution is better; sometimes a more stable one is. If time to market is vital to your business’s survival, getting a shoddy first version out the door might be more important than having beautiful code and architecture.5 Similarly, if you’re shipping software to accompany a holiday promotion or a major sporting event, an imperfect solution is much better than a late one.
create a sense of safety and calm by being consistent and predictable.
Don’t feign surprise, but go even further. Every time someone apologizes for asking a basic question and there’s a chorus of reassurance from others who insist that it’s actually a good question, culture is built. That’s an environment where it’s easy to learn.
Gently redirecting your colleagues towards more valuable work is an example of what I’m going to talk about next: taking charge of the situation. Note that taking charge doesn’t necessarily mean you have prior authority. It means that you see a gap and you’re stepping up to fill that gap.
The problem is, when junior people do too much administrative or leadership work and not enough technical work, they’re spending their prime technical learning years in a way that doesn’t teach them technical skills. That can stunt their careers in the long run. But, often, leaders don’t step in: the glue work is needed for the project to succeed, and they’re just glad it’s getting done.
As a leader, you have a responsibility to make the implicit explicit. It’s not fair, but if a junior person asks these questions, the team may sigh and say, yes, obviously we thought of that. If an expert asks, team members learn that they should include explicit answers to these questions in their design documentation. (Or they genuinely consider the question for the first time!)
Ownership also means using your own good judgment: you don’t need to constantly ask for permission or check whether you’re doing the right thing. But that doesn’t mean you should operate in private. While the classic advice is to seek forgiveness rather than ask permission, Elizabeth Ayer, a product and delivery advisor, offers a more open and predictable approach: “radiating intent”, the idea of signaling what you’re about to do before you do it. You’re giving everyone else context about your actions—and you’re creating an opportunity to intervene if you’re about to do something dangerous.
Notice if your role is preventing you from continuing to learn. In particular, be wary of drifting so far from the technology that you’re only learning how your company operates. While you should also learn enough about the business to make good choices, keep yourself anchored in the tech.
Never, ever accept a managerial role until you are already solidly senior as an engineer. To me this means at least seven years or more writing and shipping code; definitely, absolutely no less than five. It may feel like a compliment when someone offers you the job of manager—hell, take the compliment —but they are not doing you any favors when it comes to your career or your ability to be effective.
Being staff doesn’t absolve you of being wrong, but it does mean you need to be careful when you open your dang mouth
8. Good Influence at Scale¶
mentoring is focused on your experience.
advice is noisy: there’s bad signal mixed in with good, and it tends to not be tailored to the person who’s receiving it.
9. What’s Next?¶
five metrics for evaluating your job health:
Whether you’re learning
Whether you’re investing in transferable skills or navigating dysfunction
How you feel about recruiting other people to your team
How confident you feel
How stressed you feel
Beware the role that sounds absolutely tailor made for you but also feels completely exhausting when you imagine doing it. Doubly beware if the job is “fancy”—where your friends and family are going to think it’s cool—because then your ego gets in the mix and wants you to take it even though your gut says that you will hate most days on that job. That venn diagram—things you’re exceptional at but hate doing—is one that can lead to career mistakes.