How to Ruin a Company with One Bad Process (2014)(a16z.com)
a16z.com
How to Ruin a Company with One Bad Process (2014)
https://a16z.com/2014/07/22/how-to-ruin-your-company-with-one-bad-process/
22 comments
In the long run, having a company dependent on a handful of highly-paid superstars is an incredible risk. Moreover if one team's hiring practices create a "class system" where there are vast disparities in how engineers are paid, there are going to be resentments.
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.
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.
Teams with better people being more productive and getting paid more seems like a normal thing to expect. It seems weird to expect all people and teams to be only to be average, and to see deviations from this as highly risky.
It doesn't make sense to attack the special team here as that team exists to show what is wrong with other parts of the organization, and how productivity might be improved if incentives/measures were changed.
It's also one managers attempt to be more effective. Should one not strive to be more effective? Is it better to make sure that one doesn't differ from average as that would be risky to the business and create resentment?
It doesn't make sense to attack the special team here as that team exists to show what is wrong with other parts of the organization, and how productivity might be improved if incentives/measures were changed.
It's also one managers attempt to be more effective. Should one not strive to be more effective? Is it better to make sure that one doesn't differ from average as that would be risky to the business and create resentment?
If a more productive team emerged naturally from incentives available to everyone, and that team collected large bonuses as a result of proven success, I think the company and the team would both be better off.
If a team is designed from the beginning with a different set of rules than the rest of the company, it has a lot to answer for before it even begins, and its achievements will be accordingly discounted.
If a team is designed from the beginning with a different set of rules than the rest of the company, it has a lot to answer for before it even begins, and its achievements will be accordingly discounted.
Thank you for your insightful comment. This explains a lot from my own experience in big firms.
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.
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.
Some people are experimenting with bringing unfettered capitalism into the corporation:
https://www.bloomberg.com/news/articles/2019-06-20/charging-...
https://www.bloomberg.com/news/articles/2019-06-20/charging-...
This is focusing on expenses though, which is a much easier problem in terms of accounting (I doubt if this particular approach would work well)
The real difficulty is in accounting for revenue contributions
The real difficulty is in accounting for revenue contributions
My god that’s a depressing and frighteningly accurate account of the problem. Well stated!
It seems like if you can't spare anyone maybe you're not training anyone either? A team that's working well should be able to train new hires and that would also bring the averages down.
Isn't that just an extension of the "empire building" that the OP was talking about? If your team is functioning fine with top level or senior developers, why do you have to train anyone? Because senior/top-level developers don't need training and will quickly pick up your system and swim-along relatively fine and learn as they go. That is, if your docs are good, your coverage is excellent and your process is unhindered otherwise by corporate games.
Or maybe they can't spare anyone because they're all busy being trained or training someone.
Or maybe they can't spare anyone because they're all busy being trained or training someone.
Discussed at the time: https://news.ycombinator.com/item?id=8069893
Rather interesting to note the use of "my" rather than "our" and "I" rather than "We" in the article: "Multiply this by all my managers and I was on my way to burning up all my cash and destroying my culture."
I noticed this as well. I wonder how much of his assertive and dominant character also influenced empire-building politics. Management is responsible for setting the general tone and language for the corporate culture.
Even though "we" and "our" sounds better in principle and rightfully gives credit to the team/company as a whole, I've noticed that management oddly like people that speak the opposite way. Speaking about things as "my" team, what "I" would like to do, or what "my" idea is. Saw it recently, even. Coming from a (mediocre) junior developer, coupled with a cocky attitude, and it absolutely infuriates me to watch it.
“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.
- 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.
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?
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?
"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?
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?
> 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.
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.
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).
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.
> Would that mean communication becomes more difficult as the monolith grows? What signifies that?
I'm not sure what you mean by "What signifies that?" but yes, as a team grows, communication cost naturally increases. Imagine a team with N members and no titles or clear signals of what people are responsible for. Imagine one person has a question and wants to know whom to ask. There are N-1 possibilities. So she must have N-1 conversations in the worst case before she finds her answer. Everyone team member occasionally has questions, so the communication cost is actually N times N-1, which is proportional to N squared.
Another concrete example:
Imagine you have a slack channel with 10 people in it. 1 person sends a message and 9 other people read it, think about it, and maybe respond.
Imagine you have a slack channel with 200 people in it. Someone sends a message and thoughtlessly includes '@here' in it. 199 people get pinged.
I'm not sure what you mean by "What signifies that?" but yes, as a team grows, communication cost naturally increases. Imagine a team with N members and no titles or clear signals of what people are responsible for. Imagine one person has a question and wants to know whom to ask. There are N-1 possibilities. So she must have N-1 conversations in the worst case before she finds her answer. Everyone team member occasionally has questions, so the communication cost is actually N times N-1, which is proportional to N squared.
Another concrete example:
Imagine you have a slack channel with 10 people in it. 1 person sends a message and 9 other people read it, think about it, and maybe respond.
Imagine you have a slack channel with 200 people in it. Someone sends a message and thoughtlessly includes '@here' in it. 199 people get pinged.
Called an “Inverse Conway Maneuver.” You take advantage of Conway’s Law and structure the team in the way you want the product to turn out.
“Ideally your technology architecture will display isomorphism with your business architecture.”
“Ideally your technology architecture will display isomorphism with your business architecture.”
It's easy to blame middle managers for playing politics when they focus on empire building above all else, but usually they're just responding to what upper management rewards.
At one of my first Big Company management jobs, I naively thought I would focus on building a small, nimble team of top-10% engineers. We would work cohesively in small but highly efficient teams to deliver results. And it worked! We delivered great things to high praise from our customers faster than expected. Sales were up, customer feedback was up, but politically, we were suffering within the company. A few reasons:
- HR and upper management didn't like engineers being paid significantly above average. Hiring 2-4 top-10% engineers and paying them accordingly attracted a lot scrutiny and criticism from management. Teams who hired 10+ average engineers at average compensation didn't have any problems. Politically, the best move was to ignore the best candidates and focus on hiring as many average candidates as possible.
- Upper management used headcount as a proxy for estimating each team's contributions to a project. If I had 2 principle-level software engineers leading an initiative but my peer allocated 5 junior engineers to his portion of the project, he might collect more credit when those personnel reports go out. Politically, you wanted more names to put in slide decks and more lines on the personnel report spreadsheets wherever management wasn't paying attention to the details.
- The empire builders always had idle hands among their growing headcount, so they were always available to "save the day" by allocating some spare engineers to other department's problems. Ironically, this made it more difficult for other departments to hire more people because management remembered the "save the day" move more than the core work delivered. Politically, if putting out fires is rewarded above all else, you want as many idle hands as possible to assign at a moment's notice.
- Empire builders always had poor performers available to take blame and get fired. Small teams of high performers couldn't spare anyone. When we had budget cuts and headcount reductions, the empire builders always had a few people they could fire with zero consequence to the team. The smaller teams suffered when they lost one of their key performers. Likewise, when empire builders had a project fall behind or fail, they always had an underperforming employee around who could take the blame and get fired, and they also had someone else who could step up and take credit for rescuing the project.
Through all of this, management had no idea they were encouraging empire-building over productivity and cooperation. They were just rewarding what they saw through their slide decks, spreadsheets, and other narrow snapshots of the company that didn't really reflect who was delivering the most value.
Fixing these problems always starts with management. Be very careful about what you reward. And be very careful about how you measure success, because your employees will notice. Any incentive system, explicit or otherwise, will be gamed.