These are my notes from the book: The Staff Engineer’s Path: A Guide for Individual Contributors Navigating Growth and Change by Tanya Reilly

These notes don’t cover everything in the book, only the parts that seemed relevant to me, but they can be a reference for someone who also read the book and wanted to remember key points quickly.

Part 1: Big Picture

1. What would you say you do here?

• The levels below senior are for people to grow their autonomy. Above increase impact and responsibility.
• Job titles are related to implicit bias – we don’t have to prove our skills and build trust every time. They communicate an expected level of competency to the outside world.
• They also give us a feeling of progression
• https://progression.fyi/ – to see career ladders in different companies
• It’s not enough to know the pros and cons of a specific tech stack. We also need to understand the local context.
  • Sometimes what is good for a team may be costly for the organization – local maximum.
  • Teams need decision-makers (or at least influencers) who have an outsider view.
• Sometimes managers can set the direction of technology (e.g. in startups). This may mean a company doesn’t need a staff engineer.
  • Over time it may become a bottleneck to balance people management and being up to date with technology
  • Additionally, the manager’s authority may put pressure and lead to not necessarily the best decisions
  • Still, though, managers need to understand the technology to assign people to the teams
• No matter how well you plan the project, there will always be areas not covered by any team (or covered by multiple teams). Each team has its local maximum and sometimes someone responsible for the whole is necessary. Such people tell the story of what’s going on, and why, they sell the vision to the rest of the organization and explain what these projects enable.
• A manager sets the team’s culture. Staff engineer is like a role model. In a way they also set culture.
  • If a respected engineer doesn’t write tests, they won’t convince others to do it.
  • Therefore they should: celebrate others’ successes; ask clarification questions; treat others with respect.
• The more you deal with strategy, standards, mentoring, etc the less you code. You shouldn’t treat it as a distraction from work. It is the actual work.
• Staff engineer is a leadership role. But they lead differently than managers. They don’t have direct reports. Teaching is a form of leadership e.g.
  • designing “happy path” solutions to protect other engineers from common mistakes
  • by reviewing other’s code and designs in a way that improves their confidence and skills
  • by highlighting that a design proposal doesn’t meet a genuine business need.
• https://kind.engineering/ – how to be nicer to others as an engineer
• Your goal is to solve problems, and writing code isn’t always the most effective way to do so.
• Sometimes you have to take a vague problem and lead it to the place where someone else can take over.
• As a senior engineer, your manager tells you what’s important and you think what to do with it. As a staff engineer, your manager brings you information and context, and you tell them what’s important, and the other way around.
• “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? – you create it!” – Sabrina Leandro
• Your role is to make sure the org has a good tech direction. The job is not to come up with all but to ensure there’s an agreed upon, well-understood solution, decisions get made and are written down.
• Reporting to the upper management gives you access to better context, watching how they work. But at the same time, they have less time they could focus on you and watch your progress.
• What’s your scope?
  • A scope too broad
    • lack of impact – if anything can be your problem them it’s easy for everything to become your problem. You can end up in a role that’s entirely a side quest with no goal
    • becoming a bottleneck – if you have to be part of every decision
    • decision fatigue – you have to constantly decide which things to do
    • missing relationships – if you work with too many teams you don’t have the opportunity to build relationships within a team
  • A scope too narrow
    • lack of impact
    • opportunity cost – you could be doing something more important
    • taking away learning opportunities from engineers
    • overengineering – because you have too much time
• What shape is your role?
  • do you approach things depth-first or breadth-first?
  • four disciplines. The more senior the more crucial it is to switch between. Be aware of which one you’re more inclined to:
    • core technical skills
    • product management
    • project management
    • people management
  • Define how much you want/need to code. If you can’t live without it decide how you’re going to satisfy that need.
  • Be prepared for delayed gratification. Cultural changes can take months/years. You can ask the manager to show his perspective on how things are going.
  • Tech lead manager is a dangerous role because it mixes technical leader and team management and you feel like failing at both.
  • Staff engineer archetypes:
    • Tech leads – Partner with managers to guide the execution of one or more teams.
    • Architects – Responsible for technical direction and quality across a critical area.
    • Solvers – Wade into one difficult problem at a time.
    • Right hands – add leadership bandwidth to an organization
  • You have to focus on important things. What is important? Often something nobody else sees. It might be even hard to articulate a need for it because teams don’t have a good mental model yet. It might involve gathering data that doesn’t exist. Know why the problem you’re working on is strategically important.
  • It’s useful to write down what you think you do and share it with the manager to get an alignment on the job scope.
  • Your job is to make the team successful. Sometimes it means doing things that are not in anyone’s job description.

2. Three maps

A map metaphor:

• locator map – you’re here. See your scope and what’s outside of it. What’s along the borders? It’s to be objective about what’s important for the organization because deep inside you only see your team’s concerns
  • can help you make sure the teams you work with really understand their purpose in the org, who their customers are, how their work affects other people
• topographical map: learning the terrain – know the hazards, difficult people, political boundaries, and skeleton of previous travelers
  • can help highlight the friction and gaps between teams and open up the paths of communication
• treasure map – the goal to follow
  • everyone knows exactly what they’re trying to achieve and why

The Locator Map: Getting perspective

Being too focused on one team/domain has some risks:

• prioritizing badly – your team’s work seems more important and unique than others which leads to teams caring about local maximum
• losing empathy – you consider other domains as easy compared to your rich ones.
• turning out the background noise – you stop noticing problems e.g. failing tests
• forgetting what the work is for – you only develop a small piece and don’t care about the whole thing

You need to take an outsider’s view – as if you just joined the team. Avoid echo chambers and build relationships outside engineering. Engineers tend to be focused too much on technology.

Over time the goals may change. It’s ok if you’re not working on the most important thing but you should not waste your time. If you can’t explain to yourself why what you’re trying to do needs staff eng, you might be doing the wrong thing.

Nines (in SLO) don’t matter if customers aren’t happy. If Bing doesn’t work because of the ISP or CDN it doesn’t matter. Bing doesn’t work.

📚 Recommended resources:

• conference: leadDev, SREcon
• rands leadership slack
• infoQ software architects newsletter
• VOID report
• SRE weekly
• raw signal newsletter – manager’s point of view
• technology radar quarterly updates

The Topographical Map: Navigating the Terrain

Rough terrain (challenges) without understanding how the organization works

• your good ideas don’t get traction
• you don’t find out about the difficult parts until you get there
• everything takes longer

Questions that help to understand engineering culture:

• secret or open?
  • calendars are private, slack channels are invite-only, and you get access to something if you ask for it. It’s harder to come up with a creative solution because you may miss the context
  • in open org, you have access to everything, even messy first drafts and you can get decision fatigue. Not clear which documents are official and which are just early ideas
  • sharing information in secret org – you lose trust, withhold information in open – you’re considered political.
• oral or written?
  • in oral, your documents may not even be read. In a written one you may be considered irresponsible if you just make the change without a design discussion
• top-down or bottom-up?
  • in bottom-up – when initiatives need broader support, and there’s disagreement, it may lead to deadlock. In top-down decisions won’t be the best because they miss the local context.
  • It’s good to know the type of organization and where to search for support for your initiatives.
• fast change or deliberate change?
  • in a fast one, you want an incremental path that shows value immediately. In a slow one, you need to show you thought everything through
• back channels or front doors?
  • if everyone is strict about formal channels, it will be considered rude to ask questions out of turn, if back channels are typical you can wait for a month to get a response on a ticket while you could just have talked to someone
• allocated or available?
  • if everyone is overworked, new ideas will be rejected. The most accepted ones are these which don’t require people’s effort and free up their time. If people are available they quickly become busy with too many novel ideas. In that case, you will get the most impact by helping finish the project
• liquid or crystalized?
  • crystalized – you get your project, you wait in turn, you get promoted. In liquid you have more room to change but it requires more hussle. And ultimately it’s still some sort of favorism and biases – see https://istechameritocracy.com/

What do leaders think it’s important? It can shape the organization via rewards and punishments.

Westrum’s typology model (oriented around X):

Pathological	Bureaucratic	Generative
Power-oriented	Rule-oriented	Performance-oriented
Power	Rules	Mission
Low cooperation	Modest cooperation	High cooperation
Messengers shot	Messengers neglected	Messengers trained
Responsibilities shirked	Narrow responsibilities	Risks shared
Bridging discouraged	Bridging tolerated	Briding encourated
Failure -> scapegoating	Failure -> justice	Failure -> inquiry
Novelty crushed	Novelty -> problems	Novelty implemented

DORA suggests that high trust culture organizations have better software delivery performance.

Points of interest (map reference):

• chasms – when teams have different goals e.g product vs security
• fortress – gatekeeper that blocks any progress
• disputed territory – two teams overlap, or responsibility is smeared across too many people
• uncrossable deserts – many have tried before and failed
• paved roads, shortcuts, and long ways around
  • e.g. self service checklists (paved roads)
  • shortcuts e.g undocumented features, admin who responds to DMs
• other ideas:
  • cliffs you can walk off
    • behavior or communication styles that would be ok elsewhere but here are considered rude
    • are there guardrails you expected to be in plae but that just aren’t
    • are there leaders who cause earthquakes
    • which teams are led by monarchs, and which by councils, which ares anarchy?
    • Who’s at war with whom?

To affect decisions you need to understand how they are made (and where). Maybe there’s a weekly managers’ meeting. You can ask someone where particular decision came from. Sometimes there may no “room”. Decision can be made on 1on1s, or entirely bottom up.
When asking to join – point out why the organization will benefit, not you personally.
Also, reduce cost of including you: come prepared, be collaborative.

Shadow org chart: there can also be informal decision-making process, e.g. “connectors” – people who know everybody, or “old-timers” who regardless of title, would influence just from being around a long time.

Keeping topographical map up to date:

• subscribe to dedicatee channels and announcements
• walking the floor – idea of gemba. E.g. occasional reviews or pair programing on other teams’ code
• lurking – checking info that isn’t secret but isn’t exactly for you e.g. checking others’ calendars, looking at meeting agendas (when you don’t participate), checking all slack channels, to know which projects are going on
• reading docs, RFCs
• checking in with your leadership
• talking with people e.g. from other departments

Build bridges e.g. by sending email summary nobody is sending, introducing two people who should have spoken a month ago, writing a document to show how projects connect to each other.

The Treasure Map: Remind Me Where We’re Going?

Thinking only about short term goals can be limiting.

• it will be harder to keep everyone going in the same direction
• you won’t finish big things
• either the system will have to support every case and it’s hard to maintain, or can make local decision and become an edge case
• you’ll have competing initiatives
• engineers stop growing

Sometimes what you’re doing is not a real goal. It’s just an enabler to achieve a bigger goal.

When you have the narrative, even small task become part of a bigger story.

3. Creating the big picture

📚 Technical vision – resources:

• https://www.eventbrite.com/engineering/writing-our-3-year-technical-vision/
• https://jlhood.com/how-to-set-team-technical-direction/
  • Vision:
    • A picture is worth 1000 words. Architectural block diagrams can add a lot of clarity around key components and their relationship to one another.
    • Don’t try to fit your entire vision into a single picture – C4 can help
    • Stay abstract. Avoid choosing specific technologies. Instead, stick to defining components and keep concepts like databases, queues, streams, etc generic, rather than naming a particular solution.
  • Strategy:
    • focus on small incremental but possible steps
    • they accumulate and one can enable another that was unattainable before
    • to decide what to pick up – you can use the Effort matrix – Effort vs Impact.
      • High impact, low effort – yes!
      • High effort, high impact – maybe
      • Low impact, low effort – maybe
      • high effort, low impact – no!
    • Use the long-term vision as your guidepost.
    • Enumerate the key business and/or technical wins of each milestone. This ensures you know why you’re doing each one.
    • Be concrete. Unlike your long-term vision, short-term solutions should be well-defined. Choose specific technologies and justify your choices.
    • Don’t try to define every single milestone all the way to the end goal. The long-term vision is directional and it may (will) change and evolve as you learn more from each milestone. Trying to define every step at the outset is difficult and wastes time.

The vision may include:

• a description of high-level values and goals
• a set of principles to use for making decisions
• a summary of decisions that have already been made
• an architectural diagram

Vision is big and gives direction.
Strategy is tangible. It’s about path, not direction.

📚 More Resources:

• Good Strategy Bad Strategy: The Difference and Why It Matters – Richard Rumelt
• Technology Strategy Patterns: Architecture as Strategy – Eben Hewitt
• https://leaddev.com/leaddev-live/technical-strategy-power-chords
• https://leaddev.com/staffplus-new-york/video/getting-commitment-tackling-broad-technical-problems-large-organizations
• https://lethain.com/survey-of-engineering-strategies/

You could follow 3 steps:

• the diagnosis – describe the current state of the system in a simplified way e.g. using metaphor or finding patterns
• guiding policy – approach to bypass obstacles
• coherent actions

Strategy is NOT aspirational. It has to be realistic and acknowledge constraints.

Writing vision and strategy takes time. If you can achieve the same outcome in a more lightweight way, do that.

A big part of creating the vision/strategy is convincing people to follow you.

The strategy/vision is usually boring and obvious.

Have perspective about leading competition:

• is their direction wrong or is it just different
• would you advocate just as hard if it was a colleague’s idea
• be wary of fighting for a marginally better path at the cost of not making decision at all

Sponsor of the vision is helpful. It can serve as a tiebreaker. To get a sponsor you need to sell the idea in a way that makes others care/want it. A sponsor needs the power to decide what an organization spends time on.

Gather your core group: When one person is distracted, the others will keep the momentum going. Knowing that you’ll need to check-in about the work can be a motivator.

Be clear that you’re the lead from the beginning e.g. by adding roles section to the documents.
Offer opportunities to lead and be supportive of initiatives.
Make sure you have influence for where you plan to make a change e.g someone from that specific team in your core group or a sponsor.

Make sure the problem is solvable to not waste time. E.g. ask someone who has done it before.

Helpful questions before writing the vision:

• what documents already exist
• what needs to change
• e.g. architectural characteristics scalability, extensibility, availability (by Mark Richards and Neal Ford)
• what’s great as it is
• if you’re going to sacrifice something be conscious about it
• what’s important
• what will Future You wish that Present You had done

Interview people to get more context:

• what’s important to include
• what’s it like working with
• what else should i have asked you

Tradeoffs: while we value thing X we value thing Y even more.

Building consensus: rough consensus approach. Lack of disagreement is more than agreement. Don’t ask is everyone ok with the choice. Ask “can anyone NOT live with the choice”. Not making decision is also a decision. Usually the worst.

https://thedecider.app

Nemawashi – sharing information and laying foundations so by the time a decision is made there’s already consensus.

A catchy slogan (e.g. “Project Homecoming” when migrating data from the US to the EU) can help align people because it’s easy to remember, so people refer to the strategy even if you’re not in the room.

The change should be comfortable. If it’s too radical it can be hard to convince people. If you want to go from A to B, make sure you are actually at A. See Overton window.

To make the document more engaging you can use personas.

When the document is official do not allow comments or resolve them quickly.

Part 2: Execution

4. Finite time

Put work into calendars, not only meetings (interruptions to work)

The bars (a’la the Sims)

• Energy
  • smartbrain – the energy to stay focused.
  • understand what the entry level is to even start certain types of tasks
• Credibility
  • you can build credibility by solving hard problems, showing good technical judgment
  • absolutism is a way to lose it e.g. if you see one tool to solve all the problems
  • if you’re polite, communicate clearly, and stay calm in stressful situations people will trust you
• Quality of life
  • do you enjoy what you do? And if not, does it lead to something you value?
• Skills
  • it’s slowly decreasing. If the project doesn’t teach you anything your skills slowly become outdated
  • ways of learning:
    • deliberate learning e.g. courses, books
    • working with someone more skilled
    • learning by doing
• Social capital
  • is a mix of trust, friendship, a feeling of owing someone a favor or believing they’ll remember that they owe you one.

Sources of projects

• you’re invited to join
  • you may be invited because you did something similar in the past, not because it has an opportunity for you to grow
• you ask to join
• you have an idea
• the fire alarm goes off
  • late project, performance regression, incident.
  • it’s a major context switch
  • too much of this moves you away from the main project
• you’re claiming a problem
  • finally fixing something e.g. tech debt
  • you gain social capital (kudos)
  • too much of this moves you away from the main project
• you’re invited to join a grassroot effort
  • some work that’s nobody’s OKR e.g. improving testing across the company
  • can be an opportunity to work with interesting people and have a huge impact, can also be a waste of time
  • working groups can be effective if there’s organizational buy-in, clear time commitment, exit criteria, process for decision-making
• someone needs to…
  • e.g. unexpected request from another team, action item from a meeting, problem nobody anticipated
  • as a senior, you can shield less experienced colleagues
  • volunteering can build credibility
  • too much of it and people can always expect it from you
• you’re just meddling
  • sharing opinions on things you haven’t been invited to. E.g. if the project goes in the wrong direction or you see an easy improvement
  • do not “lobby a water balloon” – getting involved long enough to cause chaos, then disengaging

What are you signing on for?

• projects can change time commitment over time e.g. blow up after project approval
• is 1h recurring meeting a one hour or does it require prep and action items afterwards?
• if the meeting is in the middle of an empty block, will be able to use the rest of it productively
  • a single meeting can build your social capital and credibility or drain your energy and morale

Questions to ask yourself about projects

• energy: How many things are you already doing?
  • e.g. like juggling the balls. If you take too many at some point one will drop (and not necessarily the least important one)
  • the author says they care 5 topics to care about at once
  • and also consider things in real life. E.g. it may not be the best time to start an engaging project
• energy: Does this kind of work give or take energy?
  • will it involve a lot of meetings, reading to understand the context, and working with people who leave you exhausted after each interaction?
• energy: Are you procrastinating?
  • low-impact, low-effort work can be tempting. It feels like work and it’s easy.
  • https://www.intercom.com/blog/first-rule-prioritization-no-snacking – this kind of work is like snacks. You can’t live only on snacks.
• energy: Is this fight worth it?
  • when you try to solve unowned problems (OPP other people’s problems), even if the project is successful it could drain more energy than you intended
• quality of life: do you enjoy this work?
  • will it be exciting enough, or too intense?
  • will you work alone or in a group?
  • will you have to be on call?
  • will you have to travel?
  • will it involve publicly sharing e.g. talks, writing articles?
• quality of life: how do you feel about the project’s goals?
  • your values
• credibility: does this project use your technical skills?
  • so that you’re not an ivory-tower developer
• credibility: does this project show your leadership skills?
  • taking responsibility for outcomes
  • communicating
  • be aware of the risk of failure: if you’re taking an unwinnable battle will you be respected for trying or blamed?
• social capital: is this the kind of work that your company and your manager expects at your level?
  • work that matters to the people in your reporting chain is work that builds social capital
  • “managing up”
  • help your boss be successful. Their success gives them social capital they can spend to help you
• social capital: will this work be respected?
• social capital: are you squandering the capital you’ve built?
  • e.g. if you recommend a friend you can’t vouch for
• skills: will this project teach you something you want to learn?
  • what story do you want to tell in your resume?
• skills: will the people around you raise your game?
  • you learn by watching the skill being executed well
  • you still can learn from less experienced if they do a good job

If it’s not the right project you can:

• do it anyway
  • the easiest, but not sustainable
  • if you feel it makes you unhappy, let your manager know
• compensate
  • maybe the project is not perfect, but has something good too
  • remove something from your agenda to make space for it, or make space for something that would make you happy
• let others lead
  • a project that isn’t a good fit for you right now might be an excellent opportunity for someone else
  • there may be work that you would do great but you can show trust if you let others do it
• resize the project
  • maybe you can join part-time, or for a few months, or only advise, or recommend someone
• say no
  • saying no is the price of high-quality work: if you do too many things you won’t be able to do them well
  • not all problems are your problems

Defend your time

Context: you want to ask a VP or an upper manager for help but you feel bad about it.
PoV: ask them. You don’t get to that level without knowing how to defend your time.

You are responsible for managing your energy.

5. Leading big projects

Not genius makes a good leader but perseverance, courage, and willingness to talk to other people.
Projects are not complex because you push boundaries of the technology but because you deal with ambiguity, unclear direction.

At the beginning of the project, you feel overwhelmed. But that feeling of discomfort is called learning. Managing discomfort is a skill that you can learn.

Feeling impostor syndrome could be a signal that you lack the resources from Chapter 4.

“99% of people don’t know better than I what to do”. The difficulty is the point, it’s the nature of the work. If it wasn’t messy and difficult, they wouldn’t need you.

How to make projects less overwhelming

• create an anchor for yourself – document things (just for you), leads, rumors, and todos in one place, so that you can get back to it when you’re stuck
• talk to your project sponsor – and agree if you understand the project mission the same way
• decide who gets your uncertainty – find a person you can talk to to share your fears and who can admit it is indeed a hard problem. Don’t let your fears spill into juniors but show them that you’re learning too
• give yourself a win – just do something to make any step forward, write things down, draw a picture, learn. It’s the right time to not know things.
• use your strengths – start with something you feel comfortable with

Building context

you have to create maps for yourself

• goals – if you’re working on something and you don’t know why probably it won’t solve the problem
• customer needs – you need to understand the needs to build the right thing. You have to listen, don’t fill the gaps by what you think people need. Don’t use jargon because people won’t admit they didn’t understand
• Success metrics – you need to measure if you’re right.
• sponsors, stakeholders, and customers – who wants this project, and who’s paying for it? It will be easier to sell the value of the work if you can find other people who want it too.
• fixed constraints – are there deadlines you can’t move? Do you have a budget? Are there teams you depend on that are too busy? There’s a difference between “ship a feature” and “ship a feature without enough engineers and with two stakeholders who disagree on the direction”
• risks – for sure something will go wrong. Try to foresee them. Are there unknowns, dependencies, and key people who will doom the project if they quit? A common risk is the fear of wasted effort. If you make frequent, iterative changes you can mitigate it
• history – respect what came before. When other teams have failed to solve the problem, there may be leftover components you may need to use, work around or clean up first. If you’re new to an existing project don’t just jump in. Identify half-built systems, understand people’s feelings, and expectations, and learn from their experience.
• team – try to have good relationships with other leaders. Unclear expectations of who’s doing what are a common source of conflict.

Giving your project structure

• defining roles
  • make it clear who’s responsible for what e.g. in the form of a table (items like: setting timelines, setting KPIs for product success, understanding customer needs, devising A/B experiments)
  • you can use the RACI model (known as the responsibility assignment matrix)
    • Responsible – the person actually doing the worm
    • Accountable – ultimately delivering the work and responsible for signing off when it’s done
    • Consulted – asked for opinions
    • Informed – kept up to date on progress
  • alternative approach: team leader Venn diagram: what, how, why (and maybe when)
  • “here’s what I think I’m responsible for. Do you agree? Am I taking the right amount of ownership?“
  • if you’re the project lead you are responsible for the project and you’re implicitly filling any unassigned roles
• recruiting
  • try to find people who have skills you don’t have
  • good leads are not only tech skills but also optimistic, good at conflict resolution, good communicators
• agreeing on scope
  • define milestones. Users can give early feedback. This also means they can change requirements because seeing what they can do helps them realize what else they want.
  • with milestones, you constantly have deadlines that embed a sense of urgency
• estimating time
  • practice estimation. Estimate every milestone and then adapt your previous estimates for the next steps
  • keep other teams in mind
• agreeing on logistics
  • how often are going to meet? Will you have demos, retros, or other ceremonies?
  • how will you encourage informal communication?
  • how will you share the status? Who will do it and how?
  • where is the documentation?
  • what are the development practices?
• having a kickoff meeting
  • even if everything is written down it can give the project a momentum
  • ideas of topics to cover:
    • who everyone is
    • what the goals of the project are
    • what’s happened so far
    • what structures you’ll all set up
    • what’s happening next
    • what you want people to do
    • how people can ask questions and find out more

Driving the project

Driving means choosing the route, making decisions, and reacting to hazards.

• exploring:
  • the better you understand the problem the easier it is to frame it for other people
  • unify vocabulary
  • first understand the problem. Only then come up with solutions. Otherwise, you may try to use your original ideas ignoring the actual problem.
  • maybe you can reuse existing solutions. It means fewer things to maintain.
• clarifying:
  • new facts are as useless and fugitive as necklace beads without a connecting chain
  • you can explain a new/difficult concept by relating it back to the concept you already understand (e.g. this book does this with a map analogy)
  • ubiquitous language. Or at least provide a glossary.
  • pictures reduce complexity a lot
    • if something is changing – use “after” and “before” pictures
    • if one idea fits within another, draw them as nested
    • if they’re parallel concepts they can be parallel shapes
    • if there’s a hierarchy you might depict a ladder, a tree, or a pyramid
    • humans should rather be a sticky man or an emoji than a box
    • be aware that shapes may have associations e.g cylinder is a database
    • if you use colors people start to interpret their meaning (e.g. may assume green is good, red is bad)
• designing:
  • RFC template serves as a checklist so that you won’t forget about different aspects or questions
  • provide context, goals, and design. Do not include implementation in the goals.
  • wrong is better than vague. Be precise about who and what will do. If you’re using passive voice it may be a sign of vague design. Don’t be afraid of repeating yourself instead of using this and that.

RFC Template

RFC should contain:

• context: title, author’s name, dates, status of the document (early idea, open for detailed review, superseded by another document, being implemented, completed, on hold)
• goals: show what problem you’re trying to solve or what opportunity you’re trying to take advantage of.
  • If the goal suggests the question “ok, but why are you doing that” then you should answer that question too.
  • The goal shouldn’t include implementation details
• design: how you intend to achieve the goal
  • give your audience what they need to know. If you’re writing for potential users or product managers make sure you’re clear about functionality and interfaces. If you depend on systems or components, include how you’ll want to use them
  • could be a couple of paragraphs or 10 dense pages. Could be a narrative or set of bullet points
  • design could include: APIs, pseudocode or code snippets, architectural diagrams, data models, wireframes or screenshots, steps in a process, mental models of how components fit together, organizational charts, vendor costs, dependencies on other systems
  • wrong is better than vague. Don’t skip the design section because you don’t want people to argue about the details:
    • be clear about who or what is doing the action for every single verb. Avoid passive tens e.g. the data will be encrypted
    • don’t be afraid of repeating things. Instead of saying “this” or “that” spell out exactly what you’re referring to
• security/privacy/compliance: what do you have worth protecting and from whom? Does it plan to collect user data in any way? Does it open new access points to the outside world? How are you going to store secrets?
• alternatives considered/prior work: if you could solve this same problem with spreadsheets would you still want to do it?
  • If you find yourself omitting this section because you didn’t consider any alternatives, that’s a signal you may not have thought the problem through.
  • has anyone else at the company ever tried something similar and why isn’t their solution a good fit?
• optional: background: what information does a reader need to evaluate this design? You could include a glossary
• optional: trade-offs: what are the disadvantages of your design? What tradeoffs are you making because you think the downsides are worth the benefits?
• optional: risks: what could go wrong? Don’t hide your concerns.
• optional: dependencies: what are you expecting from other teams? Do you need to provision infrastructure, need approval from security, legal, communication
• optional: operations: who will run the system? How will you monitor it?

Technical pitfalls

• it’s a brand new problem (but it isn’t )
• this looks easy (it means you don’t understand the domain)
• building for the present
• building for the distant, distant future
• every user just needs to… – explaining how to use the counterintuitive system doesn’t scale
• we’ll figure out the difficult part later
• solving the small problem by making the big problem more difficult
• it’s not really a rewrite (but it is)
• but is it operable? –
  • if you don’t remember how it works at 3 pm, you won’t remember at 3 am
• discussing the smallest decision the most (bike-shedding)

Coding

• thoughts by Joy Ebertz
  • writing code is rarely the highest leverage thing a lead can spend time on
  • however, coding gives a depth of understanding and helps to spot the problems
  • it can also keep you engaged
  • it makes you feel the costs of your own architectural decisions
• if you, as a lead, are coding, take work that’s not time-senstive
• think of your code as a lever to help everyone else. E.g. you update the code and this establishes the pattern because you know people will copy it for future cases
• prioritize the team’s sense of ownership over your own sense of aesthetic
• knowledge sharing: if there’s something only you know how to fix – insist on pairing; write a code to establish a new pattern but then hand it off to someone to implement it
• think about how your code review comments will be received. You want to be perceived as a resource to learn from, not as someone who criticizes every decision. Sometimes it’s better to let someone set the pattern that’s good enough even if you would have done it better
• you’ll be an example: improve testing standards, and documentation, and be careful about taking shortcuts. If you’re sloppy you’re going to have a sloppy team

Communicating

• talking to each other. Encourage them to ask clarifying questions.
• sharing status
  • just necessary information
  • explain your status in terms of impact
  • think about what the audience really wants to know
  • don’t mention delays or problems that don’t need escalation
  • practice explaining e.g. following facts with “that means” or explaining that you’re doing something “so that we can”
  • avoid “watermelon projects” – green outside, red inside

Navigating

• assume something will go wrong. You just don’t know yet what exactly
• treat it as a learning opportunity

6. Why have we stopped?

Will Larson: a surprising number of projects are one small change away from succeeding, one quick modification away from unlocking a new opportunity, or one conversation away from consensus.

Stuck in traffic

Techniques:

• understand and explain
  • make sure everyone else has the same understanding of what’s happening
• make the work easier
  • by not needing as much from the people you’re waiting for
• get organizational support
  • it’s easier to prioritize if you link to the company objective
• make alternative plans

blocked by another team

Reasons:

• misunderstanding – the other team doesn’t know there’s a deadline or doesn’t understand what you expect from them
• misadventure – someone on the team quits, gets sick, etc. that just can’t do it
• misalignment – one team’s main priority may be the other team’s 3rd priority

Techniques:

• understand and explain:
  • explain why it is important and what you expected them to do when
• make the work easier:
  • scope down to a must-have feature, think if you can do anything to unblock them doing a side quest
• get organizational support:
  • ask leadership which priority is higher. When escalating use unemotional facts: explain what you need, why it’s important, and what’s not happening. Ask your manager for opinion before escalating
• make alternative plans:
  • rescope the project, move the deadline, choose a different direction

blocked by a decision

When you’re waiting for a decision from someone else, it’s tempting to think of their work as easier than yours.

Techniques:

• understand and explain:
  • remeber you’re on the same side, see if you can navigate the ambiguity together. Understand what information they need to make a decision. Make sure they know why it matters and what can’t happen until the decision. Explain the impact on the thing they care about
• make the work easier:
  • build a mental model of how your question is received. Think if you can use pictures, user stories, and examples to reframe the question. Explain what’s hard or expensive to reverse later
• get organizational support:
  • talk to the project sponsor. They may have ideas or influence
• make alternative plans:
  • sometimes you may need to take a risk and make the decision yourself. Document the tradeoffs.

blocked by a f*cking button click

Even if the work/approval takes them 10 minutes it’s not their only work. “Lack of planning on your part is not an emergency on mine”.
It’s not just a button click. They take responsibility for the approvals

In general use the same techniques from the dependencies. But if you need to skip the line:

• understand and explain:
  • try asking, be polite, say thank you
• make the work easier:
  • check how other requests look like, and what are frequent problems, and prepare your request to be the easy one
• get organizational support:
  • try to avoid. Be clear that you understand why they have this process
• make alternative plans:
  • make connections within the team. Otherwise, let the stakeholders know.

blocked by a single person

It can be they are overwhelmed, have a personal crisis which makes it impossible for them to focus, didn’t understand what you need twice, and are afraid to ask 3rd time.

• understand and explain:
  • get a sense if it’s something you can help with. Be clear about why the work is necessary. Consider setting a deadline
• make the work easier:
  • add a structure, break the problem down
  • “three bullets and a call to action” (Fitzpatrick, Collins-Sussman)
  • help the person start by pairing – useful when you’re waiting for your manager – set up a 1:1 with them, let them do the work, and be there to answer the questions
• get organizational support:
  • try to avoid but if someone is not doing their job and that’s going to fail the project, you don’t do it either by ignoring it

blocked by unassigned work

If nobody is assigned to do the work there’s limited value in breaking it down.

Techniques:

• understand and explain:
  • If you’re the person most interested in the success of the project, don’t be surprised people think you’re the owner.
  • rollup technique: summarize complex problems that would fit into a rollup.
• make the work easier:
  • if you have time to mentor, advise, or join the team doing the work mention that in your rollup. Directors are more inclined to build a team around existing volunteer
• get organizational support:
  • advocate for owning team and organizational support. Prepare an elevator pitch and be able to justify the effort it needs
• make alternative plans:
  • if you keep hearing “next quarter” without any specifics it may not happen

blocked by a huge crowd of people

E.g. a migration. One team supports the migration but doesn’t have time; one team is opposed, they prefer the old system; one team doesn’t have preferences but is just tired of constant upgrades.

Techniques:

• understand and explain:
  • don’t let the narrative get lost. “infrastructure team wants to play with new technology” while they apply legal requirements that they are not happy about. “Product team doesn’t care about tech debt” while they already spend half of the quarter on other migrations.
  • try to understand both sides and build the story. Be a bridge
• make the work easier:
  • automate what you can
  • tell each team what exactly to edit
  • make sure the new way actually works for the teams
  • make the new way the default e.g. templates, documentation
  • add friction to use the old way e.g. i_know_this_is_unsupported
  • show the progress of work. This can motivate
  • try to identify components that nobody owns and try to do it on your own or find a team to pair
• get organizational support:
  • can you make the migration a company quarterly priority? If not, maybe you shouldn’t be spending time on it right now. And finish other work first
• make alternative plans:
  • if you have support and it doesn’t affect users you may add more friction to old systems e.g. artificially slowing them down or introducing controlled downtimes
  • if there’s one team to refuse the migration make them owners of the old system. Last out turns out the lights

You’re lost

you don’t know where you’re all going

A huge group tackling an undefined mess will almost get stuck in analysis paralysis.
You can’t steer the project because it’s just a bunch of ideas: there’s no project to steer. You can’t start finding a path to the destination until you’re very clear about what the destination is.

• Clarify roles
  • Be explicit that you want to hear from everyone, but that you’re NOT aiming for complete agreement
  • If you don’t have the power to name yourself a decider, ask your project sponsor to back you up.
• Choose a strategy
  • 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 make trade-offs and it can’t make everyone happy. You’ll pick a small number of challenges, and leave other real problems unresolved for now.
• Choose a problem
  • If you don’t have time to rank the work by importance choose something, any real problem.
  • Set the expectation that you won’t allow the group to divert by the other, real issues but you intend to return to them after solving the first one
• Choose a stakeholder
  • It can help define a problem by choosing a stakeholder to make happy.
  • Reorient the project around getting something to someone.
  • Progressing in some direction can help break the deadlock and clarify next steps

you don’t know how to get there

The path forward is unknown but not unknowable.

• Articulate the problem
  • Try writing it out or explaining it out loud to yourself.
  • Notice places where you could be more precise about who or what you’re referring to or what is happening versus what should be happening
• Revisit your assumptions
  • Is it possible that you’ve already assumed a specific solution?
  • Are you looking for a solution that’s an improvement on every axis when trade-offs might be acceptable?
  • Are you dismissing any solution because it seems “too easy”?
  • Explain it out loud why you think the problem can’t be solved.
• Give it time
  • Sleep on it or take a vacation from the problem
• Increase your capacity
  • Schedule yourself some dedicated time to really focus and clear the noise
• Look for prior art
  • For what other people have done internally and externally
  • Look at other industries e.g. aviation, civil engineering, medicine
• Learn from other people
  • Check online communities
  • Talk to the project sponsor
• Try a different angle
  • E.g. if you’re trying to solve a technical problem, think about an organizational solution. Or organizational problem solved with a code.
  • What if you had to outsource it: who would you pay to solve this problem? And what would they do?
• Start smaller
  • If you’re overwhelmed, try solving one single small part and see if you can feel a sense of progress.
  • Could a hacky solution be good enough for now?
• Ask for help
  • From coworkers, mentors, local experts, or a project sponsor.

you don’t know where you stand

You don’t know if your work is still necessary. E.g. due to political, and organizational changes, new leaders, and new priorities.
But remember that your project might be just going so well that you’re getting less attention.

• Clarify organizational support
  • Talk with your manager or project sponsor, explain what you’ve heard, and ask whether your project is intended to continue.
• Clarify roles
  • see RACI Matrix
  • if you’re trying to run a project with a title like “unofficial lead” that will fail. If you’re the lead, and nobody else knows you are, you’re NOT a lead.
• Ask for what you need
  • Ask for reassurance, and be mentioned in a list of important initiatives at all-hands meetings.
• Refuel
  • new deadlines, building a new program charter, having a new kickoff or off-site meeting.
  • resetting with “Welcome to Phase 2” is more motivating than “Let’s keep doing what we’ve been doing”

You have arrived … somewhere?

but it’s code complete

It can happen because engineers often think only about the code. Not testing, rolling out, monitoring. “Nobody wants to use software. They want to catch a Pokemon“

• define “done”
• be your own user (dogfooding)
• celebrate landings, not launches
  • celebrate shipping things to users, rather than milestones that are only visible to internal teams

it’s done by nobody is using it

It’s not about building the solution. You also have to market it. It’s like a farmer who planted a seed, watered it, weeded and grew the crop and then left it.

• tell people. Not once. Keep telling
• make it discoverable. Link from the docs, add a go/link

it’s built on a shaky foundation

The hacky prototype turns into production software. There’s no such thing as a temporary solution.

• set a culture of quality.
  • Keep asking for tests or documentation in PRs. Add templates and style guides.
• make the foundational work a user story.
  • For example, add a cleanup work as part of the project. You may frame it as user experience because users don’t like flaky software, or laying the foundation for the next feature.
  • if people report bugs you can include a cleanup there. Focus the conversation on the customer’s needs.
• negotiate for engineer-led time.
  • fix-it weeks
  • tech debt weeks
  • set up a rota for responding to issues and this could also include making things better when nothing happens

the project just stops here

• the project is “done enough”
• – check if it’s really done, you are not abandoning unhappy customers, or walking away from a half-migration
• you kill it early
  • avoid a sunk cost fallacy
  • “that didn’t work. It’s ok. Here’s what we learned”
  • write a retrospective
• it’s cancelled
  • accept your emotions. Accept team members’ emotions. You can talk them through with your manager
  • try to tell the team directly. Don’t let them find out from all hands etc
  • start explaining to the team with the why
  • cancelled projects can derail promotions. Try to showcase everyone’s work
  • if technical decisions are done without technical people it could be time to discuss this with a manager
• you declare victory
  • worth doing a retrospective. E.g. to discuss things that went well and should be continued

Part 3: Levelling up

7. You’re a Role Model now (sorry)

People will assume you know what you’re talking about. Your work will be less checked and your ideas will be considered credible. Rather than guiding you, people will look to you for guidance.

Sometimes you will think “someone should say something” and you will realize that someone is you.

The company can have values. However, the clearest indicator of what the company values is what gets people promoted. E.g. if the company claims they promote collaboration but someone becomes a staff engineer through a “heroic” solitary effort, it can undermine the claim.

You shape your company every day by how you behave.

Be competent

• know things:
  • build experience
  • 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
  • staff engineer is typically 10+ years, principal 15+
  • build domain knowledge
  • you may see patterns from other domains
  • when you’re in a new domain, know which technologies are on the market and how they might be used, know who the “famous people” are and what they advocate for
  • stay up to date
  • even if you don’t know the hottest tools, know how to find out
  • be wary of drifting so far from technology that you only learn how your company operates. You should keep yourself anchored in tech
  • show that you’re learning. Especially to juniors
• be self-aware
  • admit what you know
    • you don’t have to be the best in the industry to call yourself an expert
    • it’s not bragging. It’s a statement of fact
  • admit what you don’t know
    • if you bluff you lose an opportunity to learn
  • understand your own context
    • your perspective, opinions, and knowledge are specific to you
• have high standards
  • seek out constructive criticism
    • when you request comments be open to taking them
    • your solutions are not you and they don’t define you
  • own your mistakes
    • don’t beat yourself up but don’t deny the impact
    • solving the problem you caused may not be what you love but it’s a good opportunity to retain the goodwill and social capital
    • a leader being open about their mistakes gives psychological safety to others
  • be reliable
    • finish what you start
    • it builds up when people see you get things under control

Be responsible

• take ownership.
  • avoid “cover your ass engineering”
  • ownership means using your own good judgment: you don’t need to constantly ask for permission or check whether you’re doing the right thing
  • while the advice is to seek forgiveness than ask permission, a better option is to radiate intent – signal what you’re about to do before you do it. It makes you keep responsibility and doesn’t transfer it when seeking permission
  • make decisions
    • technical leaders must be prepared to make the final call and own the outcome
    • be honest with yourself when you consider trade-offs.
    • owning decisions includes accepting that you might be wrong. Make the cost of a wrong decision as low as possible
  • ask “obvious” questions
    • as a leader you have a responsibility to make the implicit explicit
    • if an expert asks, and team members learn that they should include explicit answers to these questions in their design documentation. Juniors asking these questions could be downplayed.
  • don’t delegate through neglect
    • recognize the glue work and understand who’s doing it.
    • promotion committees might consider this leadership work when a staff engineer does it but ignore it when a junior does
• take charge
  • step up in an emergency
    • everything goes better when someone is coordinating. But coordinating only works if everyone knows you are coordinating
    • check: Incident Command System
    • take clear notes, make sure everyone involved has the same context, and ask everyone to radiate intent
  • ask for more information when everyone is confused
    • someone needs to be brave enough to say “I don’t know what to do with the information you just gave me”
    • it’s safer for senior people to ask
    • avoid “feigned surprise” – a reference to BOFH, and the question e.g. “You’ve seriously never used Linux?”
  • Drive meetings
    • if the meeting doesn’t have notes, was it really worth getting together?
    • if a senior person takes notes they’re making sure the meeting is effective. When junior is, it’s considered low-status administrative work.
    • when taking notes, be the first to frame the decision. Then you can invite everyone to confirm what you wrote
  • if you see something, say something
    • reacting to someone saying something inappropriate
    • while it’s suggested to praise in public and criticize in private, here it’s important to say something in public. If someone is attacked in front of a group, you need to support them in front of the same group
    • describe the culture you’re aiming to build
    • give the person a path to being on the same side as you e.g. “I get using humor in hard situations but let’s be mindful that people in this meeting might be affected by what’s going on”
    • if it’s a private conversation you can refer to the person’s values
• create calm
  • defuse, don’t amplify
    • even just seeing that you have the same information and don’t seem to be panicking can help reduce anxiety
    • a senior person making a fuss can blow up a minor thing to a big issue. If your actions will amplify rather than calm down, consider staying out. Especially if this side quest is not the right use of your time
    • be clear about why you’re telling something to your leader. They can also reflexively react.
  • avoid blame
    • a big outage is an expensive training course so better learn something
  • be consistent
    • create a sense of safety and calm by being consistent and predictable
    • yes, change can be scary, but they can rely on you to stay while you all work through it

Remember the goal

• remember there’s a business
  • adapt to the situation
    • you don’t have to write tests on hackathon. Sometimes it’s better to have shitty code than to be late, sometimes maintainability is important
    • if you resent change, you’ll spend your time being unhappy
  • be aware that there’s a budget
  • spend resources mindfully
    • staffing a project has an opportunity cost
• remember there’s a user
• remember there’s a team
  • don’t become a single point of failure where the team can’t get anything done when you’re not available

Look ahead

• anticipate what you’ll wish you’d done
  • telegraph what’s coming
    • even if you haven’t started the migration yet because the new system isn’t fully ready, you can announce the intention to deprecate the old one. People would know not to invest in the old system
  • tidy up
    • make it easier and safer to work. No dangerous scripts that you have to remember not to run, no local config
  • keep your tools sharp
    • improve the tools. Smaller builds, intuitive tooling, fixing or deleting flaky tests, repeatable processes, automation.
  • create institutional memory
    • keep the knowledge even if people leave.
    • decision records that explain what you were thinking, system diagrams that document obvious things that “everyone knows”, and code comments that include context on what’s going on.
    • include searchable keywords.
• expect failure
  • you can’t predict everything that will go wrong, but you can predict that something will go wrong. Plan for what you’ll do when it does
  • if you haven’t tested restoring backups assume you have no backups
• optimize for maintenance, not creation
  • you may need to touch code you didn’t plan for example due to external reasons like regulations (e.g. GDPR)
  • make it understandable
    • at the moment of creating new code, you have the best understanding. It decays over time. If it’s hard to understand now, good luck in 2 years when something breaks
  • keep it simple
    • “any fool can write code that a computer can understand. Good programmers write code that humans understand“
    • when you think of a solution, treat it as “just the first”. Then spend the same time coming with other ideas. See if you can make it simpler
  • build to decommission
    • imagine knowing that you personally will need to decommission this component in 10 years. Future You won’t be any less busy than Present You.
    • clean interfaces help, knowing which components use this component.
• create future leaders
  • the metric for success is whether other people want to work with you
  • juniors now will be seniors one day

8. Good influence at scale

Good influence

• If you can help your colleagues become better engineers, you’ll be working with more competent people, which means your own work will be easier (and less annoying)
• you learn how to teach. And the industry constantly changes

3 levels of influence: individual, group and catalyst (outside your direct influence)

—	Individual	Group	Catalyst
Advice	Mentoring, sharing knowledge, feedback	Tech talks, documentation, articles	Mentorship program, tech talk events
Teaching	Code review, design review, coaching, pairing, shadowing	Classes, codelabs	Onboarding curriculum, teaching people to teach
Guardrails	Code review, change review, design review	Processes, linters, style guides	Frameworks, culture change
Opportunity	Delegating, sponsorship, cheerleading, ongoing support	Sharing the spotlight, empowering your team	Creating a culture of opportunity, watching with pride as your superstar junior colleagues change the world

Advice

• who asked you?
  • if you’re not sure whether your advice will be welcome, ask them
  • places where unsolicited advice might be helpful
    • when you think the person is in a situation they can’t see out of e.g. working in an unhealthy culture
    • when you have key information the other person doesn’t have e.g. when you know some system they want to use will be taken down

individual

• mentorship
  • advice that might work for one person may not work for others. E.g. for underrepresented groups. Or “best practices” from a decade ago offered to a younger coworker
  • even if it feels intuitive to tell what you would do in a situation it may be kinder to figure out what the person actually needs. Maybe they’re just looking for reassurance that it’s indeed a difficult problem.
  • set expectations e.g. meeting once a week
  • agree on what you’re trying to achieve e.g. feel comfortable in a new company, learn a new codebase, get career advice?
• answering questions
  • if you’re not sure, ask what your colleague is trying to do, and ask if they need help.
  • be clear whether you’re just sharing information or asking them to change course. For example, avoid leaving a comment “The library X would also work here” without giving context on what exactly you expect from them
  • if you’ve learned ways to navigate your organization and get things done, that’s valuable knowledge too.
• feedback
  • sharing constructive feedback is difficult, but it won’t help your colleague if you hide the truth
• peer reviews
  • “what could do the person do better” – take the question literally. How could they become more awesome? If you can’t think of anything, ask yourself, why they aren’t one level more senior?
  • but also remember that the feedback will be read by the person’s manager
  • if you don’t want to accidentally break someone’s path to promotion, consider private feedback via DM
  • be aware that describing the same behavior across different people can be understood differently. Was it “consensus building” or “indecisiveness”?

group advice

• example: Google’s “testing on the toilet“
• if you want to tell something to more people, write it down
• look for opportunities to get a microphone and an audience. Sometimes it can be powerful to back up your message with a good story e.g. establishing practices about dependency management with a talk about an outage.

being a catalyst

• set up advice flows that don’t need you to be involved
• look for a small but meaningful change e.g. a culture of documenting new solutions
• you can set up monthly tech talks or lunch-and-learn meetings
• you can scale mentorship further by setting up a mentorship program
  • the administrative work is time-consuming
  • convincing someone to set up a mentorship program still counts as being a catalyst

Teaching

The difference between telling people things and teaching them is understanding. When you’re teaching, you’re trying to have the other person not just receive the information but internalize for themselves

individual teaching

• unlocking a topic
  • great classes “unlock” a topic for you, sparking curiosity and interest
  • have a lesson plan and a specific goal
  • the student should be doing as well as listening
• pairing, shadowing, reverse shadowing
  • you execute, they shadow
  • pairing, you lead,
  • pairing, no leader or equal time leading
  • pairing, they lead
  • they execute, you reverse shadow
• code and design review
  • understand the assignment
    • get the context
    • understand the stage of work. If it’s a last review before launch it’s not time for big directional questions
  • explain why as well as what
    • so that in similar situations they know what to apply
  • give an example of what would be better
  • be clear about what matters
    • is it a security risk or a nitpick
  • choose your battles
    • do review in passes. First high-level, then increasing details. If the code is incorrect, it doesn’t make sense to check other things
  • if you mean “yes”, say “yes”
    • explicitly say LGTM on design documents
• coaching
  • mentoring involves sharing your personal experiences, coaching teaches people to solve problems for themselves. It can be a slower process but a person will learn more by making their own connections
  • asking open questions
  • active listening
  • making space
    • silence so that they can process
    • in the beginning, it feels strange to not just help

group

• codelabs are a good example of asynchronous classes
• example story – applicable to projects with big rotation and short tenure – e.g on day one add a joke to the repository of jokes to see how the PR process works

catalyst

• teach others how to teach. Let them develop their own style

Guardrails

individual

• code, design, change review
  • change review is like code review but for command lines, click buttons in the right order
  • if you want to be a good guardrail don’t rubber stamp changes. Read them carefully.
  • categories of problems you should look for:
    • should this work exist? – do you need a technical solution for it
    • does this work actually solve the problem?
    • how will it handle failure?
    • is it understandable?
    • does it fit into the bigger picture?
    • do the right people know about it?
• project guardrails
  • it’s nice to have someone who has done such a project in the past. They won’t do the work for you but will protect you from mistakes before you notice them.
  • they can help by asking the right question at the right moment: e.g. “how were you planning to balance these two conflicting business priorities”
  • be specific about how you can help with the project e.g. doing the reviews of nudging people when they don’t respond

group

• processes
  • examples where the process or checklist may be helpful
    • outage or security incident
    • RFCs or designs
    • adopting new technology or language
    • making and recording decisions that cross multiple organizations
  • be clear (e.g. writing a process preamble) that the process attempts to give mostly correct answers but they will not apply perfectly in every situation. Think twice before discarding them, but if they don’t make sense do what does. All guidelines are wrong sometimes. But if they are wrong a lot suggest a change
• written decisions
  • style guide
  • paved roads
    • e.g. technology radar
  • policies
    • use them sparingly. It’s hard to account for all edge cases. And if there are too many people won’t remember
  • technical vision and strategy
• robots and reminders
  • maybe you can put process steps in people’s faces in the right moment
  • automated reminders
  • linters
  • search
    • update old documents to point to the right one
  • document templates
  • config checkers and presubmits

catalyst

• culture change takes time
• solve a real problem
  • expect “why” questions. Have a good answer that’s not just aspirational – what the business gets out of it
• choose your battles
  • rather than a process for design review try to instill a respect for design review
• offer support
• Find allies

Opportunity

individual

• delegation
  • give them a messy, unscoped project with a bit of a safety net
  • try to find someone who will find the work a bit of a stretch but manageable with support. Promise them that support
  • inevitably the person you’ve delegated to is going to take a different approach. But a guardrail, coach them, ask questions but don’t step in
  • you should be redirecting questions, not proxying so that people know who’s the real point of contact
• sponsorship
  • ABCD of sponsorship:
    • amplifying – promote good work so that others know about their accomplishments
    • boosting – recommend opportunities and endorse their skills
    • connecting – bring them into a network
    • defending – stand up for them when unfairly criticized
  • you’re spending social capital by recommending so don’t waste on people who don’t want the opportunity or won’t put the effort
• connecting people

group

• share the spotlight
  • if someone asks a question in a group meeting, leave a gap or explicitly hand off the floor to another person on your team
  • add a less senior colleague to a meeting you go to, and let them speak about their work
  • invite a less senior colleague to review designs or code that connects to their work, and be clear their opinion matters
  • don’t be extreme, don’t delegate everything. Most managers expect some visible accomplishments from staff engineers

catalyst

• look for ways you can teach your colleagues to look beyond the obvious candidates to suggest opportunities
• if you can delegate, you’ll be able to take responsibility for even bigger problems

9. What’s next?

Your career

what’s important to you?

• being financially secure
• supporting your family
• having a flexible schedule
• learning a lot
• being visible
• doing cool things
• challenging yourself
• building wealth
• working for yourself
• making a difference
• enabling your vocation/passion
• making friends
• traveling the world
• taking care of your health

where are you going?

Your career is like a trail map. If you’ve got a faraway goal, plot some steps that will take you closer. Where do you see yourself in 5 years? What do you need to do now to be there?

If you base it only on your own experience you won’t be able to find the non-obvious path, and the trails will be limited to what you can see from where you stand.

what do you need to invest in?

• building skills
  • it’s like spending points in a game.
  • you should put points into what you want to be good at
  • having a sustainable career means managing energy. You’re going to learn the whole life. Make sure you know yourself and what makes you happy and spend time mostly doing just that
  • take comfort in the fact that it’s common, even at this level, to feel the impostor syndrome. Find opportunities to put ability points into something that makes you nervous, and show yourself it’s a learnable skill.
• building network
  • https://www.scienceofpeople.com/networking/
  • most of the jobs positions above senior are filled with people from the network
• building visibility
  • let people see you solving problems, asking insightful questions, showing up with a clear strategy when there’s chaos, and they’re more likely to think of you when an opportunity arises
  • don’t waste the opportunities. If you get a talk at a conference, prepare for the talk
• choosing roles and projects deliberately
  • you’ll get better at whatever you spend time on. In fact it’s easy to gain a specialty accidentally just because it’s what you’re doing at work.
  • so choose roles that will give you the experiences you want to have

Your current role

five metrics to keep an eye on

You can have a matrix and update regularly to avoid recency bias and be alerted when your metrics are going down

• are you learning/growing?
  • 0: stagnant
  • 5: rocketship growth
• are you learning transferable skills or just how to cope with your organization dysfunction?
  • 0: learning to cope in this org
  • 5: learning transferable skills
• how do you feel about recruiting friends to your company?
  • 0: morally conflicted
  • 5: widly enthusiastic
• how’s your confidence and how capable you feel?
  • 0: confidence being eroded
  • 5: confidence growing
• is your job physically good for you?
  • 0: stress, stress, stress
  • 5: feeling healthy

If things stayed exactly like they are would you stay another month? 6 months? Year? 5 years? How long?

can you get what you want from your role?

Do the evaluation:

• what’s great as it is?
• what do I wish were different?

It’s not possible to achieve all goals because they often stay in the tension (e.g. earning money vs doing good)

should you change jobs?

• reasons to stay in the same role or company
  • feedback loops – you see the consequences of your decisions
  • depth – you learn the domain and work faster
  • relationship
  • context – you know how to navigate the organization, know the OKR process, shadow org chart
  • familiarity – you know the work, schedule, people
• reasons to move
  • employability – when you don’t learn transferable skills
  • experiences
  • growth
  • money
  • mismatch – not all growth paths exist in all companies

Paths from here

keep doing what you’re doing

If you get what you need from your current position, you still learn it’s fine to stay. There is pressure in the industry to keep changing jobs.

You may also want to do what you do until you retire. It’s also fine. Be wary though that the industry changes so try to keep up at least

work toward promotion

Being promoted feels nice. But unpack that feeling. Is it really about the level, or are you actually looking for cash, prestige, interesting challenges, broader scope, respect, getting in “the room”, and a sense of progression?

Understand what promotion means at your company

work less

The most frequent choice is 80% work schedule.

Be cautious about not working full time anyway just to keep up with work, and doing unpaid overtime.

Also, be deliberate about which hours you cut. Meetings, focus time?

Your team may not be happy because they get less of you, but do not get a new headcount.

change teams

It’s like playing a game from the beginning. You know the game, you just start with a fresh character.

You may also bring perspective because you know how to the team is perceived from the outside

build new specialty

You may learn something adjacent to what you already know. The greatest innovation happens at the boundaries of two professions.

explore

In bigger companies, you can change teams temporarily to see what works best for you. R&D? Product team? SRE?

take a management role

Charity Majors: the engineer/manager pendulum. Every few years you can switch between these two. So you are an IC with a management perspective and a manager with hands-on experience who’s been in the trenches.

Management shouldn’t be considered a promotion. Rather change of profession.

take on reports for the first time

If a future goal requires you to have management experience, you’ll eventually need to start building that skill set.

If you’re at a company where decision-making and context only come to folks on the manager track, you might decide that the management track will give you more leverage to get projects done.

If you’re at the top of your career ladder and are interested in the business problems of the next level up

Just as having been a software engineer helps to be better at managing software engineers, having been a line manager helps to be better at managing other managers.

“If you’re a manager, your job is to get better at management. Don’t try to cling to your former glory”.

Charity Majors: going into management requires you to be prepared to commit to at least 2 years of experiment.

find or invent your own niche

The more senior you get, the more likely you are to be looking for a role that needs your specific skills, rather than shaping yourself to fit a generic role.

“Career comes in two phases: first learning what your strengths are, and then finding holes that are shaped like you”

Beware of the roles that are at the intersection of things you are good at and you hate.

Sometimes you may simply ask to create a new role for you.

do the same job for a different employer

Picking the opposite of what is currently making you miserable won’t lead to happiness, it just helps you get out of a bad situation.

Ask many questions at the interview because the staff role is unclear and each manager has different assumptions

change employers and go level up

sometimes the only way to go level up is to change companies. It could be because your company is not growing that fast, and doesn’t need more senior leaders.

Changing companies and going up a level is usually easier if you’re already an expert in the new company’s domain.

Be careful that each company can have different ranks for the same role. See levels.fyi.

change employers and go level down

if you think about your path only in terms of EVERYTHING improving or increasing, you’re going to limit your options.

set up your own startup

it makes sense to have some financial safety net before doing it.

go independent

Consulting, contracting, indie app development, training, and other part-time work.

Working independently benefits from a strong preexisting network.

Marketing is a constant. You have to give talks and be active on social media so people can find you.

Consulting is not for everyone. It’s a big switch (different skills are needed, finding clients, etc), and it’s not as glamorous as many find it (usually less money than a stable FAANG job, more stress)

Being independent means you’ll be missing many of the support structures you might have expected in other roles.

change careers

You can try to bring your technical experience and background to solving a different kind of problem. E.g. shift into education, academia, policy, and research.

Prepare to reset

If you move to another job be prepared to be a beginner again.

You’ll need to “sketch new maps”.

Don’t try to do a new job using the rules of the previous one.

• Take the time to talk with as many people as you can.
• figure out
  • how to get connected
  • how to know things
  • how to be in the right rooms
• learn the shadow org chart
• solve some problems but be humble and assume there were good reasons for previous technical decisions
• figure out how to level up engineers around you
• understand what’s important
• enjoy relatively quiet time for a while before your calendar fills up with meetings

Your choices matter

Take the software seriously. It affects people’s lives. Crashing apps can waste time and cause stress. Abuse of social networks, leaks of private info, and deliberately addictive apps destroy people’s lives