How to Ruin a Company with One Bad Process (2014)

Do you have any suggestions on how to encourage efficient delivery over Empire building ? It almost feels like any metric driven incentive can be gamed, due to the difficulty in backpropagating revenue to the individual functions.

If you build a special team in a company that has different norms overall, everything that you accomplish is going to be discounted according to how much it makes the rest of the company harder to manage, and how vulnerable the company becomes to a small number of superstars leaving. There's a bigger picture than just what the team gets done.

EDIT: That said, if the results are markedly better than the company's general performance, the company as a whole might need some re-tooling. But a special team isn't going to stay special for long, either way.

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?