More on this book
Community
Kindle Notes & Highlights
by
Tanya Reilly
“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?” Her answer: “You create it!”
autonomy demands responsibility. If the thing they asked you to work on turns out to be harmful, you have a responsibility to speak up.
The work that’s most important will often be the work that nobody else sees. It might be a struggle to even articulate the need for it, because your teams don’t have good mental models for it yet.
Think big. If you’re working in a codebase that takes a day to build and deploy, it might be tempting to wish for incremental improvement. “This needs to take only half a day!” But go further than that. If you set a goal of 20-minute deploys, the teams pushing toward that goal have an incentive to have bigger, braver ideas. Maybe they’ll contemplate replacing the CI/CD system, or discarding a test framework that can never be compatible with that goal. Inspire people to get creative.
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.
Previous attempts to improve reliability have centered on adding more testing to your release path—but this actually slowed deploy times and lengthened outages.
As a staff engineer, you’ll likely have opinions on a bunch of things (as in Figure 4-11) you haven’t been invited to help with. If you see a project that’s going in a dangerous direction, or you have ideas about how to make it better, you might nudge your way in and have some conversations. Meddling can be very welcome, or very much the opposite. Make sure you’re not “lobbing a water balloon”: getting involved long enough to cause chaos, then disengaging without sticking around to experience the consequences of your changes.
Product management is a huge and difficult discipline, and it’s not easy to understand what your users actually want—as opposed to what they’re telling you.
“If I had asked people what they wanted, they would have said faster horses.”
The reasons your colleague gives you for being blocked aren’t necessarily the real ones. The person could be intimidated, stuck, or oversubscribed.
One option is to focus on education and hands-on experience. You can run continual classes about the system, making sure that everyone who might have to work on it in future is fully trained and has logged enough hours to handle any problems that might arise. The other option is to make it as easy as possible for people to understand the system when they need it.
