3 ms·

“Engineering growth rate – Unless you are making an acquisition and running it separately or sub-dividing engineering in some novel way, you should strive not t

by dpflan 7y ago

“Engineering growth rate – Unless you are making an acquisition and running it separately or sub-dividing engineering in some novel way, you should strive not to more than double a monolithic engineering organization in a 12-month period.” - Note the word “monolithic”. When should a monolithic org be broken up to support faster growth? There is definitely an art to this, but I don’t personally have the experience to give an answer here.

afarrell 7y ago
As an engineer without management experience, I'll throw out one idea: You should break up a monolithic engineering org when the effects of Conway's law mean that the org's divisions will result in a better set of products with better user experiences. ------------------------------------------------- I can imagine the following conversation happening among people who hold this principle: Alice: In order to develop the features we want by next year, we'll need to grow the engineering organization by 3x over the next year Ben: If we do that, it will be hard to maintain the cultural cohesion to keep the engineering org aligned. Alice: Good point. Currently, our engineering org is monolithic. Would it make sense to split into two? Ben: If we do that, we'd either have two engineering orgs which are both growing at 3x and have the same problem...or we have one which is growing at 2x and one which is growing at...{mental algebra}...like 5x because it started out smaller. Melvin Conway: Also remember, when you create an organizational boundary, it impacts the way the product is developed. That can be good if the teams realize they need to define a clean interface between their submodules. But it also means you should divide the human responsibilities in the same way that you'd divide the module responsibilities. Jason: Should we really grow the engineering org that fast? Would it be better to constrain headcount growth to 1.9x and cut features from our roadmap? Alice: Jason, the question of scope is always worth asking. You and I were both aligned that when we started the discussion of the high-level roadmap. Consequently, there's not anything superfluous here. Some of these are key user needs we need to deliver on to retain or win clients to hit future revenue targets. Some of these are foundational investments we need to make if our service is going to still be stable at the scale we're approaching. Some of these are just baseline permission-to-play in the new geographies we know we need to go after. Jason: You're totally right. And yet Ben's point about the risk to cultural cohesion still stands. And {gestures at Conway} we're also risking the cohesion of our product's user experience. {thoughtful silence} Melvin: I have a few questions that could move us forward: - Of these product goals, which already have subteams with the knowledge to execute them? - If we did split the Engineering org, which subteams could afford to each other less frequently? - For the goals where no subteam yet maintains the required knowledge, is it better to upskill an existing team or start a new subteam? - For the new subteams, do they need to have much knowledge of our existing business? Or can we acquire a subteam?
- dpflan 7y ago
  "The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interface structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult." Would that mean communication becomes more difficult as the monolith grows? What signifies that? This seems dependent upon team formation that is a result of segregation by frequent communications and knowledge-share about commonly used and maintained systems: essentially, a group (rather than an individual) becomes "expert" in a portion of the monolith and then separates themselves from the monolith (organically or by decree). I think when a group can stand in for an individual, perhaps that is signal that the organization can begin to subdivide. Bottom-up vs. top-down subdivision: which is better?
  - AnimalMuppet 7y ago
    > Would that mean communication becomes more difficult as the monolith grows? I'm not quite sure that "this" implies "that", but it is definitely true that communication becomes more difficult as the monolith grows. > What signifies that? Everything starts taking longer. Peoples' work steps on other peoples' work. You need more meetings to keep everything straight.
    - dpflan 7y ago
      Ah, that’s interesting and easy to track i bet: more meetings with engineers and analysis of code base encroachment (and similar code being created across repos).
      - AnimalMuppet 7y ago
        And more bugs where a change in one area broke something that seemed unrelated. Note that the initial bug report may not know that - it may take specifically asking the question after fixing the bug.
  - afarrell 7y ago

by dpflan 7y ago

afarrell 7y ago

As an engineer without management experience, I'll throw out one idea: You should break up a monolithic engineering org when the effects of Conway's law mean that the org's divisions will result in a better set of products with better user experiences. ------------------------------------------------- I can imagine the following conversation happening among people who hold this principle: Alice: In order to develop the features we want by next year, we'll need to grow the engineering organization by 3x over the next year Ben: If we do that, it will be hard to maintain the cultural cohesion to keep the engineering org aligned. Alice: Good point. Currently, our engineering org is monolithic. Would it make sense to split into two? Ben: If we do that, we'd either have two engineering orgs which are both growing at 3x and have the same problem...or we have one which is growing at 2x and one which is growing at...{mental algebra}...like 5x because it started out smaller. Melvin Conway: Also remember, when you create an organizational boundary, it impacts the way the product is developed. That can be good if the teams realize they need to define a clean interface between their submodules. But it also means you should divide the human responsibilities in the same way that you'd divide the module responsibilities. Jason: Should we really grow the engineering org that fast? Would it be better to constrain headcount growth to 1.9x and cut features from our roadmap? Alice: Jason, the question of scope is always worth asking. You and I were both aligned that when we started the discussion of the high-level roadmap. Consequently, there's not anything superfluous here. Some of these are key user needs we need to deliver on to retain or win clients to hit future revenue targets. Some of these are foundational investments we need to make if our service is going to still be stable at the scale we're approaching. Some of these are just baseline permission-to-play in the new geographies we know we need to go after. Jason: You're totally right. And yet Ben's point about the risk to cultural cohesion still stands. And {gestures at Conway} we're also risking the cohesion of our product's user experience. {thoughtful silence} Melvin: I have a few questions that could move us forward: - Of these product goals, which already have subteams with the knowledge to execute them? - If we did split the Engineering org, which subteams could afford to each other less frequently? - For the goals where no subteam yet maintains the required knowledge, is it better to upskill an existing team or start a new subteam? - For the new subteams, do they need to have much knowledge of our existing business? Or can we acquire a subteam?

dpflan 7y ago
"The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interface structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult." Would that mean communication becomes more difficult as the monolith grows? What signifies that? This seems dependent upon team formation that is a result of segregation by frequent communications and knowledge-share about commonly used and maintained systems: essentially, a group (rather than an individual) becomes "expert" in a portion of the monolith and then separates themselves from the monolith (organically or by decree). I think when a group can stand in for an individual, perhaps that is signal that the organization can begin to subdivide. Bottom-up vs. top-down subdivision: which is better?
- AnimalMuppet 7y ago
  > Would that mean communication becomes more difficult as the monolith grows? I'm not quite sure that "this" implies "that", but it is definitely true that communication becomes more difficult as the monolith grows. > What signifies that? Everything starts taking longer. Peoples' work steps on other peoples' work. You need more meetings to keep everything straight.
  - dpflan 7y ago
    Ah, that’s interesting and easy to track i bet: more meetings with engineers and analysis of code base encroachment (and similar code being created across repos).
    - AnimalMuppet 7y ago
      And more bugs where a change in one area broke something that seemed unrelated. Note that the initial bug report may not know that - it may take specifically asking the question after fixing the bug.
- afarrell 7y ago