The Single-Threaded Leader (STL) model was born inside Amazon and became foundational to how we scaled and delivered customer-obsessed innovation—especially in the early years of Alexa. I wrote the original doc that helped crystalize the model, and it’s been gratifying to see how the idea has since echoed through other orgs, blog posts, and companies trying to scale impact without scaling chaos
“The best way to fail at inventing something is by making it somebody’s part-time job.”
— Dave Limp
This post is about how I now explain STL to the teams and leaders I coach—and how to apply it to build durable, focused organizations.
What is a Single-Threaded Leader?
A Single-Threaded Leader (STL) is one person—fully dedicated, fully accountable—for solving a specific customer problem over time.
This does not necessarily mean they are a people manager. STLs may have teams reporting to them. Or they may lead via influence. Either way, they are the one person with the long-term mandate to own the problem and deliver results.
They are not part-time. They are not spread across multiple areas. They don’t just “support” the work—they own it, end to end.
What is a Single-Threaded Organization?
A Single-Threaded Organization (STO) is the structural extension of the STL model. It means organizing teams around long-term programs, not around short-term projects, functional silos, or headcount allocations.
A good STO:
- Is aligned to a well-defined scenario area with durable customer value.
- Operates over a time horizon measured in years.
- Enables autonomy and end-to-end ownership for the STL and their team.
In most cases, STOs should align with Programs—large, strategic areas where the organization expects to invest “forever.” Sometimes, an STO may be aligned with a Product, if that product is enduring. But STOs should almost never be built around Projects, which are temporary by nature.
Organize your team for continuity, not convenience.
Why It Works
The STL/STO model works because it optimizes for clarity, focus, and accountability:
- You always know who owns what.
- You reduce dependencies and cross-team friction.
- You build institutional knowledge that compounds over time.
- You structure your org in ways that naturally lead to better, more modular system architectures (Conway’s Law works both ways).
And if you’re in a scaling environment? STL/STO is a force multiplier. It enables faster decision-making and better long-term thinking—at the same time.
Leadership vs. Ownership
The STL model unifies two powerful, often conflicting ideas:
- Ownership means you’re accountable. You’re on the hook for outcomes.
- Leadership means you inspire and influence others to follow.
Too much ownership without leadership = bottlenecks and burnout.
Too much leadership without ownership = fuzzy responsibility and slow progress.
A strong STL embodies both. They lead—often without direct authority—and they own, without excuse.
Tenets of STL/STO Teams
Great tenets are written as if they are already true. These are.
- STLs are single-threaded. Each STL has exactly one long-term problem space they are 100% dedicated to. They are not shared across domains or overloaded with side hustles.
- STOs are organized around Programs. STO teams are aligned to long-term areas of customer value, not short-term projects or matrixed functions.
- Team size is intentionally small. A STO team is small enough to be fed with two pizzas—typically 3 to 8 engineers and no more than ~15 people total. Small teams move faster and make better decisions.
- Org structure matches system architecture. Team boundaries are designed with Conway’s Law in mind, enabling clean interfaces and modular architecture.
- We start with focused engineering effort. We don’t wait for perfect org charts. We start by giving one engineer total focus on a customer problem, and grow the team as needed.
- Engineers are athletic. STO teams require engineers who can work across disciplines—infra, product, design, operations—to solve real problems end to end.
- The STL defines the model. We are not dogmatic about structure or process. Each STL determines the right operating model for the problem space they own.
Whether you’re building a startup or refactoring a massive enterprise org, the STL model forces the conversations that matter:
- Who owns this?
- What problem are we solving?
- What’s getting in the way of focus?
And if you’re a leader trying to scale, ask yourself: Are you designing for coordination… or for ownership?
Want help implementing STL/STO thinking in your org? I’m available for coaching—and my office hours are open.
Appendix: Lexicon
Here’s how I define the terms that underpin effective STL/STO thinking:
- Program – A long-term (measured in years) human effort to deliver customer value in a well-defined scenario area. Programs are generally defined around areas where the company will invest “forever.” For example, a Rocket Engine Program might include reusable engine R&D and associated infrastructure.
- Project – A short-term (measured in days, weeks, or months) effort to deliver something specific. When a project is done, the resources move on. Projects are how we deliver incrementally inside Programs. For example, building a test stand for an engine is a Project inside a larger Program.
- Product – A bundle of functionality delivered to customers as a cohesive whole. Products are launched via Projects, and great ones are often supported long-term by Programs. For example, a 100% reusable launch vehicle is a Product resulting from multiple Projects.
STOs should be built around Programs, sometimes Products, but rarely Projects.
RSS - Posts