You push the points of interaction to very few, very well-managed interfaces and allow modules (teams, services, components) to operate freely within those confines.
Bezos’ famous API memo is another extreme example.
Lex interview with Bezos. https://www.youtube.com/watch?v=DcWqzZ3I2cY
I didn’t say Amazon is successful “because” of the API memo nor did I say alignment is a technical problem.
Yes, but Leadership is a necessary condition for alignment to happen.
> Bezos’ decision process and leadership compelled him to modularize and decouple the various systems and teams
That is the essence of leadership. Make an important decision and have people follow it. If Bezos just made a decision but not enforce it, he would not reach same scale Amazon and created AWS as by product.
> You push the points of interaction to very few, very well-managed interfaces and allow modules (teams, services, components) to operate freely within those confines. > nor did I say alignment is a technical problem.
For me, you suggested technical approaches either via process, organisation, and technology.
Who, then, leads the leader?
> Leadership, both as a research area and as a practical skill, encompasses the ability of an individual, group, or organization to "lead", influence, or guide other individuals, teams, or entire organizations.
Everywhere there is more than one person, there would be an element of leadership where one person would try to influence another.
> Your assumption is that alignment cannot arise out of a natural ecosystem that rewards collaboration between two individuals with no leader
Alignment for me is when people are working toward the same goal. For alignment to happen, you need the individual to agree on a shared goal. You can have a group of people leading each other as long they share a goal.
Effective leadership mean that there are timely decisions made that are communicated and committed to by the group. Everyone involved should know why they are doing something and what is the end state.
Short and highly specific: Bezos’ API memo — https://konghq.com/blog/enterprise/api-mandate
An actual book that’s a bit broader but touches on system coupling/decoupling and is very practical for software people: Wiring the Winning Organization by Gene Kim
An excellent, very approachable primer on the overarching field of thought, which is systems theory, is Donella Meadows’ “Thinking in Systems”
Going back to more of the philosophical foundation (along with other valuable business ethics lessons), you should look into the work of W Edwards Deming and his “System of Profound Knowledge” — sounds pretentious but is EXTREMELY practical. This region of thought forms the basis of e.g. the Toyota Production System
And an absolutely excellent but more academic deep dive into precisely this topic of modularity is Carliss Baldwin’s “Design Rules.” It’s sort of a super-theory of Conway’s Law, but in a book-length argument.
- [0](https://hbr.org/2020/11/how-apple-is-organized-for-innovatio...)