If you have a business unit, program, or initiative critical to your company’s success, consider asking the following three questions.
1. Who is the most senior leader working full time on this initiative and no other?
2. Does this leader have the organizational skills and capabilities to make this initiative a reality?
3. Does this leader control the resources necessary to achieve the desired results?
If the answers to these questions are an individual’s name, “Yes,” and “Yes,” then you have a Single Threaded Leader (STL). If any of those answers are “no one,” “no,” or “no,” then you do not.
A Single-Threaded Team (STT) includes everyone who reports directly (or indirectly under certain conditions) to the STL and works on nothing but the initiative.
You’ll notice we did not mention org charts in this definition. That’s deliberate. At Amazon, teams took different approaches to implementing STTs. There are many ways to make it work. Various organizational structures, decision-making workflows, and technology stacks can work. We’ll discuss multiple scenarios below.
Before implementing STTs, Amazon was organized by function. In the early 2000s, we faced new challenges as our business became more complex (multiple products and business units, multiple countries), and the organization achieved scale (exceeding 500 HQ staff). Functional teams (in particular product, design, and engineering) faced the problem of managing resource planning and allocation processes covering each business unit and geography. Jeff and the S-team were also required to continuously review and weigh in on every significant resource contention issue. The result was lots of time spent in meetings debating resources and less time spent designing, building, and shipping products. Worst of all, business unit leaders felt frustrated that they had no control over resources and inputs to grow their business. Jeff coined the phrase “learned helplessness” to describe the resulting mindset and emphasize how corrosive this could be. The STT model answered our challenges with our org chart and planning processes.
STTs were established to a) reduce time spent debating resource allocation, b) increase time spent building, c) provide leaders and their teams with the resources and autonomy to achieve the best outcomes for their business unit, and d) establish clear owners for P&Ls, programs, and products.
STTs are built to increase the speed of execution and capacity for innovation. Since everyone on the STT has the same objective, there is typically less time spent on alignment and coordination. Accountability and ownership are also crystal clear in this model. The STL has the resources, autonomy, and capability to do the job. Hence, they are responsible and accountable for the teams’ successes or setbacks.
Every organizational model has its own set of strengths and weaknesses. Below are the potential risks of STT implementations and what you can do to mitigate those risks and reap the maximum benefit of STTs:
These potential pitfalls can be mitigated but require specific processes to be implemented.
Since STTs are built for speed, a “fire and forget” approach is risky. Before you let the STT run fast, the executive team needs to ensure that they and the STL are aligned on the objectives the team intends to accomplish and the metrics that will be used to measure progress. The STT goals and metrics must also align with the company’s objectives. A formal process should be in place with regular check-ins to make the necessary course corrections.
At Amazon, before an STT was “approved,” the S-team leader or the CEO would meet with the STL and review a narrative document that would describe the specific objectives, initiatives, and input and output metrics that would be used to measure the STT’s progress. They would also discuss and define the areas the STT owned and, just as importantly, those the STT did not own. At the end of this iterative process, everyone was aligned on the team charter, the set of metrics used to evaluate progress, an enumerated list of areas of ownership with clear boundaries, and an understanding of any upstream or downstream areas it would need to work within a loosely coupled fashion. This upfront effort proved beneficial since it created complete alignment and trust between the STT and the executive team from the first day the team was created.
But that step was not sufficient. We needed a process where the executive team could audit whether the STT was on track and, when necessary, assist them in any course correcting. Amazon accomplished this through numerous operating mechanisms. During the annual planning process, each STT would write a detailed operating plan (OP1) in the fall, which was reviewed by the S-Team (executive team reporting to the CEO). All OP1 plans were trued up in January and converted into OP2 plans, which became the plan of record for that calendar year. The most important SMART goals from the various OP2 plans were culled into a list of “S-Team goals.” An STT typically owns one or more of these goals and must review them with the S-Team every quarter. S-Team goals are very Amazonian. However, other tools and processes, such as OKRs, can accomplish the same objectives. Finally, an STT participates in the weekly business review (WBR) and prepares a monthly or quarterly business review (MBR/QBR) with the relevant audience (a VP or SVP). This cadence provides the best balance between achieving alignment, giving the STT the freedom and autonomy to experiment, and ensuring that the company goals are met.
Since STTs are built for speed, a “fire and forget” approach is risky. Before you let the STT run fast, the executive team needs to ensure that they and the STL are aligned on the objectives the team intends to accomplish and the metrics that will be used to measure progress. The STT goals and metrics must also align with the company’s objectives. A formal process should be in place with regular check-ins to make the necessary course corrections.
At Amazon, before an STT was “approved,” the S-team leader or the CEO would meet with the STL and review a narrative document that would describe the specific objectives, initiatives, and input and output metrics that would be used to measure the STT’s progress. They would also discuss and define the areas the STT owned and, just as importantly, those the STT did not own. At the end of this iterative process, everyone was aligned on the team charter, the set of metrics used to evaluate progress, an enumerated list of areas of ownership with clear boundaries, and an understanding of any upstream or downstream areas it would need to work within a loosely coupled fashion. This upfront effort proved beneficial since it created complete alignment and trust between the STT and the executive team from the first day the team was created.
But that step was not sufficient. We needed a process where the executive team could audit whether the STT was on track and, when necessary, assist them in any course correcting. Amazon accomplished this through numerous operating mechanisms. During the annual planning process, each STT would write a detailed operating plan (OP1) in the fall, which was reviewed by the S-Team (executive team reporting to the CEO). All OP1 plans were trued up in January and converted into OP2 plans, which became the plan of record for that calendar year. The most important SMART goals from the various OP2 plans were culled into a list of “S-Team goals.” An STT typically owns one or more of these goals and must review them with the S-Team every quarter. S-Team goals are very Amazonian. However, other tools and processes, such as OKRs, can accomplish the same objectives. Finally, an STT participates in the weekly business review (WBR) and prepares a monthly or quarterly business review (MBR/QBR) with the relevant audience (a VP or SVP). This cadence provides the best balance between achieving alignment, giving the STT the freedom and autonomy to experiment, and ensuring that the company goals are met.
If you ask teams to remove dependencies, act autonomously, and focus on customers, duplication of effort across teams is inevitable. Sometimes, it’s an acceptable tradeoff to make. At Amazon, we were pragmatic; the details matter. In general, we favored the carrot versus stick approach. If the company had an internal service that an STT could use, the “use versus build your own” decision was typically left to the STL. But there were a few cases dealing with security, identity and privacy, for example, where all STTs were mandated to use an existing service.
Let’s take an example of a new Digital STT team that has just started within a company that, up until now, has only shipped physical products. The Digital team wants to start selling digital goods and services quickly. The Digital team needs a payment service so customers can buy digital goods. However, the existing payment system was designed and built to ship physical goods. You typically don’t charge the customer unless you ship them a product. And to ship them a product, you need a physical address. So, the payment service required a shipment record and a legitimate physical shipping address to charge a payment instrument. In the digital world, this model doesn’t make sense. The Digital team was faced with the potential of a significant dependency on the Payments team and wasn’t sure it could deliver the necessary features in an acceptable time frame. Yet building a new digital payment service would also take time to do right. From the point of view of the Payments team, they were being asked to devote significant resources to build functionality that would handle a tiny percentage of their overall transactions. Moreover, the Payments team felt they “owned” all payments at the company and needed to be the stewards of all payment systems to properly manage the company’s risk.
What’s the correct answer? Well, it depends. In this case, the Digital STT decided to build its own payment system, even over the protests of the payments team. Over time, however, as digital sales increased, the payments team eventually created functionality to accommodate the sale of digital goods and subscription products. The Digital STT migrated to this centralized service and got out of the business of building and maintaining a digital goods and subscription payment system. The point here is that you can have two well-intentioned teams trying to do what they both think is right and both trying to execute on their approved charters. In this case, we let the teams try to work together to find a solution, and when they could not, they escalated. One of the critical responsibilities of Executive leaders (VP and above) in an STT model is to review, understand, and help determine the right path when there is a duplication of effort. In this case, we opted for autonomy and speed after we were convinced the Digital STT had the capability and expertise to do the job correctly. Still, there were other cases where we decided to merge efforts.
As you distribute smaller groups of functional expertise across STTs (software engineering or data science, for example), there is a risk that these functional groups become siloed and valuable knowledge and experience isn’t shared across teams. Moreover, you run into the problem on smaller-scale teams where relatively junior individual contributors are still learning and developing their expertise yet they report to someone with different functional expertise.
This risk can be mitigated with some formal and informal processes. At Amazon, we had several functional tech leadership groups, such as Tech VPs, Tech Directors, and Principal Engineers, who would meet regularly. They took it upon themselves to always ask what else is needed to make Amazon the best place in the world to be a software engineer. These informal groups created programs and processes to make that vision a reality. They managed things like job leveling – ensuring what it meant to be an SDE III was the same across the company. When an STL wished to promote someone to a Principal Engineer, Tech Director, or VP, they needed the promotion document to be reviewed by the relevant, centralized promotion review panel whose members were functional experts from around the company.
Finally, we made it easy for individual contributors or managers in functional areas to share what they learned with other teams and learn new technologies. The details of what you do at your company will differ. However, the critical point is to put in place both formal and informal processes and programs to ensure functional (e.g., design, technology, marketing, category management, etc.) best practices continue to thrive even if the organizational chart differs. We found that loosely coupled teams worked far better than 100% independent and separate ones.
How can a software engineer be convinced to work in a group run by a non-technical manager? Or how do you convince a marketing expert to work for someone with a technical background?
Implementing STTs with solid reporting lines may be challenging for smaller organizations. In an organization with ~150 people, a pod-like org chart with dotted lines may be more appropriate. At the beginning of the document, we said that to be an STL, the answer to “Does this leader have the organizational skills and capabilities to make this initiative a reality?” must be “Yes.” Effective STLs are effective general managers. They are comfortable hiring, managing, and growing the careers of subject matter experts beyond their expertise. One of the first things an STL typically does is recruit and hire direct reports who can attract and retain functional talent in areas outside of their expertise. For example, if a VP of Product Management has been recently switched to an STL, one of their first and key hires should be a technical VP or Director who can build out that part of the team.
To successfully implement single-threaded teams in your organization, begin with a pilot program. Select one to three teams ideally led by strong managers and operating in areas with minimal dependencies. That is, choose the easiest cases first. Focus on mastering STT management within this pilot group before scaling the model across your organization. For each area, you need to do the following:
1. Identify the right leader.
2. Create a plan and get aligned with the executive team.
3. Establish executive control and audit processes.
4. Staff the team.
5. Remove dependencies and instrument systems so you can measure progress.
Once the leader has been established, steps 2-4 can happen concurrently (or at least recruit the core STT managers). As discussed above, defining the team’s charter, metrics, initiatives, and boundaries will likely take many iterations. But it’s crucial to gain alignment here so that when the STT starts moving fast, it’s in your desired direction.
The next important step is to identify the dependencies that prevent teams from quickly achieving their goals and then create a plan to remove as many of them as possible. Each dependency creates a situation where an STT member will have to stop working on their primary tasks and figure out how to work with teams that may have different or even conflicting goals. The number and type of dependencies you have as an organization will dictate the pace of progress and what STTs will look like in your company. Here are a few examples.
Dependency | Type | Description |
Database | Technical | Too many services/teams use the same data source |
Code | Technical | Too many services/teams use a code base (free for all, shared libraries, etc.). |
Deployment | Process | Need to wait for the deployment train, which other groups can hold up |
Roadmap roulette | Process | Your team often gets signed up to work on other projects not part of your plan. |
Can’t go it alone | Resource | You need to convince one or more teams to build/do something for your idea to work. |
Approval / Veto Nightmare | Organizational, Process | Need to ask and receive permission from too many people across the org. If just one of them says no, it will effectively kill the idea |
Hurry up and wait | Process | Need to wait too long for the decision-making body to meet just to vet and greenlight the idea |
Misalignment | Process | Business, product, and tech teams are not aligned on what to build and how it should be built. |
Removing dependencies can be frustrating. The initial list of dependencies can be daunting and extensive. Moreover, removing a single dependency often requires significant resources and likely will yield little immediate improvements in the metrics the team is judged on. Yet, each dependency removed means the STT team can move faster. Accrued over time, these benefits do make a material difference.
To conclude, here are a few questions to help you determine the best way to implement STTs in your organization.
The Right Leader – Does the STL have the skills, authority, and capability to build and manage a team to achieve the desired results? (If you have a $1B new product idea, you will need a leader capable of running and building one).
Dependency Elimination – Have you identified and removed enough of your dependencies so your STL and the STT members can spend the bulk (>80%) of their time focused inwardly on successfully delivering their single, major initiative?
Alignment Checks – Are there processes in place to ensure upfront alignment when an STT is created and regular check-ins to ensure the STT’s objectives align with the company objectives?
Countermeasure Processes – We discussed this area in the Pros & Cons section above. As you decentralize certain functions, have you implemented appropriate processes to ensure consistent, high-quality functional expertise across the company?
The Amazon organizational structure varied depending on the point in time and the nature and scale of each business unit. The answer below reflects how we organized in the early 2000s, which is most applicable to growth-stage companies.
Staff and central non-tech functions (Biz Dev & Corp Dev, Finance, Legal, HR) remained functional/vertical. However, it was a matrix where people/resources in most of these functions had a dotted line or supporting relationship with each team. For example, in the Digital STT example above, at least one person in Finance, HR, and Legal was full-time dedicated to the Digital STT. Still, they had a functional manager who was not a member of the STT.
The Engineering org consisted of two types of teams: teams that built and operated core services (e.g., Dev Ops, Search, Payments, Item Master, etc.) and teams that supported a business unit (e.g., Retail, Digital Media, Affiliates, FBA, Advertising, Amazon Fresh, EC2, etc.).
The core services became STTs with a deeply technical STL who was typically a Senior Manager, Director, or VP. Each team had a set of APIs that they solely owned and operated. As the teams grew, they split into different STTs nested under the Tech VP. Each of these teams reported to the CTO or a tech SVP.
The rest of the engineering organization became part of STTs, which owned and operated a line of business. Each of these teams had an STL. The category STLs tended to have a business rather than a technical background. Businesses such as AWS products were often led by STLs who were technical. But there was no hard and fast rule. You want to choose the best leader for the opportunity at hand. Just as with the core services, as the business unit teams grew, they became a collection of smaller STT teams nesting within each STT.
Within a business line STT, those teams were typically organized by function. For example, the VP of Amazon Fresh would have a development manager, product management manager, marketing manager, and logistics manager reporting to them.
At Amazon we would assign STLs based on the scale of opportunity rather than the size of the current team or business. When that STL was successful, though it would take time, they would eventually run a larger business with a more significant impact than their prior role. So, viewed over that timeframe, it was not a demotion.
We recommend starting with a few STTs, ideally in areas with fewer dependencies that can easily be separated.
Get in touch for bulk orders, speaking events or advisory services.
© 2021 Working Backwards LLC. All rights reserved.
See our Privacy Policy and Terms of use