
How to Ruin a Company with One Bad Process (2014) - mooreds
https://a16z.com/2014/07/22/how-to-ruin-your-company-with-one-bad-process/
======
PragmaticPulp
Empire building is one of the most well-known political moves in the company
politics playbook. The difference between healthy team growth and politically-
motivated empire building always feels obvious in retrospect, but it's much
harder to identify as it's unfolding within your own company.

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.

~~~
doublement
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.

~~~
codys
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?

~~~
doublement
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.

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=8069893](https://news.ycombinator.com/item?id=8069893)

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

~~~
n-exploit
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.

~~~
zo1
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.

------
dpflan
“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
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
"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
> 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
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
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.

