More on this book
Community
Kindle Notes & Highlights
by
Tanya Reilly
Read between
October 20 - December 20, 2022
Instead, explain your status in terms of impact and think about what the audience will actually want to know.
You don’t get to say, “Well, the project is blocked and so there’s nothing we can do”: you are responsible for rerouting, escalating to someone who can help, or, if you really have to, breaking the news to your stakeholders that the goal is now unreachable.
But if you’re stuck and need help, the biggest failure is not asking for it. Don’t struggle alone.
Write things down. Be clear and opinionated. Wrong gets corrected, vague sticks around.
Although it’s almost certainly apocryphal, there’s a Henry Ford quote about the Model T that illustrates how people in different domains can fail to communicate: “If I had asked people what they wanted, they would have said faster horses.”
It’s hard to build a trusting relationship on completely asynchronous communication.
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.
“The Power of ‘Yes, if’: Iterating on Our RFC Process”
Dr. Rebecca Johnson offers the best test I’ve ever read for accidental use of the passive voice: “If you can insert ‘by zombies’ after the verb, you have passive voice.” It almost always works.
defend your time.
Choose the opportunities where your help is most valuable, and then take deliberate action, with a plan for stepping away again afterward.
“Three Bullets and a Call to Action”
escalating doesn’t mean complaining: it means asking for help.
But the challenges were too big for anyone to solve as a side project. Unless it gets dedicated attention, the work is just not going to happen.
If nobody is assigned to do the work, there’s limited value in breaking it down, optimizing it, or making plans:
the art of the rollup”: summarizing all of the information in one place to “create clarity and reduce chaos.”
The half-migration slows down everyone who has to engage with it. This is a place where a staff engineer can step in and have a lot of impact.
In general, lean toward having the team that’s pushing for the migration do as much extra work as possible, rather than relying on every other team to do more.
If you can be more specific about exactly what you want each team to do—which files you want them to edit, for example—spend extra time providing that information.
Try to make the new way the default. Update any documentation, code, or processes that point people toward the old path.
Show the progress of the work. I worked on one project where I needed to get hundreds of teams to change their configs to use a different endpoint. When I shared the graph showing how many had been done and how many were left to do, people were more eager to do their part to get the numbers down.
If the final teams are really refusing to move off the old system, can you make them its sole supporters and owners, so that it runs as a component of their own service? Last out turns out the lights, friends.
You Don’t Know Where You’re All Going
Choosing a destination You can’t start finding a path to the destination until you’re very clear about what that destination is. Here are some approaches for choosing it:
Set a rule that, until you all agree on exactly what problem you’re solving, nobody is allowed to discuss implementation details.
Emphasize that any strategy will, by definition, make trade-offs, and that it can’t make everyone happy.
You’ll pick a small number of challenges, and leave the other real problems unsolved for now. Chapter 3 has lots more on how to write a strategy: set the expectation that it will not be a short or painless journey.
wrong is better than vague: any deliberate direction will probably be better than staying frozen in indecision.
One way you can choose a problem to solve is by choosing a stakeholder to make happy. Rather than solving “the shared datastore stinks and we need to rethink our entire architecture!” can you solve “one team wants to move its data elsewhere”? Reorient the project around getting something to someone. Aim to solve in “vertical slices”: first you help one stakeholder complete something, and then another.
Don’t forget that you can learn from domains other than software: industries like aviation, civil engineering, or medicine often have well-thought-out solutions to problems tech people think we’re discovering for the first time!
If you’re someone who hates asking for help, remember that by learning from other people’s experiences, you’re amortizing the time they had to spend learning the same thing: it’s inefficient to have you both figure out solutions from first principles.
“Welcome to Phase 2 of the project” is somehow more motivational than “Let’s keep doing what we’ve been doing, but I swear it will be different this time.”
In this section we’ll look at three ways you might declare victory without actually reaching your destination: doing only the clearly defined work, creating solutions you don’t tell your users about, and shipping something quick and shoddy. Watch out for these end states!
Software engineers often think of their job as writing software. When we plan projects, we often only list the parts of the work that are about writing the code. But there’s so much more that needs to happen to allow the user to get to the code: deploying and monitoring it, getting launch approvals, updating the documentation, making it run for real. The software being ready isn’t enough.
Heidi Waterhouse, a developer advocate for LaunchDarkly, once blew my mind with the observation that “nobody wants to use software. They want to catch a Pokémon.”
You don’t just need to tell people that the solution exists: you need to keep telling them. A
Set a culture of quality
Make the foundational work a user story
You can help by making sure the user stories for the project include any cleanup work you’ll need to do. You might frame this as part of user experience (nobody’s excited about a product that’s flaky or falls over a lot), or as laying the foundation for the next feature.
Focus the conversation back on the customer’s needs and show that the work has a real impact on them.
Another option is to set up a rotation where one person on the team is always dedicated to responding to issues and making things better.
This is the blessing and the curse of a staff engineer title: people will assume you know what you’re talking about—so you’d better know what you’re talking about!
But the clearest indicator of what the company values is what gets people promoted.
Engineering goes beyond what you do when you’re talking to computer systems; it’s also about how you talk to humans. So sometimes being a good engineer boils down to being a good colleague.
Being a role model doesn’t mean you have to become a public figure, be louder than you’re comfortable with, or throw your weight around. Many of the best leaders are quiet and thoughtful, influencing through good decisions and effective collaboration (and showing fellow quiet people that there’s space for them to lead).
A staff engineer has the good sense to know when the conventional wisdom is wrong.
The four attributes we’re going to look at for the rest of the chapter are being competent, being a responsible adult, remembering the goal, and looking ahead.
“You want to get so good at your craft that your focus can be almost entirely on what other people are doing and you don’t have to worry about your own execution.” Invest time—lots of time—in honing your technical skills so that they become second nature to you.
Job levels vary a lot across companies. Most places don’t consider years of experience when allocating grades or titles, but staff engineers typically have at least 10 and principal engineers have at least 15.
Never, ever accept a managerial role until you are already solidly senior as an engineer.
