Productivity Versus Alignment | Hacker News Reader

Productivity Versus Alignment

zaxis.page

106 pointshalababalaba59 comments

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:

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.

But you will end up with different divisions trying to solve the same problems in ways that either confound each other or the customer.

Nobody wants to deal with a company that behaves like eight rats in a trenchcoat.

>you will end up with different divisions trying to solve the same problems in ways that either confound each other or the customer.

I'm pretty sure you just described most of the 100 largest consumer products companies, and a good fraction of the Fortune 500.

[0]https://consumergoods.com/top-100-consumer-goods-companies-2...

More like every larger corporation...

If you have non factory assembly line[1] personnel above 1000 chances you have that

[1] physical and direct nature of work sometimes countermands weird multiple solutions

I’m very much describing a Fortune 500 company that nearly went bankrupt due to a combination of this and drinking the Jack Welch Koolaid.

> 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.

A couple things:

* 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.

Interesting how copy-pasting that link leads to the article while cliking it leads to Wikipedia.. reminds me of jwz's site.

Oh dear, he got me.

  <script type="98f4b28488f8bdfd1252d4f9-text/javascript">
    try {
      if (document.referrer) {
        const ref = new URL(document.referrer);
        if (ref.host === 'news.ycombinator.com') {
          window.location.href = 'https://en.wikipedia.org/wiki/Freddy_the_Pig';
        }
      }

      // If you're reading this, you've entirely missed the fucking point. Go touch some grass.
      if (Math.random() > 0.9) {
        window.location.href = 'https://en.wikipedia.org/wiki/Special:Random';
      }
    } catch (e) { }
  </script>

This is even true at larger scale: https://en.wikipedia.org/wiki/Leopold_Kohr#The_Breakdown_of_...

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.

Isn't this what The Mythical Man-Month is about? https://en.wikipedia.org/wiki/The_Mythical_Man-Month

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.

Lex interview with Bezos. https://www.youtube.com/watch?v=DcWqzZ3I2cY

“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.

Who, then, leads the leader?

Wikipedia definition:

> 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 don’t know what you’re arguing against.

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”.

Okay, I can't tell if you think that's what I'm proposing (it's not) or if you're just taking the moment to rant?

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.

Could you elaborate on that or maybe provide a source to read up on that approach and how it is implemented?

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…

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.

Noted

I know Amazon's API model, but not Apple's. Does anyone have any reading material?

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]

- [0](https://hbr.org/2020/11/how-apple-is-organized-for-innovatio...)

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.

(Ideally)

Not Apple under Jobs. There were projects in isolated buildings. Few on the Mac side were allowed to know about the iPhone until it launched.

Apple's new building is a ring. How many employees can walk all the way around the ring?

I have a theory that Ive left Apple after designing this building because his ego couldn't handle how many people told him he fucked up big time.

Lots of employees walk halfway around the ring just for lunch. All the way around the ring doesn’t sound impossible.

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.)

Oh, I thought there were checkpoints.

>The introduction of any new node into a communication system raises the number of stakeholder relationships exponentially.

Correction: It increases quadratically.

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.

Nitpicking here, but it bothers me a lot the use of "exponentially" to mean "quadratically" in the article.

It even shows a quadratic formula for the number of relationships.

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.

I genuinely think it's been a major loss.

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 genuinely think it's been a major loss.

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...

Startups must choose between doing things

- Cheap - Well - Fast

Choose two.

You can get all three if you don't let project managers take over.

Good leadership of a small skilled team gets you powerful results.

I think that means they aren't cheap.

It's a different kind of cheap. A high functioning team costs what it costs. Until you break it.

Once you become more interested in power than success then the high functioning team becomes the enemy because you can't control them.

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.

The people aren't cheap but you can do more with less. Having one expensive competent engineer is cheaper than four bad ones and a PM.

I can always easily burn extra money to spend more for the same thing.

But that doesn't really tell me anything about how to hire competent people who can build things fast for cheap.

What I'm getting at is "just hire extremely competent people" isn't really a way out of the original statement.

Pick 2 (fast, cheap good).

Very apt summary, I’ve grasped at these points before but never fully articulated what to all. Great points they bring up for consideration

* the productivity/alignment trade-off * the number of communication channels * the time lag of keeping team members/sub-organizations in sync

'Alignment' looks to be the hot new buzzword of summer 2024.

Alignment is just one non-linear transformation away for any set of new basis vectors!

Is it a metaphor for AD&D type alignment?

Lawful Evil, Chaotic Neutral, etc?

> Consider, for instance, how many different functions the three buttons on the sides of your iPhone serve depending on the context.

And why did Android do such a better job of this.

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?

Reply on news.ycombinator.com