Read next section: Topographical map (Staff Engineer’s Path)
Wait to do this for a month or two. I’m not at a senior/staff level yet and I can benefit from more execution-focused efforts right now.
Summary
Pillars
- Big-picture thinking (Staff Engineer’s Path)
- Execution (Staff Engineer’s Path)
- Leveling up (Staff Engineer’s Path)
Thoughts
Notes
Foreword
One of the core challenges of the staff+ engineering path is the unspoken expectation that part of being qualified to be on that path is figuring out how to climb it without much in the way of directions. If you were destined to be a staff+ engineer, conventional wisdom argues, you would figure out how to get there yourself. Needless to say, this is a frustrating and bias-ridden approach to career development. As more and more companies realize the need for staff+ engineers, we as an industry cannot afford to maintain a mysticism about the staff+ engineering career path that ignores the underlying skills that lead to successful technical leaders.
Introduction
Two Paths
The staff engineer’s path is a little less defined. While many companies now allow engineers to keep growing in seniority without taking on reports, this “technical track” is still muddy and poorly signposted. Engineers considering this path may have never worked with a staff engineer before, or might have seen such a narrow set of personalities in the role that it seems like unattainable wizardry. (It’s not. It’s all learnable.) The expectations of the job vary across companies, and, even within a company, the criteria for hiring or promoting staff engineers can be vague and not always actionable.
The Pillars of Staff Engineering
I’ll unpack the staff engineer role by looking at what I think of as its three pillars: big-picture thinking, execution of projects, and leveling up the engineers you work with.
Big-picture thinking
Big-picture thinking means being able to step back and take a broader view. It means seeing beyond the immediate details and understanding the context that you’re working in. It also means thinking beyond the current time, whether that means initiating yearlong projects, building software that will be easy to decommission, or predicting what your company will need in three years.
Execution
At the staff level, the projects you take on will become messier and more ambiguous. They’ll involve more people and need more political capital, influence, or culture change to succeed.
Leveling up
Every increase in seniority comes with more responsibility for raising the standards and skills of the engineers within your orbit, whether that’s your local team, colleagues in your organization, or engineers across your whole company or industry. This responsibility will include intentional influence through teaching and mentoring, as well as the accidental influence that comes from being a role model.
[…]
But technical knowledge is not enough. Success and growth at this level means doing more than you can do with technical skills alone. To become adept at big-picture thinking, execute on bigger projects, and level up everyone around you, you’re going to need “humaning” skills, like:
- Communication and leadership
- Navigating complexity
- Putting your work in perspective
- Mentorship, sponsorship, and delegation
- Framing a problem so that other people care about it
- Acting like a leader whether you feel like one or not
And a lot more. Check out Camille Fournier’s article “An Incomplete List of Skills Senior Engineers Need, Beyond Coding” [Camille Fournier | An Incomplete List of Skills Senior Engineers Need, beyond Coding].
[formatting mine]
Part I: The Big Picture
Part II: Execution
Part III: Leveling Up
O’Reilly Online Learning
How to Contact Us
Acknowledgments
I. The Big Picture
1. What Would You Say You Do Here?
What Even Is a Staff Engineer?
Why Do We Need Engineers Who Can See the Big Picture?
Staff+ engineers play the role of a gardener; resisting Moloch within the business.
Why Do We Need Engineers Who Lead Projects That Cross Multiple Teams?
Team boundaries are a Lagging indicator of the needs of a project. Crossing team boundaries is necessary in practice to accomplish larger tasks.
- Why Do We Need Engineers Who Are a Good Influence?
Enough Philosophy. What’s My Job?
You’re Not a Manager, but You Are a Leader
First things first: staff engineering is a leadership role. […] Whenever there’s a feeling of “someone should do something here,” there’s a reasonable chance that the someone is you.
[…]
As your compensation increases and your time becomes more and more expensive, the work you do is expected to be more valuable and have a greater impact. Your technical judgment will need to include the reality of the business and whether any given project is worth doing at all. As you increase in seniority, you’ll take on bigger projects, projects that can’t succeed without collaboration, communication, and alignment; your brilliant solutions are just going to cause you frustration if you can’t convince the other people on the team that yours is the right path to take. And whether you want to or not, you’ll be a role model: other engineers will look to those with the big job titles to understand how to behave. […]
Leadership comes in lots of forms that you might not immediately recognize as such [TODO: LINK]. It can come from designing “happy path” solutions that protect other engineers from common mistakes. It can come from reviewing other engineers’ code and designs in a way that improves their confidence and skills, or from highlighting that a design proposal doesn’t meet a genuine business need. Teaching is a form of leadership. Quietly raising everyone’s game is leadership. Setting technical direction is leadership. Finally, there’s having the reputation as a stellar technologist that can inspire other people to buy into your plans just because they trust you.
Create and link to node
Something like: “Senior engineering leadership is indirect”, “Soft leadership” versus “Hard leadership” being the distinction between telling people what to do (hard, direct) and guiding people to take the path you want them to take (soft, indirect). The slow knife penetrates the shield. What would you call that? Guiding somene to make a choice on their own that’s also the choice you want them to make. Either by convincing them directly or by making it the easier path or by aligning Incentives.
You’re in a “Technical” Role
To be a good influence, you need to have high standards for what excellent engineering looks like and model them when you build something [Lead by example]. Your reviews of code or designs should be instructive for your colleagues and should make your codebase or architecture better. When you’re making technical decisions, you need to understand the trade-offs and help other people understand them too. You need to be able to dive into the details where necessary, ask the right questions, and understand the answers. When arguing for a particular course of action, or a particular change in technical culture, you need to know what you’re talking about. So you have to have a solid foundation of technical skills.
This doesn’t necessarily mean you’ll write a lot of code. At this level, your goal is to solve problems efficiently [TODO: LINK], and programming will often not be the best use of your time. It may make more sense for you to take on the design or leadership work that only you can do and let others handle the programming. 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).
Link to reference node
I read something a while back which went “Your job is to Solve the problem” – not to code or fall into a Technologist trap. Try to find that and cite it here.
You Aim to Be Autonomous
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. As Sabrina Leandro, principal engineer at Intercom, asks, “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!”
See Sabrina Leandro | So You’re Staff+ … Now What?.
As a senior person in the organization, it’s likely that you’ll be pulled in many directions. It’s up to you to defend and structure your time.
You Set Technical Direction
As a technical leader, part of a staff engineer’s role is to make sure the organization has a good technical direction. Underlying the product or service your organization provides is a host of technical decisions: your architecture, your storage systems, the tools and frameworks you use, and so on. Whether these decisions are made at a team level or across multiple teams or whole organizations, part of your job is to make sure that they get made, that they get made well, and that they get written down. The job is not to come up with all (or even necessarily any!) of the aspects of the technical direction, but to ensure there is an agreed-upon, well-understood solution that solves the problems it sets out to solve.
You Communicate Often and Well
The more senior you become, the more you will rely on strong communication skills. […] The better you are at being understood, the easier your job will be.
Understanding Your Role
Where in the Organization Do You Sit?
- Reporting “high”
- Reporting “low”
What’s Your Scope?
A scope too broad
If your scope is too broad (or undefined), there are a few possible failure modes:
- Lack of impact
- Becoming a bottleneck
- Decision fatigue
- Missing relationships
A scope too narrow
Beware, too, of scoping yourself too narrowly. […]
- Lack of impact
- Opportunity cost
- Overshadowing other engineers
- Overengineering
What Shape Is Your Role?
- Do you approach things depth-first or breadth-first?
Which of the “four disciplines” do you gravitate toward?
Yonatan Zunger, distinguished engineer at Twitter, describes the four disciplines that are needed in any job in the world:
Core technical skills
Coding, litigation, producing content, cooking— whatever a typical practitioner of the role works on
Product management
Figuring out what needs to be done and why, and maintaining a narrative about that work
Project management
The practicalities of achieving the goal, removing chaos, tracking the tasks, noticing what’s blocked, and making sure it gets unblocked
People management
Turning a group of people into a team, building their skills and careers, mentoring, and dealing with their problems
Zunger notes that the higher your level, the less your mix of these skills corresponds with your job title: “The more senior you get, the more this becomes true, the more and more there is an expectation that you can shift across each of these four kinds of jobs easily and fluidly, and function in all rooms.”
- Read and link to https://oreil.ly/3S9HE (a)
- How much do you want (or need) to code?
- How’s your delayed gratification?
- Are you keeping one foot on the manager track?
- Do any of these archetypes fit you?
What’s Your Primary Focus?
What’s important?
“Your work needs to be important” doesn’t mean you should only work on the fanciest, most glamorous technologies and VP-sponsored initiatives. 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. It might involve gathering data that doesn’t exist, or spelunking through dusty code or documents that haven’t been touched in a decade. There are any number of other grungy tasks that just need to get done. Meaningful work comes in many forms. Know why the problem you’re working on is strategically important—and if it’s not, do something else.
- What needs you?
Aligning on Scope, Shape, and Primary Focus
By now, you should have a pretty clear picture of what the scope of your role is, how it’s shaped, and what you’re working on right now. But are you certain that your picture matches everyone else’s? Your manager’s and colleagues’ expectations may differ wildly from yours on what a staff engineer is, what authority you have to make decisions, and myriad other big questions. If you’re joining a company as a staff engineer, it’s best to get all of this straightened out up front.
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 early if your mental model of the role is the same as everyone else’s. Better now than at performance review time.
Is That Your Job?
Your job is to make your organization successful. You might be a technology expert or a coder or affiliated with a specific team, but ultimately your job is to help your organization achieve its goals. Senior people do a lot of things that are not in their core job description. They can end up doing things that make no sense in anyone’s job description! But if that’s what the project needs to be successful, consider doing it.
To Recap
- Staff engineering roles are ambiguous by definition. It’s up to you to discover and decide what your role is and what it means for you.
- You’re probably not a manager, but you’re in a leadership role.
- You’re also in a role that requires technical judgment and solid technical experience.
- Be clear about your scope: your area of responsibility and influence.
- Your time is finite. Be deliberate about choosing a primary focus that’s important and that isn’t wasting your skills. [see James F. Kile, Donald J. Little, Samir Shah | Busy Person Patterns]
- Align with your management chain. Discuss what you think your job is, see what your manager thinks it is, understand what’s valued and what’s actually useful, and set expectations explicitly. Not all companies need all shapes of staff engineers.
- Your job will be a weird shape sometimes, and that’s OK.
2. Three Maps
Uh, Did Anyone Bring a Map?
Remember that The map is not the territory.
A Locator Map: You Are Here
Locator map (Staff Engineer’s Path)
We’re going to start with your place in the wider organization and company. Last chapter we talked about your scope, but to truly understand that scope, you need to see what’s outside it. What’s along the borders? When you zoom way out, how big is your part of the world compared to everywhere else? Think of it like one of those maps that a news station throws up behind the presenter to remind you where a particular place is, and put it in context.
You need the locator map because it’s tricky to be objective about any work while you’re deep inside it. Unless you can maintain perspective, the concerns and decisions of your local group will feel more important to you than they would if you looked at them on a bigger scale. So we’ll try out some techniques for getting that perspective. You’ll be honest with yourself about which of the projects you care about would actually show up on a big map of the company, and which ones you wouldn’t see unless you zoomed all the way in.
A Topographical Map: Learning the Terrain
Topographical map (Staff Engineer’s Path)
The second map is all about navigating the terrain. If you’re setting off across the landscape, you’ll go further and faster if you have a robust knowledge of what’s ahead. In this section, we’ll look at some of the hazards on the map: the canyons and ridges along the fault lines of your organization, the weird political boundaries in places nobody would predict, and the difficult people everyone’s been going out of their way to avoid. If there’s quicksand ahead, or krakens to be wary of, or an impassable desert full of the sun-bleached skeletons of previous travelers, you’ll want to mark those pretty clearly before you set out on your journey.
Despite the dangers and difficulties, you might find that there are navigable paths already in place. Discovering these paths will include understanding your organization’s “personality” and how your leaders prefer to work, clarifying how decisions are made, and uncovering both the official and the “shadow” organization charts.
A Treasure Map: X Marks the Spot
Treasure map (Staff Engineer’s Path)
The third map has a destination and some points on a trail to get there. It shows where you’re going and lays out some of the stops on the journey.
Clearing the Fog of War
These three maps already exist in your organization; they’re just obscured. When you join a new company, most of the big picture is completely unknown to you. A big part of starting a new job is building context, learning how your new organization works, and uncovering everyone’s goals.
[…]
You’ll be able to clear some parts of the map through everyday learning, but you’ll need to deliberately set out to clear other parts. A core theme of this chapter is how important it is to know things: to have continual context and a sense of what’s going on. Knowing things takes both skill and opportunity, and you might need to work at it for a while before you start seeing what you’re not seeing.
[…]
Why could they see all of these things when I couldn’t? Because they had learned to pay attention and they knew what they were looking for.
Paying attention means being alert to facts that affect your projects or organization. And that means continually sifting information out of the noise around you. If you can train your brain to say “That’s interesting!” and remember facts that you might need later on, you’ll start to add detail to your maps and build skills in synthesizing new information. What sorts of facts are useful? Anything that can help you or others have context for your work, navigate your organization, or progress toward your goals. Here are some examples:
- A company all-hands presentation about an upcoming marketing push might be a hint that huge traffic spikes you’re not ready for are coming your way.
- Your director asks you to take on a project you don’t have time to do, but you know which senior engineers in your organization are ready for opportunities to stretch their skills.
- A shift in corporate priorities could mean a platform you’d considered but backburnered has become an amazing investment.
- Your database just disappeared, and you remember getting an email about network maintenance.
Over time, you’ll get used to how news travels in your org and what you should pay attention to. […] Think of gathering context as a skill to build as part of your job.
The Locator Map: Getting Perspective
See Locator map (Staff Engineer’s Path).
- Read (Larson 2022)
Seeing Bigger
Taking an outsider view
- Read (Na n.d.)
- Escaping the echo chamber
- What’s actually important?
- What do your customers care about?
- Have your problems been solved before?
The Topographical Map: Navigating the Terrain
- Rough Terrain
Understanding Your Organization
What’s the culture?
- Secret or open?
- Oral or written?
- Top-down or bottom-up?
- Fast change or deliberate change?
- Back channels or front doors?
- Allocated or available?
- Liquid or crystallized?
- Power, rules, or mission?
Noticing the points of interest
- Chasms
- Fortresses
- Disputed territory
- Uncrossable deserts
- Paved roads, shortcuts, and long ways around
What Points of Interest Are on Your Map?
- How are decisions made?
- Where is “the room”?
- Asking to join in
- The shadow org chart
- Keeping Your Topographic Map Up to Date
- If the Terrain Is Still Difficult to Navigate, Be a Bridge
The Treasure Map: Remind Me Where We’re Going?
Treasure map (Staff Engineer’s Path)
- Chasing Shiny Things
Taking a Longer View
- Why are you doing whatever you’re doing?
- Sharing the map
- If the Treasure Map Is Still Unclear, It Might Be Time to Draw a New One
Your Personal Journey
To Recap
- Practice the skills of intentionally looking for a bigger picture and seeing what’s happening.
- Understand your work in context: know your customers, talk with peers outside your group, understand your success metrics, and be clear on what’s actually important.
- Know how your organization works and how decisions get made within it.
- Build or discover paths to allow information you need to come to you.
- Be clear about what goals everyone is aiming for.
- Think about your own work and what your journey is.
3. Creating the Big Picture
The Scenario: SockMatcher Needs a Plan
What’s a Vision? What’s a Strategy?
- What’s a Technical Vision?
What’s a Technical Strategy?
- The diagnosis
- Guiding policy
- Coherent actions
- Do You Really Need Vision and Strategy Documents?
The Approach
- Embrace the Boring Ideas
- Join an Expedition in Progress
- Get a Sponsor
- Choose Your Core Group
- Set Scope
- Make Sure It’s Achievable
- Make It Official
The Writing
The Writing Loop
Initial ideas
- What documents already exist?
- What needs to change?
- What’s great as it is?
- What’s important?
- What will Future You wish that Present You had done?
Writing
- Interviews
- Thinking time
Make Decisions
- Trade-offs
- Building consensus
- Not deciding is a decision (just usually not a good one)
- Show your work
Get Aligned and Stay Aligned
- Be reasonable
- Nemawashi
- Work on your story
- Create the Final Draft
The Launch
- Make It Official
- Keep It Fresh
Case Study: SockMatcher
Approach
- Why didn’t previous attempts work?
- Sponsorship
- Other engineers
- Scope
The Writing
- Diagnosis
- Guiding policy
- Actions
- The Launch
To Recap
II. Execution
4. Finite Time
See James F. Kile, Donald J. Little, Samir Shah | Busy Person Patterns.
Doing All the Things
Time
- Finite Time
- How Busy Do You Like to Be?
- projectqueue.pop()?
Resource Constraints
Your Dashboard
- Energy
- Quality of life
- Credibility
- Social capital
- Skills
- E + 2S + …?
- Bin packing
Choosing Projects
Evaluating a Project
- You’re invited to join
- You ask to join
- You have an idea
- The fire alarm goes off
- You’re claiming a problem
- You’re invited to join a grassroots effort
- Someone needs to…
- You’re just meddling
- What are you signing on for?
Questions to Ask Yourself About Projects
- Energy: How many things are you already doing?
- Energy: Does this kind of work give or take energy?
- Energy: Are you procrastinating?
- Energy: Is this fight worth it?
- Quality of life: Do you enjoy this work?
- Quality of life: How do you feel about the project’s goals?
- Credibility: Does this project use your technical skills?
- Credibility: Does this project show your leadership skills?
- Social capital: Is this the kind of work that your company and your manager expects at your level?
- Social capital: Will this work be respected?
- Social capital: Are you squandering the capital you’ve built?
- Skills: Will this project teach you something you want to learn?
- Skills: Will the people around you raise your game?
What If It’s the Wrong Project?
- Do it anyway?
- Compensate for the project
- Let others lead
- Resize the project
- Just don’t do it
Examples
- Example: Speaking at the all-hands meeting
- Example: Joining an on-call rotation
- Example: The exciting project you wish you could do
- Example: I want to want to
- Defend Your Time
To Recap
5. Leading Big Projects
The Life of a Project
The Start of a Project
If You’re Feeling Overwhelmed…
- Create an anchor for yourself
- Talk to your project sponsor
- Decide who gets your uncertainty
- Give yourself a win
- Use your strengths
Building Context
- Goals
- Customer needs
- Success metrics
- Sponsors, stakeholders, and customers
- Fixed constraints
- Risks
- History
- Team
Giving Your Project Structure
- Defining roles
- Recruiting people
- Agreeing on scope
- Estimating time
- Agreeing on logistics
- Having a kickoff meeting
Driving the Project
Exploring
- What are the important aspects of the project?
- What possible approaches can you take?
Clarifying
- Mental models
- Naming
- Pictures and graphs
Designing
- Why share designs?
- RFC templates
What goes in an RFC?
- Context
- Goals
- Design
- Security/privacy/compliance
- Alternatives considered/prior art
- Background
- Trade-offs
- Risks
- Dependencies
- Operations
Technical pitfalls
- It’s a brand-new problem (but it isn’t)
- This looks easy!
- Building for the present
- Building for the distant, distant future
- Every user just needs to…
- 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?
- Discussing the smallest decisions the most
Coding
- Should you code on the project?
- Be an exemplar, but not a bottleneck
Communicating
- Talking to each other
- Sharing status
- Navigating
To Recap
6. Why Have We Stopped?
The Project Isn’t Moving—Should It Be?
- You’re Stuck in Traffic
Blocked by Another Team
- What’s going on?
Navigating the dependency
- Understand and explain
- Make the work easier
- Get organizational support
- Make alternative plans
Blocked by a Decision
- What’s going on?
Navigating the unmade decision
- Understand and explain
- Make the work easier
- Get organizational support
- Make alternative plans
Blocked by a Single $%@$% Button Click
- What’s going on?
Navigating the unclicked button
- Understand and explain
- Make the work easier
- Get organizational support
- Make alternative plans
Blocked by a Single Person
- What’s going on?
Navigating a colleague who isn’t doing the work
- Understand and explain
- Make the work easier
- Get organizational support
Blocked by Unassigned Work
- What’s going on?
Navigating the unassigned work
- Understand and explain
- Make the work easier
- Get organizational support
- Make alternative plans
Blocked by a Huge Crowd of People
- What’s going on?
Navigating the half-finished migration
- Understand and explain
- Make the work easier
- Get organizational support
- Make alternative plans
You’re Lost
You Don’t Know Where You’re All Going
- What’s going on?
Choosing a destination
- Clarify roles
- Choose a strategy
- Choose a problem
- Choose a stakeholder
You Don’t Know How to Get There
- What’s going on?
Finding the way
- Articulate the problem
- Revisit your assumptions
- Give it time
- Increase your capacity
- Look for prior art
- Learn from other people
- Try a different angle
- Start smaller
- Ask for help
You Don’t Know Where You Stand
- What’s going on?
Getting back on solid ground
- Clarify organizational support
- Clarify roles
- Ask for what you need
- Refuel
You Have Arrived…Somewhere?
But It’s Code Complete!
- What’s going on?
Making sure the user can catch a Pokémon
- Define “done”
- Be your own user
- Celebrate landings, not launches
It’s Done but Nobody Is Using It
- What’s going on?
- Selling it
- Tell people
- Make it discoverable
It’s Built on a Shaky Foundation
- What’s going on?
- Shoring up the foundations
- Set a culture of quality
- Make the foundational work a user story
- Negotiate for engineer-led time
The Project Just Stops Here
- This is a better place to stop
- It’s not the right journey to take
- The project has been canceled
- This is the destination!
To Recap
III. Leveling Up
7. You’re a Role Model Now (Sorry)
What Does It Mean to Do a Good Job?
- Values Are What You Do
- But I Don’t Want to Be a Role Model!
What Does It Mean to Do a Good Job as a Senior Engineer?
- Be Competent
Know Things
- Build experience
- Build domain knowledge
- Stay up to date
Be Self-Aware
- Admit what you know
- Admit what you don’t know
- Understand your own context
Have High Standards
- Seek out constructive criticism
- Own your mistakes
- Be reliable
- Be Responsible
Take Ownership
- Make decisions
- Ask “obvious” questions
- Don’t delegate through neglect
Take Charge
- Step up in an emergency
- Ask for more information when everyone is confused
- Drive meetings
- If you see something, say something
Create Calm
- Defuse, don’t amplify
- Avoid blame
- Be consistent
Remember the Goal
Remember There’s a Business
- Adapt to the situation
- Be aware that there’s a budget
- Spend resources mindfully
Remember There’s a User
Remember There’s a Team
Look Ahead
Anticipate What You’ll Wish You’d Done
- Telegraph what’s coming
- Tidy up
- Keep your tools sharp
- Create institutional memory
- Expect Failure
Optimize for Maintenance, Not Creation
- Make it understandable
- Keep it simple
- Build to decommission
- Create Future Leaders
To Recap
8. Good Influence at Scale
Good Influence
- Scaling Your Good Influence
Advice
Individual Advice
- Mentorship
- Answering questions
- Feedback
- Peer reviews
Scaling Your Advice to a Group
- Being a Catalyst
Teaching
Individual Teaching
- Unlocking a topic
- Pairing, shadowing, and reverse shadowing
Code and design review
- Understand the assignment
- Explain why as well as what
- Give an example of what would be better
- Be clear about what matters
- Choose your battles
- If you mean “yes,” say “yes”
Coaching
- Asking open questions
- Active listening
- Making space
- Scaling Your Teaching to a Group
- Being a Catalyst
Guardrails
Individual Guardrails
- Code, design, and change review
- Project guardrails
Scaling Your Guardrails to a Group
- Processes
Written decisions
- Style guides
- Paved roads
- Policies
- Technical vision and strategy
Robots and reminders
- Automated reminders
- Linters
- Search
- Templates
- Config checkers and presubmits
Being a Catalyst
- Solve a real problem
- Choose your battles
- Offer support
- Find allies
Opportunity
Individual Opportunities
- Delegation
- Sponsorship
- Connecting people
Scaling Your Opportunities to a Group
- Share the spotlight
- Being a Catalyst
To Recap
9. What’s Next?
Your Career
- What’s Important to You?
- Where Are You Going?
What Do You Need to Invest In?
- Building skills
- Building a network
- Building visibility
- Choosing roles and projects deliberately
Your Current Role
- Five Metrics to Keep an Eye On
- Can You Get What You Want from Your Role?
Should You Change Jobs?
- Reasons to stay in the same role or company
- Reasons to move
Paths from Here
- Keep Doing What You’re Doing
- Work Toward Promotion
- Work Less
- Change Teams
- Build a New Specialty
- Explore
- Take a Management Role
- Take on Reports for the First Time
- Find or Invent Your Own Niche
- Do the Same Job for a Different Employer
- Change Employers and Go Up a Level
- Change Employers and Go Down a Level
- Set Up Your Own Startup
- Go Independent
- Change Careers
- Prepare to Reset