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.
I help often customers understanding technical debt, and code quality. Most people focus of code metrics, but they tend to forget organizational metrics, and how that impact the software. There are several studies on this. I particularly like one from Microsoft [1].
One of the metrics that I use address your point:
Number of Ex-Engineers (NOEE): This is the total number of unique engineers who have touched a code and have left the company as of the release date of the software system
Implications: This measure deals with knowledge transfer. If
the employee(s) who worked on a piece of code leaves the
company then there is a likelihood that the new person taking
over might not be familiar with the design rationale, the
reasoning behind certain bug fixes, and information about
other stake holders in the code.
A large loss of team members affects the knowledge retention and thus quality.
The Jevons paradox applies to compute. In economics, the Jevons paradox occurs when technological progress increases the efficiency with which a resource is used, but the rate of consumption of that resource rises due to increasing demand.
The more efficient (or cheaper) compute gets the more uses we find for it, rising the consumption of it.
People think about pricing as a zero sum game. In reality, there are very few things in the world that are zero sum games.
It is quite common to get communication wrong, even inside Amazon. It leads to design by committee, slow decision making, and increase team dependencies.
I would love to hear your experience adopting Amazon mechanisms.
Disclaimer: I work at Amazon. I help customers to adopt some of those mechanisms.
Music is a winner-take-all markets. It makes it really hard for new musicians to break in. It also tend to be a sticky market, so those that have several hits remain relevant for a long time. Winner-take-all markets are reinforced by feedback loops.
The Two-pizza team concept is a very small part on how Amazon works. A few others on top of my head.
- Enable high-velocity decision making: Defining clear tenets that act as the north start for decision making at team level, and two-way doors thinking.
- Establish how you measure success, and how does relate to the goals of the organisation.
- Achieve team independency is a key factor, and having strong mechanisms such as the "away teams" concept, "communication is terrible" mental model and reducing cognitive overload by relying on platform teams
- Nominating a single-threaded owner for programs and business outcomes.
- Articulate how the organisation works across teams using mechanisms such as bar raisers, OP1/OP2, PR/FAQs, CoEs, WBRs, experiment-driven teams, ...
If workers unionize right now, then it will probably put the general public opinion against the workers. Specially as the pandemic get its way into the US, and more and more people self quarantine, and start relying in delivery services for all their shopping
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...