5 ms·

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 man

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"

erikerikson 6y ago
Perhaps: as size increases, relationships don't scale and mechanisms of control and coordination become more shallow.
Smaug123 6y ago
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-summary/ https://thezvi.wordpress.com/2020/05/23/mazes-sequence-summa...).
plorkyeran 6y ago
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.
- chris11 6y ago
  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.
- titanomachy 6y ago
  > 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.
- pm90 6y ago
  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.
- rm_-rf_slash 6y ago
  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.
closeparen 6y ago
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").
- jgeada 6y ago
  That is a brilliant take on middle management!
- sesuximo 6y ago
  Some middle managers also serve as individual contributors
- kubanczyk 6y ago
  Or, in short, "middle managers gotta middle manage".
- kochikame 6y ago
  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.
beastcoast 6y ago
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.
fhrow4484 6y ago
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?
- romwell 6y ago
  >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.
  - ColFrancis 6y ago
    > Not after the infamous need-to-know memo. I couldn't find that memo, could you please link to a copy?
    - username90 6y ago
      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.
    - romwell 6y ago
      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-execs-internal-email-on-data-leak-policy-rattles https://www.buzzfeednews.com/article/carolineodonovan/google...

erikerikson 6y ago

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

Smaug123 6y ago

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-summary/ https://thezvi.wordpress.com/2020/05/23/mazes-sequence-summa...).

plorkyeran 6y ago

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.

chris11 6y ago
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.
titanomachy 6y ago
> 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.
pm90 6y ago
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.
rm_-rf_slash 6y ago
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.

closeparen 6y ago

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

jgeada 6y ago
That is a brilliant take on middle management!
sesuximo 6y ago
Some middle managers also serve as individual contributors
kubanczyk 6y ago
Or, in short, "middle managers gotta middle manage".
kochikame 6y ago
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.

beastcoast 6y ago

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.

fhrow4484 6y ago

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?

romwell 6y ago
>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.
- ColFrancis 6y ago
  > Not after the infamous need-to-know memo. I couldn't find that memo, could you please link to a copy?
  - username90 6y ago
    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.
  - romwell 6y ago
    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-execs-internal-email-on-data-leak-policy-rattles https://www.buzzfeednews.com/article/carolineodonovan/google...