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.â
