The Single-Threaded Model at Amazon(pedrodelgallego.github.io)
pedrodelgallego.github.io
The Single-Threaded Model at Amazon
https://pedrodelgallego.github.io/blog/amazon/single-threaded-model/
4 comments
This sounds like a great idea at Amazon's current scale, but I struggle to see how this is possible at a company with <20 head count. There are so many different areas that need attention when running a business, and many of them require less than one person's full time.
...Maybe the move is to bring process-driven management to the startup. You outsource all non-core processes, including payroll, benefits, invoicing, accounting, legal, HR, finance, etc. You could then have an eng leader, a product leader, a sales leader, a customer success leader, and a "vision" leader. Sounds like a lot of the VC backed startup world, actually.
...but at that scale, each "single thread" contains multitudes. In "engineering," there's recruiting, mentorship, internal tooling, existing process maintenance, new project scoping & architecture, sprint planning and execution, the list goes on. So the "single-threaded" eng leader is actually multi-threaded across all these different sub-areas.
...Maybe the move is to bring process-driven management to the startup. You outsource all non-core processes, including payroll, benefits, invoicing, accounting, legal, HR, finance, etc. You could then have an eng leader, a product leader, a sales leader, a customer success leader, and a "vision" leader. Sounds like a lot of the VC backed startup world, actually.
...but at that scale, each "single thread" contains multitudes. In "engineering," there's recruiting, mentorship, internal tooling, existing process maintenance, new project scoping & architecture, sprint planning and execution, the list goes on. So the "single-threaded" eng leader is actually multi-threaded across all these different sub-areas.
Author here. Two comments:
1/ As you mentioned, this is not a good approach for start-ups. The single-threaded model keeps teams autonomous and focused by eliminating alignment in big companies. It tries to replicate the nimbleness of start-ups within business units and teams. A startup should already be focused on finding a market fit as fast as possible.
2/ Not everything should be run as single-threaded. For example, AWS sales and support teams run as functional teams because otherwise, it will impact the customer's experience.
A better approach for start-ups and small businesses is using something similar to the Directly Responsible Individuals approach. Its focus is on decision-making ownership and speed. [1]
Thanks for the feedback. I will try to incorporate it into the post.
[1] https://about.gitlab.com/handbook/people-group/directly-resp...
1/ As you mentioned, this is not a good approach for start-ups. The single-threaded model keeps teams autonomous and focused by eliminating alignment in big companies. It tries to replicate the nimbleness of start-ups within business units and teams. A startup should already be focused on finding a market fit as fast as possible.
2/ Not everything should be run as single-threaded. For example, AWS sales and support teams run as functional teams because otherwise, it will impact the customer's experience.
A better approach for start-ups and small businesses is using something similar to the Directly Responsible Individuals approach. Its focus is on decision-making ownership and speed. [1]
Thanks for the feedback. I will try to incorporate it into the post.
[1] https://about.gitlab.com/handbook/people-group/directly-resp...
The single threaded leader is multitasking among their various teams!
Projects are typically organized with cross-functional teams that have to negotiate project requirements, timelines, and produce deliverables in an iterative manner. The idea that you have a single team leader who is responsible for a single thing sounds great -- if that person gets to pick each member of the team and the team is also responsible for that single thing. you are pulling together teams who report to different people/organizations and who probably are themselves assigned to multiple projects.
If the STL doesn't get to pick the team, or if the team isn't also singularly aligned with a single business focus, you have a situation where the person primarily responsible for an initiative is essentially competing with their team for time. And that STL probably is not empowered to demand cycles from their team because the resources are cross-functional and report to other people, so you need to work with your project manager to get more time for your resources. It can be helpful to eliminate a question of who the "product owner" is, but that product owner is likely to be placed in the unenviable position of getting sandwiched between the business leadership demanding results and teams who have shared responsibilities and who don't actually directly report to the STL.
In short -- whether an organization is large or small, this model is a very good way to find scapegoats for when projects go wrong, but success depends on the organization committing people and technology to a problem rather than a single leader.