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.

A technique I learned from my friend Cian Synnott is to write out my understanding of my job and share it with my manager. It can feel a little intimidating to answer the question “What do you do here?” What if other people think what you do is useless, or think you don’t do it well? But writing it out removes the ambiguity, and you’ll find out ear

First things first: staff engineering is a leadership role. A staff engineer often has the same seniority as a line manager.

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 tractable, it becomes a growth opportunity for less experienced engineers (sometimes with support from the staff engineer).

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 sh

If you don’t understand how decisions are made in your organization or company, you’ll find yourself unable to anticipate or influence them.

Charity Majors, CTO of Honeycomb, often hands out stickers that say: “Nines don’t matter when users aren’t happy.” “Nines” here refers to service level objectives (SLOs), a common mechanism for measuring system availability. “Three and a half nines of availability” means that 99.95% of the time, the service is up and running. SLOs are useful, but a

Good decisions need context. Experienced engineers know that the answer to most technology choices is “it depends.” Knowing the pros and cons of a particular technology isn’t enough—you need to know the local details too. What are you trying to do? How much time, money, and patience do you have? What’s your risk tolerance? What does the business ne

Be prepared to ignore your scope when there’s a crisis: there is no such thing as “not my job” during an outage, for example. You should also have a level of comfort with stepping outside your day-to-day experience, leading when needed, learning what you need to learn, and fixing what you need to fix.