Coda Hale's "work is work" is my favorite analysis of this topic, because of its focus on axiomatic mathematical upper bounds on productivity and how you can avoid hitting them:
The solution, as mentioned by other comments already, is for leaders to ruthlessly focus on keeping work efforts as independent as possible:
> When presented with a set of problems which grow superlinearly intractable as N increases, our best bet is to keep N small. If the organization’s intent is to increase value delivery by hiring more people, work efforts must be as independent as possible. Leaders should develop practices and processes to ensure that the work efforts which their strategies consider parallel are actually parallel. Shared resources should be continuously managed for contention, and where possible, the resources a group needs should be colocated with that group (e.g., if the work involves a lot of design, staff a designer to that group). Combined arms doctrine isn’t just for soldiers.
> But you will end up with different divisions trying to solve the same problems in ways that either confound each other or the customer.
That's the tradeoff.
You either allow teams to work independently and lose some efficiency through work duplication. Or, you centralize the work and you lose efficiency through centralized bottlenecks.
For small to medium orgs the centralized approach works better. But as the org grows, the bottlenecks become worse and you're forced to switch to the independent approach which is more scalable.
* The guidance is to allow teams to do work independently in parallel, not give them no direction or strategy of what to work on. Without small discreet teams that can operate without a bunch of external blocking approvals or manual processes, you simply will not get work done as the org scales because your productivity will quadratically approach zero.
* He addresses the cost of coherence (both its creation and its absence) in the post, which is worth reading in full. He also talks about how to structure a product portfolio in order to avoid the “confounding competing solutions” scenario.
In short, you’re not wrong, but the downside you outline is tractable—centralization of decision making is not.
Eh, personally I prefer eight rats in a trenchcoat to the kind of sclerotic bureaucracy that seems to dominate most midsized companies. I might be confused about why the rats are doing different things, but at least they're doing things.
Nor is such a company productive when looked at from the outside.
Google might be a good example of this. Each team likely seems productive internally because they come up with new products quickly but customers wonder why the company is producing 4 different chat apps, 3 video services, and nothing seems to work together.
Google's multiple public facing apps that do the same thing are a unique issue. What's not unusual is for a company to have multiple internal tools, vendors, processes that are duplicative.
That becomes a branding issue. Many large companies own many smaller brands that are kept independent. You see this a lot in food also with mobile where each smaller brand can focus a smaller group. This gives customers choice but keeps profits with the entity.
That seems like it would be an alienating environment to work in. I'm much happier working in a collaborative environment instead of one where everyone is just working independently on their own thing.
Factoring work into independent modules that are owned by teams does not preclude active and vigorous collaboration. It just means you don't need a giant list of approvals or manual actions from people all over the company in order to ship something or make a decision.
Modularity is how you escape this and is actually how Apple achieves extreme alignment at massive scale while not completely seizing up.
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.
Alignment is not a technical problem. It is a human issue that can be solved by leadership. Bezos is successful not because of API memo but because of his decision process and leadership.
“Alignment” and certainly leadership isn’t sufficient to prevent a highly complex, highly interdependent system from becoming totally unresolvable, i.e. impossible to work on or within. Amazon could hardly ship software due to complex interdependencies which is why Bezos’ decision process and leadership compelled him to modularize and decouple the various systems and teams. If he hadn’t done that (to greater or lesser degree), it wouldn’t matter how hard he whipped the horses.
I didn’t say Amazon is successful “because” of the API memo nor did I say alignment is a technical problem.
> “Alignment” and certainly leadership isn’t sufficient to prevent a highly complex, highly interdependent system from becoming totally unresolvable, i.e. impossible to work on or within.
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.
Your assumption is that alignment cannot arise out of a natural ecosystem that rewards collaboration between two individuals with no leader, that there must be 'Leadership' orchestrating the ecosystem to be in a state where alignment is possible.
> 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.
I am arguing against people that bring SAFE, microservices, consultants, and architects to solve lack of leadership and alignment. I experienced, first-hand, meetings about the same problem for years, impossible to maintain codebases, millions wasted on idiotic projects without customers and constant carousel of VPs and theirs cronies. While everyone pretend that software development is somehow different, more meritocratic, egalitarian, and somehow we can just “collaborate”.
From what I gathered in an interview once, Apple also tends to prefer autonomy and annual timelines over high frequency sync ups, but I never got far enough to know how far that goes. Actually seems like a dream and I'd love to get another shot at it.
I don’t know in practical terms how Apple does it, I only know that they must do it because otherwise they couldn’t produce an artifact as complex as the iPhone. You can know for a fact they utilize modularity by opening up an iPhone and seeing… modules! A few things to read in the general area of this theory though…
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.
This is a good and detailed post about how apple operates during steve job and tim cool era, along with the difference between apple and other large companies along with cool examples about how it looks in reality from Harvard Business Review [0]
IMO for startups - stay small, stay close, keep the talent density as high as humanly possible - high enough that hiring and firing decisions are painful. Teams of sub 20 people can get a ton done, so try to not grow beyond that until you absolutely have to.
Alignment shouldn't come from a Brownian process of bouncing ideas/progress off everyone and summing the pressures.
Alignment - across an organization, and within divisions and teams - should be something that is thought through very carefully. And not changed lightly. With alignment of smaller groups inheriting the alignment of the larger context by default, with exceptions well considered.
Take input from everyone. But a cohesive shared direction should resist redirection, absent clear reasons to change.
If you walk halfway around the ring and then walk back on the opposite side, you’ve passed everyone. (Of course, there are also other buildings nearby.)
Correction to the correction: it is factorial. Relationships are not limited to two people: observe how easily issues between two people can become a third person's problem.
Say what you will about working from home but my company went almost entirely remote after COVID and I have barely spoken to anyone who isn't on my team in 4 years.
I used to regularly chat up our support, design and production people because we would just happen to be standing near each other waiting for our tea or something. I have to actively seek out that sort of talk now and frankly I'm really shy so that's not going to happen.
We used an app to automatically schedule coffee chats between random people when we went remote. It was a good way to intentionally add back random opportunities for relationship building that were lost in the remote world. Also, we were more intentional about giving time at the beginning of meetings for random chitchat to replace what used to happen as you waited outside a meeting room. They aren't quite the same, but I think they helped.
I cant tell you how many times I got grumbles from CS or a tip of the hat from an accountant that made me go peal back the curtains and find a problem that was bubbling just under the surface.
Boundary conditions are where problems come from. Human signals are a good place to look for those, and people are good at seeing patterns. Yes you get noise in there too, but planing ahead for potential problems means good solutions are quick...
we cant have high functioning teams because ultimately they wont scale. so we have to settle for just not functioning at all, because thats where we're going to end up anyways. right?
As a project grows so does specialization. You can grow the team until it becomes unwieldy, then split it into to around people who are facilitating keeping that culture. It’s helpful to have teams of teams and a few members who transfer between them to both keep the culture from bifurcating and to reduce Us and Them.
This article seems to miss the entire point of alignment: getting everyone to agree on what to work on. Thus, without alignment, your organization might be very productive... but at the wrong things. Which, at its extreme, is essentially the same as 0 productivity. Thus, while yes, increased communications overhead does detract from productivity in the abstract, the real question is: does it detract from productivity on the things the organization should be working on?
https://codahale.com//work-is-work/
The solution, as mentioned by other comments already, is for leaders to ruthlessly focus on keeping work efforts as independent as possible:
> When presented with a set of problems which grow superlinearly intractable as N increases, our best bet is to keep N small. If the organization’s intent is to increase value delivery by hiring more people, work efforts must be as independent as possible. Leaders should develop practices and processes to ensure that the work efforts which their strategies consider parallel are actually parallel. Shared resources should be continuously managed for contention, and where possible, the resources a group needs should be colocated with that group (e.g., if the work involves a lot of design, staff a designer to that group). Combined arms doctrine isn’t just for soldiers.