Hacker News Reader

Comment by opportune | Hacker News Reader

I have noticed that as SV companies get larger they tend to adopt the more "old school" approach. Not that it's a binary - it's a spectrum, and depending on management chain/how an org runs, people can have different experiences.

I think it's caused by

1. When you have very deep management chains you start to have lots of people with opinions on what you should do, how you should do it, who you should do it with. Even if on average most of them aren't micromanagers, it only takes a few.

2. As you grow you start pulling in more people with experience outside of SV who bring in culture with them. Note that "SV" is also not monolithic here. Companies like Microsoft (ok, technically not SV) are farther to the "traditional" side of the spectrum.

3. "Horizontals"

View on HN

The "SV style" runs into scaling problems. Engineers making product decisions requires that they have a solid grasp on everything the business cares about, which gets harder as the business gets bigger. Direct engineer -> engineer communication between teams is O(N^2) to organize things between N engineers.

As you grow I think reducing engineer autonomy is unavoidable, and the goal is merely to stick to reducing it and not eliminating it.

It's not the only solution for building products. But you can still maintain dev autonomy. Instead of having senior team-members break apart work into story-sized pieces a system can be broken apart into smaller pieces. Devs can still be working towards a specific business goal, but they can own a larger portion of their work, and they can work with longer deadlines.

Also, I think dealing with those large scale issues is what separates a staff/principal dev from a senior dev.

> Direct engineer -> engineer communication between teams is O(N^2) to organize things between N engineers.

This isn't true in my experience. I'd say it's more like a binary search than a fully-connected network. I talk to my immediate team first. If they can't help, I dig through the company-wide documentation and codebase, then message people who have done or considered something similar to what I'm trying to do; they either give me the information I need, or direct me to someone more likely to have it. Each hop gets me closer to an answer, and I typically end up having to talk to 1-3 engineers rather than the O(500) who work in my organization.

Part of the reason this works is because there are a handful of very senior engineers who have a good sense of what's going on across a big part of the company. Complex requests often get routed through one of these people, and they always seem to know who to talk to. I guess that's a form of hierarchy, but without the "command-and-control" aspect. I see it as an occasional escape hatch rather than a primary means of problem-solving.

I have to ask though: if a company built on engineering doesn’t empower its engineers to make product decisions, who can make them?

In my anecdotal experience, the “product” people generally have lesser context than the engineers, and often rely on engineers to do their jobs. The good ones make a serious effort to get at least a vague understanding of how the product works and are hungry to hear ideas on how to deliver more value.

However most PMs will not be this way. Their primary instinct is to interface with the product hierarchy and explain to engineers what the “higher ups” want. They exercise this power by vetoing ideas that don’t fit into this narrative, even if these ideas would improve the product. Engineers then mostly don’t really share everything that they’re working on with the apathetic PM; the motivated ones build things anyways risking rebukes while others will do just what product asks for.

The only scalable solution really, is to create processes and career paths for engineers who are inclined to product design to become PMs, or at least spend part of their time as PMs.

At Service Oriented B2B companies, there is another class of people who become excellent PMs: the Customer Service Managers, who have dealt with Customers and their issues, and have a deep understanding of the problems and frustrations faced by users of these systems.

This is where I think Apple does really well by having lots of small teams that each focus on a particular product area (Calendar, Remote Desktop, etc).

Teams have very limited scope in exchange for enormous autonomy. “Inmates run the asylum” as my former manager put it.

4. Middle managers are going to do something with their days. Once the growth frenzy stops and they're longer occupied by procuring and filling headcount, they go the next thing they know, implementing systems of surveillance ("accountability") and control ("alignment").

That is a brilliant take on middle management!

Some middle managers also serve as individual contributors

Or, in short, "middle managers gotta middle manage".

I hate the word “alignment” with a passion.

It never means “let’s do things in a coordinated and mutually beneficial way”. It always means “you will do the thing that I want you to do, or the way I want you to do it”.

Weasel word, if ever there was one.

Completely agree, see it at companies like Google turning more and more into deep management chains. Some of the good remains (code & documentation transparency, engineer to engineer communication), but much off the decision making is shifting up the chain

Do you mind expanding on what you mean by "Horizontals" here?

>Some of the good remains (code & documentation transparency)

Not after the infamous need-to-know memo.

Team docs visibility defaulted to "only to people I explicitly share with" for almost a year now.

It's only a question of time until code branches follow suit.

> Not after the infamous need-to-know memo.

I couldn't find that memo, could you please link to a copy?

It said that everything should only be shared on a need to know basis, basically ending the culture of all documents being open by default unless there is a need to hide it. When that change took into effect all documents I had were automatically set to hidden and I had to reshare them with everyone who needed to see them.

Here you go[1].

The audacity of that email was that it made accessing "need-to-know" documents internally (!!!) a fireable offense.

In a kafkaesque move, "need-to-know" was not determined by labeling or access restrictions. Therefore, you can't know you are accessing a "need-to-know" document until you do.

In short, this made using internal search engine fireable. It made clicking any link on the mail list fireable.

That was a year and a half ago.

[1]https://www.buzzfeednews.com/article/carolineodonovan/google...

Related: the "Moral Maze" of Robert Jackall fame, recently "popularised" (if Less Wrong can be considered "popular") by Zvi Mowshowitz (https://thezvi.wordpress.com/2020/05/23/mazes-sequence-summa...).

This is a big part of Amazon’s success. Service oriented architecture gives teams enough autonomy to define their own processes. “You build it, you own it” often extends to products as well as services.

Perhaps: as size increases, relationships don't scale and mechanisms of control and coordination become more shallow.

Reply on news.ycombinator.com