No matter how carefully you overlay teams onto a huge project, some responsibilities end up not being owned by anyone, and others are claimed by two teams.
TPMs make sure the project gets done on time, but staff engineers make sure it’s done with high engineering standards. Staff engineers are responsible for ensuring the resulting systems are robust and fit well with the technology landscape of the company.
Leadership comes in lots of forms that you might not immediately recognize as such. 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. If that sounds like you, then guess what? You’re a leader.
If your scope is too broad (or undefined), there are a few possible failure modes.
Lack of impact
If anything can be your problem, then it’s easy for everything to become your problem, particularly if you’re in an organization with fewer senior people than it needs. There will always be another side quest: in fact, it’s all too easy to create a role that’s entirely side quests, with no real goal at all.9 Beware of spreading yourself too thin. You can end up without a narrative to your work that makes you (and whoever hired you) feel like you achieved something.
Becoming a bottleneck
When there’s a senior person who is seen to do everything, the convention can become that they need to be in the room for every decision. Rather than speeding up your organization, you end up slowing them down because they can’t manage without you.
Decision fatigue
If you escape the trap of trying to do everything, you’ll have the constant cost of deciding which things to do. I’ll talk in Chapter 4 about choosing your work.
Missing relationships
If you’re working with a very broad set of teams, it’s harder to have enough regular contact to build the sorts of friendly relationships that make it easier to get things done (and that make work enjoyable!). Other engineers also lose out: they don’t get the sort of mentorship and support that comes from having a “local” staff engineer involved in their work.
But watch out for the risks of a scope that’s too narrow:
Lack of impact
It’s possible to spend all of your time on something that doesn’t need the expertise and focus of a staff engineer. If you choose to go really deep on a single team or technology, it should be a core component, a mission-critical team, or something else that’s very important to the company.
Opportunity cost
Staff engineers’ skills are usually in high demand. If you’re assigned to a single team, you may not be top of mind for solving a problem elsewhere in the org, or your manager may be unwilling to let you go.
Overshadowing other engineers
A narrow scope can mean that there’s not enough work to keep you busy, and that you may overshadow less experienced people and take learning opportunities away from them. If you always have time to answer all of the questions and take on all of the tricky problems, nobody else gets experience in doing that.
Overengineering
An engineer who’s not busy can be inclined to make work for themselves. When you see a vastly overengineered solution to a straightforward problem, that’s often the work of a staff engineer who should have been assigned to a harder problem.
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
You can use these archetypes as you define the kind of role you have, or would like to have:
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.
Know why the problem you’re working on is strategically important—and if it’s not, do something else.
The work that’s most important will often be the work that nobody else sees.
2. Three Maps
being technically correct about a direction is only the beginning. You need to convince other people too—and you need to convince the right people.
If you do get an invitation, don’t make anyone regret inviting you. Will Larson’s article “Getting in the Room” emphasizes that as well as adding value to the room, you need to reduce the cost of including you: show up prepared, speak concisely, and be a collaborative, low-friction contributor. If you make the room less effective at making decisions or sharing information quickly, you won’t be invited back.
This included reading senior people’s calendars, skimming agendas or notes for meetings you’re not in, and—something that had never occurred to me—looking at the full list of Slack channels sorted by most recently created so you can see what new projects are happening.
Admins are smart, resourceful, and well connected. They know what’s going on, and they tend to be the most fascinating people in the company. Go make friends.
If your scope is too broad (or undefined), there are a few possible failure modes.
Lack of impact
If anything can be your problem, then it’s easy for everything to become your problem, particularly if you’re in an organization with fewer senior people than it needs. There will always be another side quest: in fact, it’s all too easy to create a role that’s entirely side quests, with no real goal at all.9 Beware of spreading yourself too thin. You can end up without a narrative to your work that makes you (and whoever hired you) feel like you achieved something.
Becoming a bottleneck
When there’s a senior person who is seen to do everything, the convention can become that they need to be in the room for every decision. Rather than speeding up your organization, you end up slowing them down because they can’t manage without you.
Decision fatigue
If you escape the trap of trying to do everything, you’ll have the constant cost of deciding which things to do. I’ll talk in Chapter 4 about choosing your work.
Missing relationships
If you’re working with a very broad set of teams, it’s harder to have enough regular contact to build the sorts of friendly relationships that make it easier to get things done (and that make work enjoyable!). Other engineers also lose out: they don’t get the sort of mentorship and support that comes from having a “local” staff engineer involved in their work.
Remember that your goal is to solve the problem, not necessarily to write code to solve it. Take the time to understand what already exists—inside and outside your organization—before building something new.
3. Creating the Big Picture
A technical vision is sometimes called a “north star” or “shining city on the hill.” It doesn’t set out to make all of the decisions, but it should remove sources of conflict or ambiguity and empower everyone to choose their own path while being confident that they’ll end up at the right place.
RESOURCES FOR WRITING A TECHNICAL VISION
If you’re setting out to write a technology vision document, here are some resources I recommend:
Fundamentals of Software Architecture by Mark Richards and Neal Ford (O’Reilly)
Chapter 4 of Making Things Happen by Scott Berkun (O’Reilly)
“How to Set the Technical Direction for Your Team”, by James Hood of Amazon
“Writing Our 3-Year Technical Vision”, by Daniel Micol of Eventbrite
RESOURCES FOR WRITING A TECHNICAL STRATEGY
The canonical book on strategy is Good Strategy/Bad Strategy by Richard Rumelt (Currency). I recommend taking the time to read it if you can. Other great resources include:
“Technical Strategy Power Chords” by Patrick Shields
“Getting to Commitment: Tackling Broad Technical Problems in Large Organizations” by Mattie Toia
“A Survey of Engineering Strategies” by Will Larson
Technology Strategy Patterns by Eben Hewitt (O’Reilly)
Rands Leadership Slack, specifically the channels #technical-strategy and #books-good-strategy-bad-strategy
If everyone can get aligned without the document, you probably don’t need it.
A strategy is a plan of action. It’s how you intend to achieve your goals, navigating past the obstacles you’ll meet along the way. That means understanding where you want to go (this could be the vision we just discussed!) as well as the challenges in your path.
Will Larson adds, “If you can’t resist the urge to include your most brilliant ideas in the process, then you can include them in your prework. Write all of your best ideas in a giant document, delete it, and never mention any of them again. Now…your head is cleared for the work ahead.”
No matter how carefully you overlay teams onto a huge project, some responsibilities end up not being owned by anyone, and others are claimed by two teams.
TPMs make sure the project gets done on time, but staff engineers make sure it’s done with high engineering standards. Staff engineers are responsible for ensuring the resulting systems are robust and fit well with the technology landscape of the company.
Leadership comes in lots of forms that you might not immediately recognize as such. 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. If that sounds like you, then guess what? You’re a leader.
If your scope is too broad (or undefined), there are a few possible failure modes.
Lack of impact
If anything can be your problem, then it’s easy for everything to become your problem, particularly if you’re in an organization with fewer senior people than it needs. There will always be another side quest: in fact, it’s all too easy to create a role that’s entirely side quests, with no real goal at all.9 Beware of spreading yourself too thin. You can end up without a narrative to your work that makes you (and whoever hired you) feel like you achieved something.
Becoming a bottleneck
When there’s a senior person who is seen to do everything, the convention can become that they need to be in the room for every decision. Rather than speeding up your organization, you end up slowing them down because they can’t manage without you.
Decision fatigue
If you escape the trap of trying to do everything, you’ll have the constant cost of deciding which things to do. I’ll talk in Chapter 4 about choosing your work.
Missing relationships
If you’re working with a very broad set of teams, it’s harder to have enough regular contact to build the sorts of friendly relationships that make it easier to get things done (and that make work enjoyable!). Other engineers also lose out: they don’t get the sort of mentorship and support that comes from having a “local” staff engineer involved in their work.
If your scope is too broad (or undefined), there are a few possible failure modes.
Lack of impact
If anything can be your problem, then it’s easy for everything to become your problem, particularly if you’re in an organization with fewer senior people than it needs. There will always be another side quest: in fact, it’s all too easy to create a role that’s entirely side quests, with no real goal at all.9 Beware of spreading yourself too thin. You can end up without a narrative to your work that makes you (and whoever hired you) feel like you achieved something.
Becoming a bottleneck
When there’s a senior person who is seen to do everything, the convention can become that they need to be in the room for every decision. Rather than speeding up your organization, you end up slowing them down because they can’t manage without you.
Decision fatigue
If you escape the trap of trying to do everything, you’ll have the constant cost of deciding which things to do. I’ll talk in Chapter 4 about choosing your work.
Missing relationships
If you’re working with a very broad set of teams, it’s harder to have enough regular contact to build the sorts of friendly relationships that make it easier to get things done (and that make work enjoyable!). Other engineers also lose out: they don’t get the sort of mentorship and support that comes from having a “local” staff engineer involved in their work.
But watch out for the risks of a scope that’s too narrow:
Lack of impact
It’s possible to spend all of your time on something that doesn’t need the expertise and focus of a staff engineer. If you choose to go really deep on a single team or technology, it should be a core component, a mission-critical team, or something else that’s very important to the company.
Opportunity cost
Staff engineers’ skills are usually in high demand. If you’re assigned to a single team, you may not be top of mind for solving a problem elsewhere in the org, or your manager may be unwilling to let you go.
Overshadowing other engineers
A narrow scope can mean that there’s not enough work to keep you busy, and that you may overshadow less experienced people and take learning opportunities away from them. If you always have time to answer all of the questions and take on all of the tricky problems, nobody else gets experience in doing that.
Overengineering
An engineer who’s not busy can be inclined to make work for themselves. When you see a vastly overengineered solution to a straightforward problem, that’s often the work of a staff engineer who should have been assigned to a harder problem.
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
You can use these archetypes as you define the kind of role you have, or would like to have:
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.
Know why the problem you’re working on is strategically important—and if it’s not, do something else.
The work that’s most important will often be the work that nobody else sees.
2. Three Maps
being technically correct about a direction is only the beginning. You need to convince other people too—and you need to convince the right people.
If you do get an invitation, don’t make anyone regret inviting you. Will Larson’s article “Getting in the Room” emphasizes that as well as adding value to the room, you need to reduce the cost of including you: show up prepared, speak concisely, and be a collaborative, low-friction contributor. If you make the room less effective at making decisions or sharing information quickly, you won’t be invited back.
This included reading senior people’s calendars, skimming agendas or notes for meetings you’re not in, and—something that had never occurred to me—looking at the full list of Slack channels sorted by most recently created so you can see what new projects are happening.
Admins are smart, resourceful, and well connected. They know what’s going on, and they tend to be the most fascinating people in the company. Go make friends.
Remember that your goal is to solve the problem, not necessarily to write code to solve it. Take the time to understand what already exists—inside and outside your organization—before building something new.
A technical vision is sometimes called a “north star” or “shining city on the hill.” It doesn’t set out to make all of the decisions, but it should remove sources of conflict or ambiguity and empower everyone to choose their own path while being confident that they’ll end up at the right place.
RESOURCES FOR WRITING A TECHNICAL VISION
If you’re setting out to write a technology vision document, here are some resources I recommend:
Fundamentals of Software Architecture by Mark Richards and Neal Ford (O’Reilly)
Chapter 4 of Making Things Happen by Scott Berkun (O’Reilly)
“How to Set the Technical Direction for Your Team”, by James Hood of Amazon
“Writing Our 3-Year Technical Vision”, by Daniel Micol of Eventbrite
RESOURCES FOR WRITING A TECHNICAL STRATEGY
The canonical book on strategy is Good Strategy/Bad Strategy by Richard Rumelt (Currency). I recommend taking the time to read it if you can. Other great resources include:
“Technical Strategy Power Chords” by Patrick Shields
“Getting to Commitment: Tackling Broad Technical Problems in Large Organizations” by Mattie Toia
“A Survey of Engineering Strategies” by Will Larson
Technology Strategy Patterns by Eben Hewitt (O’Reilly)
Rands Leadership Slack, specifically the channels #technical-strategy and #books-good-strategy-bad-strategy
If everyone can get aligned without the document, you probably don’t need it.
A strategy is a plan of action. It’s how you intend to achieve your goals, navigating past the obstacles you’ll meet along the way. That means understanding where you want to go (this could be the vision we just discussed!) as well as the challenges in your path.
Will Larson adds, “If you can’t resist the urge to include your most brilliant ideas in the process, then you can include them in your prework. Write all of your best ideas in a giant document, delete it, and never mention any of them again. Now…your head is cleared for the work ahead.”
No matter how carefully you overlay teams onto a huge project, some responsibilities end up not being owned by anyone, and others are claimed by two teams.
TPMs make sure the project gets done on time, but staff engineers make sure it’s done with high engineering standards. Staff engineers are responsible for ensuring the resulting systems are robust and fit well with the technology landscape of the company.
Leadership comes in lots of forms that you might not immediately recognize as such. 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. If that sounds like you, then guess what? You’re a leader.
If your scope is too broad (or undefined), there are a few possible failure modes.
Lack of impact
If anything can be your problem, then it’s easy for everything to become your problem, particularly if you’re in an organization with fewer senior people than it needs. There will always be another side quest: in fact, it’s all too easy to create a role that’s entirely side quests, with no real goal at all.9 Beware of spreading yourself too thin. You can end up without a narrative to your work that makes you (and whoever hired you) feel like you achieved something.
Becoming a bottleneck
When there’s a senior person who is seen to do everything, the convention can become that they need to be in the room for every decision. Rather than speeding up your organization, you end up slowing them down because they can’t manage without you.
Decision fatigue
If you escape the trap of trying to do everything, you’ll have the constant cost of deciding which things to do. I’ll talk in Chapter 4 about choosing your work.
Missing relationships
If you’re working with a very broad set of teams, it’s harder to have enough regular contact to build the sorts of friendly relationships that make it easier to get things done (and that make work enjoyable!). Other engineers also lose out: they don’t get the sort of mentorship and support that comes from having a “local” staff engineer involved in their work.
If your scope is too broad (or undefined), there are a few possible failure modes.
Lack of impact
If anything can be your problem, then it’s easy for everything to become your problem, particularly if you’re in an organization with fewer senior people than it needs. There will always be another side quest: in fact, it’s all too easy to create a role that’s entirely side quests, with no real goal at all.9 Beware of spreading yourself too thin. You can end up without a narrative to your work that makes you (and whoever hired you) feel like you achieved something.
Becoming a bottleneck
When there’s a senior person who is seen to do everything, the convention can become that they need to be in the room for every decision. Rather than speeding up your organization, you end up slowing them down because they can’t manage without you.
Decision fatigue
If you escape the trap of trying to do everything, you’ll have the constant cost of deciding which things to do. I’ll talk in Chapter 4 about choosing your work.
Missing relationships
If you’re working with a very broad set of teams, it’s harder to have enough regular contact to build the sorts of friendly relationships that make it easier to get things done (and that make work enjoyable!). Other engineers also lose out: they don’t get the sort of mentorship and support that comes from having a “local” staff engineer involved in their work.
But watch out for the risks of a scope that’s too narrow:
Lack of impact
It’s possible to spend all of your time on something that doesn’t need the expertise and focus of a staff engineer. If you choose to go really deep on a single team or technology, it should be a core component, a mission-critical team, or something else that’s very important to the company.
Opportunity cost
Staff engineers’ skills are usually in high demand. If you’re assigned to a single team, you may not be top of mind for solving a problem elsewhere in the org, or your manager may be unwilling to let you go.
Overshadowing other engineers
A narrow scope can mean that there’s not enough work to keep you busy, and that you may overshadow less experienced people and take learning opportunities away from them. If you always have time to answer all of the questions and take on all of the tricky problems, nobody else gets experience in doing that.
Overengineering
An engineer who’s not busy can be inclined to make work for themselves. When you see a vastly overengineered solution to a straightforward problem, that’s often the work of a staff engineer who should have been assigned to a harder problem.
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
You can use these archetypes as you define the kind of role you have, or would like to have:
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.
Know why the problem you’re working on is strategically important—and if it’s not, do something else.
The work that’s most important will often be the work that nobody else sees.
2. Three Maps
being technically correct about a direction is only the beginning. You need to convince other people too—and you need to convince the right people.
If you do get an invitation, don’t make anyone regret inviting you. Will Larson’s article “Getting in the Room” emphasizes that as well as adding value to the room, you need to reduce the cost of including you: show up prepared, speak concisely, and be a collaborative, low-friction contributor. If you make the room less effective at making decisions or sharing information quickly, you won’t be invited back.
This included reading senior people’s calendars, skimming agendas or notes for meetings you’re not in, and—something that had never occurred to me—looking at the full list of Slack channels sorted by most recently created so you can see what new projects are happening.
Admins are smart, resourceful, and well connected. They know what’s going on, and they tend to be the most fascinating people in the company. Go make friends.
Remember that your goal is to solve the problem, not necessarily to write code to solve it. Take the time to understand what already exists—inside and outside your organization—before building something new.
A technical vision is sometimes called a “north star” or “shining city on the hill.” It doesn’t set out to make all of the decisions, but it should remove sources of conflict or ambiguity and empower everyone to choose their own path while being confident that they’ll end up at the right place.
RESOURCES FOR WRITING A TECHNICAL VISION
If you’re setting out to write a technology vision document, here are some resources I recommend:
Fundamentals of Software Architecture by Mark Richards and Neal Ford (O’Reilly)
Chapter 4 of Making Things Happen by Scott Berkun (O’Reilly)
“How to Set the Technical Direction for Your Team”, by James Hood of Amazon
“Writing Our 3-Year Technical Vision”, by Daniel Micol of Eventbrite
RESOURCES FOR WRITING A TECHNICAL STRATEGY
The canonical book on strategy is Good Strategy/Bad Strategy by Richard Rumelt (Currency). I recommend taking the time to read it if you can. Other great resources include:
“Technical Strategy Power Chords” by Patrick Shields
“Getting to Commitment: Tackling Broad Technical Problems in Large Organizations” by Mattie Toia
“A Survey of Engineering Strategies” by Will Larson
Technology Strategy Patterns by Eben Hewitt (O’Reilly)
Rands Leadership Slack, specifically the channels #technical-strategy and #books-good-strategy-bad-strategy
If everyone can get aligned without the document, you probably don’t need it.
A strategy is a plan of action. It’s how you intend to achieve your goals, navigating past the obstacles you’ll meet along the way. That means understanding where you want to go (this could be the vision we just discussed!) as well as the challenges in your path.
Will Larson adds, “If you can’t resist the urge to include your most brilliant ideas in the process, then you can include them in your prework. Write all of your best ideas in a giant document, delete it, and never mention any of them again. Now…your head is cleared for the work ahead.”
TPMs make sure the project gets done on time, but staff engineers make sure it’s done with high engineering standards. Staff engineers are responsible for ensuring the resulting systems are robust and fit well with the technology landscape of the company.
Leadership comes in lots of forms that you might not immediately recognize as such. 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. If that sounds like you, then guess what? You’re a leader.
If your scope is too broad (or undefined), there are a few possible failure modes.
Lack of impact
If anything can be your problem, then it’s easy for everything to become your problem, particularly if you’re in an organization with fewer senior people than it needs. There will always be another side quest: in fact, it’s all too easy to create a role that’s entirely side quests, with no real goal at all.9 Beware of spreading yourself too thin. You can end up without a narrative to your work that makes you (and whoever hired you) feel like you achieved something.
Becoming a bottleneck
When there’s a senior person who is seen to do everything, the convention can become that they need to be in the room for every decision. Rather than speeding up your organization, you end up slowing them down because they can’t manage without you.
Decision fatigue
If you escape the trap of trying to do everything, you’ll have the constant cost of deciding which things to do. I’ll talk in Chapter 4 about choosing your work.
Missing relationships
If you’re working with a very broad set of teams, it’s harder to have enough regular contact to build the sorts of friendly relationships that make it easier to get things done (and that make work enjoyable!). Other engineers also lose out: they don’t get the sort of mentorship and support that comes from having a “local” staff engineer involved in their work.
If your scope is too broad (or undefined), there are a few possible failure modes.
Lack of impact
If anything can be your problem, then it’s easy for everything to become your problem, particularly if you’re in an organization with fewer senior people than it needs. There will always be another side quest: in fact, it’s all too easy to create a role that’s entirely side quests, with no real goal at all.9 Beware of spreading yourself too thin. You can end up without a narrative to your work that makes you (and whoever hired you) feel like you achieved something.
Becoming a bottleneck
When there’s a senior person who is seen to do everything, the convention can become that they need to be in the room for every decision. Rather than speeding up your organization, you end up slowing them down because they can’t manage without you.
Decision fatigue
If you escape the trap of trying to do everything, you’ll have the constant cost of deciding which things to do. I’ll talk in Chapter 4 about choosing your work.
Missing relationships
If you’re working with a very broad set of teams, it’s harder to have enough regular contact to build the sorts of friendly relationships that make it easier to get things done (and that make work enjoyable!). Other engineers also lose out: they don’t get the sort of mentorship and support that comes from having a “local” staff engineer involved in their work.
But watch out for the risks of a scope that’s too narrow:
Lack of impact
It’s possible to spend all of your time on something that doesn’t need the expertise and focus of a staff engineer. If you choose to go really deep on a single team or technology, it should be a core component, a mission-critical team, or something else that’s very important to the company.
Opportunity cost
Staff engineers’ skills are usually in high demand. If you’re assigned to a single team, you may not be top of mind for solving a problem elsewhere in the org, or your manager may be unwilling to let you go.
Overshadowing other engineers
A narrow scope can mean that there’s not enough work to keep you busy, and that you may overshadow less experienced people and take learning opportunities away from them. If you always have time to answer all of the questions and take on all of the tricky problems, nobody else gets experience in doing that.
Overengineering
An engineer who’s not busy can be inclined to make work for themselves. When you see a vastly overengineered solution to a straightforward problem, that’s often the work of a staff engineer who should have been assigned to a harder problem.
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
You can use these archetypes as you define the kind of role you have, or would like to have:
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.
Know why the problem you’re working on is strategically important—and if it’s not, do something else.
The work that’s most important will often be the work that nobody else sees.
2. Three Maps
being technically correct about a direction is only the beginning. You need to convince other people too—and you need to convince the right people.
If you do get an invitation, don’t make anyone regret inviting you. Will Larson’s article “Getting in the Room” emphasizes that as well as adding value to the room, you need to reduce the cost of including you: show up prepared, speak concisely, and be a collaborative, low-friction contributor. If you make the room less effective at making decisions or sharing information quickly, you won’t be invited back.
This included reading senior people’s calendars, skimming agendas or notes for meetings you’re not in, and—something that had never occurred to me—looking at the full list of Slack channels sorted by most recently created so you can see what new projects are happening.
Admins are smart, resourceful, and well connected. They know what’s going on, and they tend to be the most fascinating people in the company. Go make friends.
Remember that your goal is to solve the problem, not necessarily to write code to solve it. Take the time to understand what already exists—inside and outside your organization—before building something new.
A technical vision is sometimes called a “north star” or “shining city on the hill.” It doesn’t set out to make all of the decisions, but it should remove sources of conflict or ambiguity and empower everyone to choose their own path while being confident that they’ll end up at the right place.
RESOURCES FOR WRITING A TECHNICAL VISION
If you’re setting out to write a technology vision document, here are some resources I recommend:
Fundamentals of Software Architecture by Mark Richards and Neal Ford (O’Reilly)
Chapter 4 of Making Things Happen by Scott Berkun (O’Reilly)
“How to Set the Technical Direction for Your Team”, by James Hood of Amazon
“Writing Our 3-Year Technical Vision”, by Daniel Micol of Eventbrite
RESOURCES FOR WRITING A TECHNICAL STRATEGY
The canonical book on strategy is Good Strategy/Bad Strategy by Richard Rumelt (Currency). I recommend taking the time to read it if you can. Other great resources include:
“Technical Strategy Power Chords” by Patrick Shields
“Getting to Commitment: Tackling Broad Technical Problems in Large Organizations” by Mattie Toia
“A Survey of Engineering Strategies” by Will Larson
Technology Strategy Patterns by Eben Hewitt (O’Reilly)
Rands Leadership Slack, specifically the channels #technical-strategy and #books-good-strategy-bad-strategy
If everyone can get aligned without the document, you probably don’t need it.
A strategy is a plan of action. It’s how you intend to achieve your goals, navigating past the obstacles you’ll meet along the way. That means understanding where you want to go (this could be the vision we just discussed!) as well as the challenges in your path.
Will Larson adds, “If you can’t resist the urge to include your most brilliant ideas in the process, then you can include them in your prework. Write all of your best ideas in a giant document, delete it, and never mention any of them again. Now…your head is cleared for the work ahead.”
