37 ms·

Designing Engineering Organizations

141 points by dochtman 6y ago

jasonpeacock 6y ago
Team Topologies[0] goes into more depth about this topic, it's a good read. [0] https://smile.amazon.com/gp/product/1942788819 https://smile.amazon.com/gp/product/1942788819
- anhldbk 6y ago
  Correct! This is an interesting book about organization design.
lrossi 6y ago
> My experience is that it takes at least 6 months to reach the “performing” level, and sometimes much more. If staff switch teams more often than that, teams never reach their full potential. On one hand, I agree with this, as I have been moved quickly between projects in the past, when I was more needed elsewhere. It helped to keep things interesting but I would have liked more stability. On the other hand, there is a risk that people get stuck in one place for a while with no mobility, working on something they don’t like. I have seen this as well. Good people weren’t allowed to move, so they quit. As the team was shrinking, the others had to stay. Needless to say that morale was poor. There is a fine line between the two.
- inerte 6y ago
  The "performing" part isn't about the individuals on the team, but the team as a whole. Every staff changes (adding or removing) slows down the entire team for a period of time. This isn't also about people not moving and denying them career or personal opportunities, just a consequence of team changes. It's a reaction to the idea that once you add more people to a team or an organization, you will see productivity gains almost immediately. It tells you that actually they will take some time, and often, a LOT more time than you initially thought.
- natmaka 6y ago
  Others criteria are sound from the organization's POV, many (most?) of them pushing it to quickly move people. A classic one is "do no let any project (and therefore at least part of at least one product) become more-or-less the private domain of its team". "Private domain" may be anything from "not really documented in written form because no member of the team needs it", to "this team gained enough power by becoming the only one able to run its project, that it now can strangle the org". Thanks to an adedequate stream of newcomers there is always some knowledge outside of the team (=> high "bus factor"), and more risk and work for any potential warlord.
ramenmeal 6y ago
I assume this is based purely from his experience. I wonder how much research has been done on this. Surely Microsoft has tried to do some studies on it?
Noe2097 6y ago
This post is interesting only as an example of a total lack of facts, comparisons, and perspective. The lone backing of each opinion is the adverb "generally". There is no mention of any concrete team/company size where issues do/might occur in one or the other setup. There is no mention of successful or failing companies adopting one or the other setup. And just to mention a single concrete counter-example to the groundless side taken here, take Apple. Apple's organization is _based_ on specialization, for the simple reason that the more specialized teams are, the higher their expertise is. Look at Spotify, Microsoft, and others; they moved away from the simplistic feature-squad model advocated here, because it simply didn't scale. Certainly, communication across team members, and communication across teams are subjects of attention. It does not mean it should be ignored/avoided. It's like saying "scaling horizontally is too difficult, just stick to scaling vertically"; sure, it's easier, but the power is not the same.
- smilliken 6y ago
  "Generally" is a bit of a cop out without data, but it's not wrong. If you survey companies to understand their organizational structure, you will see the sample dominated by domain-oriented structures (eg product, business unit, etc) as opposed to functionally-oriented structures (eg skills). The example you mention (Apple) is a notable one precisely because it's an outlier in this respect. It is interesting! In particular, I understand than iPhone, iPad, and Mac are built by the same people, not split across separate teams. Even then, Apple still has lots of typical domain-oriented structure. Of the 10 or so people I'vd known to work there, all of them have been in product-oriented teams.
- coderintherye 6y ago
  While I generally agree with the author's thesis based on my own experience leading engineering teams, I also agree with your view point that the author provides no facts to back it up, not even examples of teams he has worked on. This makes his opinions somewhat circumspect. For an example of research-based conclusions about teams, Google's write-ups are illustrative: https://rework.withgoogle.com/print/guides/5721312655835136/ https://rework.withgoogle.com/print/guides/5721312655835136/ In general, I think Google's research captures something that the author of this post fails to take into account fully, which is that psychological safety of the team members matters is a key indicator towards effectiveness.
ellimilial 6y ago
'This is – to use a technical term – bullcrap.' It's moderately inspiring to read this kind of technical opinion from a technical leader. I have heard similar objections/uneasiness concerning delivery-aligned reporting, coming especially from more junior specialists. More so within teams with broader sets of disciplines. In addition to the need of improving their skillset and receiving tailored career guidance, there is sometimes a strong political component.
- keyle 6y ago
  off topic, I've never heard the term "junior specialist" before, and that sounds hilarious.
  - natmaka 6y ago
    It may be related to a military grade, see https://en.wikipedia.org/wiki/Specialist_(rank) https://en.wikipedia.org/wiki/Specialist_(rank) ... and wait for "junior specialist in everything" :-)
  - jmchuster 6y ago
    One way of thinking of engineers is that they exist along two axis, junior => senior and generalist => specialist. So, when hiring, you might say something like, I want my team to be 50% senior generalists, 25% senior specialists, and 25% junior specialists. And, uh, yeah, junior specialists would probably end up being someone who can't really produce much of anything.
    - keyle 6y ago
      But... how is that a career path... specialist vs. generalist? I mean I'm a generalist, and if you look at my 20 years in the industry, I'm a generalist because of the trail of work I've left behind; as in work, all of which needed to happen. For example, in the 2000s, we mostly used PHP and MySQL, today, it's very different. So being a specialist with, let's say, 10+ years experience, would be quite difficult. I'm sure even the C++ people can say C++ has changed a lot in 20 years(?) and are doing things radically different today? How could I be a React specialist with 20 years in the industry? Forget the past?
jschwartzi 6y ago
Generally, you should do what makes sense for your organization regardless of what other organizations are doing.
- the_arun 6y ago
  I thought so too. One size doesn't fit all.
deleted 6y ago
[deleted]
contingencies 6y ago
You don't design an organization, you grow an organization.
- systemvoltage 6y ago
  I don't get it. What's the difference? Designing and growing are not antonyms.
  - contingencies 6y ago
    Design implies an authoritative, non-iterative mega-deployment. Growing implies an iterative, heterogeneous, observation-laden process with potential for feedback and adjustment. Where humans are involved, the latter is superior, if you want coherency and efficiency.
    - systemvoltage 6y ago
      There is no way one could have picked up what you meant from just saying "Design vs. growth". You realize how general those terms are, right? Something that implies to you may not imply to many others. Still your language is imprecise. Can you give examples? > authoritative, non-iterative mega-deployment Like what? Who designs a team like this? What are some concrete examples?
      - contingencies 6y ago
        Apologies if it was unclear to you. It's hard to know who reads all the comments here and impossible to address everyone clearly. Many people on HN are involved in building companies which means they have experience with this sort of thing and probably understood without explanation. Who designs a team like this? Bigco HR departments, the military, the government, emergency response NGOs, etc.
        systemvoltage 6y ago
        That helps and I agree with the examples you cite. I think then we're arguing about mostly bureaucracy - they work great for stable work that needs to happen on a long term basis. Not agile. But, they have their purpose. If militaries and governments were formed like startups ("growth" as we define here), they would fail to function well. Hierarchy is important characteristic of militaries and big companies. We develop everything from fighter jets to fiscal policy through "designed" organizations.
User23 6y ago
More on Conway’s Law at [1]. The adage bears out and while this article could be better, understanding the mirroring phenomenon really is important. And while it’s not a formal proof, I do find the argument that the law must hold to be true. [1] http://melconway.com/Home/Conways_Law.html http://melconway.com/Home/Conways_Law.html
convolvatron 6y ago
i worked at an organization recently that has wholeheartedly embraced this approach to Conway's law. unfortunately, the groupings were decided based on a facile and outdated model of the product and were wildly unsuited for the reality of the day. kind of pessimal. i think a more organic approach is necessary. even in larger organizations. i've never seen matrix (too many stakeholders, too many meetings, unclear unresponsibilities) do well...but surely there are other choices other than functional v product.
- webmaven 6y ago
  Organizations need to be refactored just as much as code does, and for similar reasons.
jasonpeacock 6y ago
No discussion of Conway's Law is complete without mentioning the Inverse (or Reverse) Conway Maneuver[0] - knowing that architecture follows org structure, you structure your org to deliver the desired architecture. [0] https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver https://www.thoughtworks.com/radar/techniques/inverse-conway...
- webmaven 6y ago
  That's mentioned in the linked post.
0xbadcafebee 6y ago
I've read a lot on how other orgs have grown and gone through DevOps transformations, and all of this is echoed in those stories, but it also leaves out other strategies. Would like to see more of a matrix of what strategies are useful in what context and aren't in others. In SRE/Ops, it seems to work better with two single-disciplinary teams (Builders and Runners) in one department. One team builds systems, another team runs systems. This is because experience leads to efficiency. Scaling a single-disciplinary team (in this context) you get efficiency combined with ability to respond to organizational change. Think of a cabinetmaker versus a chair maker. Or in comparing SW Developer / SRE-Builder / SRE-Runner, an auto engineer, an auto mechanic, and a racecar driver. They are each efficient at a particular thing because of their experience. But for building and running a product as a whole, you want a multi-disciplinary team to manage the wide range of experience needed to build and run that product. You still rely on outside single-disciplinary teams for things that can be done more efficiently that way. But you can change the product faster/better if a core group has a lot of general knowledge about it. The trick is to create feedback loops where these different teams feed information and work streams back into each other constantly. You do this to fight silo-ism, and to reduce friction in the value chain. I think "reporting" is highly overrated. The principle of a self-organizing team is that they will figure out what they need to do. If you start dissolving the "lines" between teams, the organization as a whole will start figuring out what it needs to do. If you think about ecology, this is how natural systems work: there are always boundaries in different parts of an organism, but many of its parts self-determine their actions. Coordination becomes a ballet, not a machine. And what's often overlooked is how the larger organization affects the value chain. The higher levels of the organization often set the tone for how work gets done for everyone. But different parts of the org may benefit from radically different working models. Are there proven ways to run different parts of the business in drastically different ways, yet still provide clear workflows for them to operate together efficiently?
choeger 6y ago
Written by a product manager, I would presume. This design is optimized for product managers and that's it. 1. No communication responsibilities. The product manager owns a team for the product and that's it. 2. Maximal headcount. Need a tenths of a frontend dev? You get one fully for your team! 3. No technical understanding required. You just tell the DB guy to "make things happen" via user story. No engineering manager to argue with, no wholistic constraints to consider. Disk space, bandwidth? What is that? May playlist feature needs to store all permutations persistently for performance! The greatest admission is the implicit acknowledgement that product managers cannot work efficiently with teams organized by discipline. In any other industry that is the bread and butter of management: Coordinate and plan with other departments. Here we just eliminate this. And what's the outcome? A coherent product? Far from it. You get a bunch of features glued together by a UI no one really owned. These features are not orthogonal and they definitely don't compose well. Why? Because to do so the product managers of different teams would have to coordinate between themselves. The very thing they just admitted they cannot do efficiently.
- madspindel 6y ago
  > software developer, co-creator of Django, and an experienced engineering leader
- aceflux 6y ago
  Please say more on point #2 - what's the rationale behind wanting a fractional member vs dedicated member in a particular engineering team structure?
  - choeger 6y ago
    Well, it should be obvious that not every feature/user story you develop needs a 40h/week specialist for every part of your product. Sometime you might only need to tweak the UI ever so slightly, or the backend integration could be trivial. Very often you will either have fractional stories in your sprint or underutilize your team. So in a perfect scenario you would share your specialistst amongst teams, but that goes against the typical manager metrics which is "how big is my headcount".

141 points by dochtman 6y ago

Team Topologies[0] goes into more depth about this topic, it's a good read. [0] https://smile.amazon.com/gp/product/1942788819 https://smile.amazon.com/gp/product/1942788819

anhldbk 6y ago
Correct! This is an interesting book about organization design.

lrossi 6y ago

> My experience is that it takes at least 6 months to reach the “performing” level, and sometimes much more. If staff switch teams more often than that, teams never reach their full potential. On one hand, I agree with this, as I have been moved quickly between projects in the past, when I was more needed elsewhere. It helped to keep things interesting but I would have liked more stability. On the other hand, there is a risk that people get stuck in one place for a while with no mobility, working on something they don’t like. I have seen this as well. Good people weren’t allowed to move, so they quit. As the team was shrinking, the others had to stay. Needless to say that morale was poor. There is a fine line between the two.

inerte 6y ago
The "performing" part isn't about the individuals on the team, but the team as a whole. Every staff changes (adding or removing) slows down the entire team for a period of time. This isn't also about people not moving and denying them career or personal opportunities, just a consequence of team changes. It's a reaction to the idea that once you add more people to a team or an organization, you will see productivity gains almost immediately. It tells you that actually they will take some time, and often, a LOT more time than you initially thought.
natmaka 6y ago
Others criteria are sound from the organization's POV, many (most?) of them pushing it to quickly move people. A classic one is "do no let any project (and therefore at least part of at least one product) become more-or-less the private domain of its team". "Private domain" may be anything from "not really documented in written form because no member of the team needs it", to "this team gained enough power by becoming the only one able to run its project, that it now can strangle the org". Thanks to an adedequate stream of newcomers there is always some knowledge outside of the team (=> high "bus factor"), and more risk and work for any potential warlord.

ramenmeal 6y ago

I assume this is based purely from his experience. I wonder how much research has been done on this. Surely Microsoft has tried to do some studies on it?

Noe2097 6y ago

This post is interesting only as an example of a total lack of facts, comparisons, and perspective. The lone backing of each opinion is the adverb "generally". There is no mention of any concrete team/company size where issues do/might occur in one or the other setup. There is no mention of successful or failing companies adopting one or the other setup. And just to mention a single concrete counter-example to the groundless side taken here, take Apple. Apple's organization is _based_ on specialization, for the simple reason that the more specialized teams are, the higher their expertise is. Look at Spotify, Microsoft, and others; they moved away from the simplistic feature-squad model advocated here, because it simply didn't scale. Certainly, communication across team members, and communication across teams are subjects of attention. It does not mean it should be ignored/avoided. It's like saying "scaling horizontally is too difficult, just stick to scaling vertically"; sure, it's easier, but the power is not the same.

smilliken 6y ago
"Generally" is a bit of a cop out without data, but it's not wrong. If you survey companies to understand their organizational structure, you will see the sample dominated by domain-oriented structures (eg product, business unit, etc) as opposed to functionally-oriented structures (eg skills). The example you mention (Apple) is a notable one precisely because it's an outlier in this respect. It is interesting! In particular, I understand than iPhone, iPad, and Mac are built by the same people, not split across separate teams. Even then, Apple still has lots of typical domain-oriented structure. Of the 10 or so people I'vd known to work there, all of them have been in product-oriented teams.
coderintherye 6y ago
While I generally agree with the author's thesis based on my own experience leading engineering teams, I also agree with your view point that the author provides no facts to back it up, not even examples of teams he has worked on. This makes his opinions somewhat circumspect. For an example of research-based conclusions about teams, Google's write-ups are illustrative: https://rework.withgoogle.com/print/guides/5721312655835136/ https://rework.withgoogle.com/print/guides/5721312655835136/ In general, I think Google's research captures something that the author of this post fails to take into account fully, which is that psychological safety of the team members matters is a key indicator towards effectiveness.

ellimilial 6y ago

'This is – to use a technical term – bullcrap.' It's moderately inspiring to read this kind of technical opinion from a technical leader. I have heard similar objections/uneasiness concerning delivery-aligned reporting, coming especially from more junior specialists. More so within teams with broader sets of disciplines. In addition to the need of improving their skillset and receiving tailored career guidance, there is sometimes a strong political component.

keyle 6y ago
off topic, I've never heard the term "junior specialist" before, and that sounds hilarious.
- natmaka 6y ago
  It may be related to a military grade, see https://en.wikipedia.org/wiki/Specialist_(rank) https://en.wikipedia.org/wiki/Specialist_(rank) ... and wait for "junior specialist in everything" :-)
- jmchuster 6y ago
  One way of thinking of engineers is that they exist along two axis, junior => senior and generalist => specialist. So, when hiring, you might say something like, I want my team to be 50% senior generalists, 25% senior specialists, and 25% junior specialists. And, uh, yeah, junior specialists would probably end up being someone who can't really produce much of anything.
  - keyle 6y ago
    But... how is that a career path... specialist vs. generalist? I mean I'm a generalist, and if you look at my 20 years in the industry, I'm a generalist because of the trail of work I've left behind; as in work, all of which needed to happen. For example, in the 2000s, we mostly used PHP and MySQL, today, it's very different. So being a specialist with, let's say, 10+ years experience, would be quite difficult. I'm sure even the C++ people can say C++ has changed a lot in 20 years(?) and are doing things radically different today? How could I be a React specialist with 20 years in the industry? Forget the past?

jschwartzi 6y ago

Generally, you should do what makes sense for your organization regardless of what other organizations are doing.

the_arun 6y ago
I thought so too. One size doesn't fit all.

deleted 6y ago

[deleted]

contingencies 6y ago

You don't design an organization, you grow an organization.

systemvoltage 6y ago
I don't get it. What's the difference? Designing and growing are not antonyms.
- contingencies 6y ago
  Design implies an authoritative, non-iterative mega-deployment. Growing implies an iterative, heterogeneous, observation-laden process with potential for feedback and adjustment. Where humans are involved, the latter is superior, if you want coherency and efficiency.
  - systemvoltage 6y ago
    There is no way one could have picked up what you meant from just saying "Design vs. growth". You realize how general those terms are, right? Something that implies to you may not imply to many others. Still your language is imprecise. Can you give examples? > authoritative, non-iterative mega-deployment Like what? Who designs a team like this? What are some concrete examples?
    - contingencies 6y ago
      Apologies if it was unclear to you. It's hard to know who reads all the comments here and impossible to address everyone clearly. Many people on HN are involved in building companies which means they have experience with this sort of thing and probably understood without explanation. Who designs a team like this? Bigco HR departments, the military, the government, emergency response NGOs, etc.
      - systemvoltage 6y ago
        That helps and I agree with the examples you cite. I think then we're arguing about mostly bureaucracy - they work great for stable work that needs to happen on a long term basis. Not agile. But, they have their purpose. If militaries and governments were formed like startups ("growth" as we define here), they would fail to function well. Hierarchy is important characteristic of militaries and big companies. We develop everything from fighter jets to fiscal policy through "designed" organizations.

User23 6y ago

More on Conway’s Law at [1]. The adage bears out and while this article could be better, understanding the mirroring phenomenon really is important. And while it’s not a formal proof, I do find the argument that the law must hold to be true. [1] http://melconway.com/Home/Conways_Law.html http://melconway.com/Home/Conways_Law.html

convolvatron 6y ago

i worked at an organization recently that has wholeheartedly embraced this approach to Conway's law. unfortunately, the groupings were decided based on a facile and outdated model of the product and were wildly unsuited for the reality of the day. kind of pessimal. i think a more organic approach is necessary. even in larger organizations. i've never seen matrix (too many stakeholders, too many meetings, unclear unresponsibilities) do well...but surely there are other choices other than functional v product.

webmaven 6y ago
Organizations need to be refactored just as much as code does, and for similar reasons.

jasonpeacock 6y ago

No discussion of Conway's Law is complete without mentioning the Inverse (or Reverse) Conway Maneuver[0] - knowing that architecture follows org structure, you structure your org to deliver the desired architecture. [0] https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver https://www.thoughtworks.com/radar/techniques/inverse-conway...

webmaven 6y ago
That's mentioned in the linked post.

0xbadcafebee 6y ago

I've read a lot on how other orgs have grown and gone through DevOps transformations, and all of this is echoed in those stories, but it also leaves out other strategies. Would like to see more of a matrix of what strategies are useful in what context and aren't in others. In SRE/Ops, it seems to work better with two single-disciplinary teams (Builders and Runners) in one department. One team builds systems, another team runs systems. This is because experience leads to efficiency. Scaling a single-disciplinary team (in this context) you get efficiency combined with ability to respond to organizational change. Think of a cabinetmaker versus a chair maker. Or in comparing SW Developer / SRE-Builder / SRE-Runner, an auto engineer, an auto mechanic, and a racecar driver. They are each efficient at a particular thing because of their experience. But for building and running a product as a whole, you want a multi-disciplinary team to manage the wide range of experience needed to build and run that product. You still rely on outside single-disciplinary teams for things that can be done more efficiently that way. But you can change the product faster/better if a core group has a lot of general knowledge about it. The trick is to create feedback loops where these different teams feed information and work streams back into each other constantly. You do this to fight silo-ism, and to reduce friction in the value chain. I think "reporting" is highly overrated. The principle of a self-organizing team is that they will figure out what they need to do. If you start dissolving the "lines" between teams, the organization as a whole will start figuring out what it needs to do. If you think about ecology, this is how natural systems work: there are always boundaries in different parts of an organism, but many of its parts self-determine their actions. Coordination becomes a ballet, not a machine. And what's often overlooked is how the larger organization affects the value chain. The higher levels of the organization often set the tone for how work gets done for everyone. But different parts of the org may benefit from radically different working models. Are there proven ways to run different parts of the business in drastically different ways, yet still provide clear workflows for them to operate together efficiently?

choeger 6y ago

Written by a product manager, I would presume. This design is optimized for product managers and that's it. 1. No communication responsibilities. The product manager owns a team for the product and that's it. 2. Maximal headcount. Need a tenths of a frontend dev? You get one fully for your team! 3. No technical understanding required. You just tell the DB guy to "make things happen" via user story. No engineering manager to argue with, no wholistic constraints to consider. Disk space, bandwidth? What is that? May playlist feature needs to store all permutations persistently for performance! The greatest admission is the implicit acknowledgement that product managers cannot work efficiently with teams organized by discipline. In any other industry that is the bread and butter of management: Coordinate and plan with other departments. Here we just eliminate this. And what's the outcome? A coherent product? Far from it. You get a bunch of features glued together by a UI no one really owned. These features are not orthogonal and they definitely don't compose well. Why? Because to do so the product managers of different teams would have to coordinate between themselves. The very thing they just admitted they cannot do efficiently.

madspindel 6y ago
> software developer, co-creator of Django, and an experienced engineering leader
aceflux 6y ago
Please say more on point #2 - what's the rationale behind wanting a fractional member vs dedicated member in a particular engineering team structure?
- choeger 6y ago
  Well, it should be obvious that not every feature/user story you develop needs a 40h/week specialist for every part of your product. Sometime you might only need to tweak the UI ever so slightly, or the backend integration could be trivial. Very often you will either have fractional stories in your sprint or underutilize your team. So in a perfect scenario you would share your specialistst amongst teams, but that goes against the typical manager metrics which is "how big is my headcount".