2024-11-24 - Splash Damage

Nov 22, 2024

"Splash damage" is a behavior where a person, in the course of solving a problem, creates a bunch of unnecessary work for others. This balloons the total cost of the problem to the company.

An example might be when a person’s work requires many revisions from their peers. Or another example might be that someone creates a massive "10-person committee" for a simple task that takes one person one day.

I believe “splash damage” is low performance. It can also be difficult to spot unless you're looking for it. And, in some company cultures, it can be contagious.

From experience, this has been because:

• The company incentivizes people to do work that involves a lot of people, or incentivizes loud individuals.
  • "This project involved 15 people, therefore it must be a super complex project, and should be rewarded."
  • "Leader/CEO keeps hearing about XYZ, therefore it must be important and high-impact."
• The company hires people who don't do a lot of deep, high-IQ thinking on their own; and these people end up outsourcing this deep work to others.
• The company doesn't sufficiently test for high-agency individuals in the interview panel, or doesn't quickly performance manage low-agency individuals.

Some examples of splash damage are:

• An engineer’s code reviews take 4+ revisions to get right.
• An engineer’s changes constantly cause incidents.
• An engineer’s designs are always too far off the mark, and take many revisions to get right.
• A leader who leans too much on consensus-building: creating processes, committees, and meetings for every decision.
• A product manager escalates every product decision to the CPO, increasing decisionmaking time and unnecessary stakeholders.
• A person tends to create too many "big working groups" for simple tasks.

In nearly every case, I find that it boils down to low ownership. The lesson that often cures splash damage is: just do the thing.

Sometimes there isn't a better way, and this individual truly was thoughtful about their approach. But in most other cases, people quickly realize the footprint of their actions, and pretty quickly correct course.

The best managers are, of course, technical and domain experts that can identify when splash damage is happening. Bad managers may also inadvertently assume work that is valuable is actually “splash damage”.

At the scope of small teams/companies, it is easier to identify, because people can see the impact directly. This ballooning of work becomes very difficult to identify at large scale.