Dirt Floors: How to Stop Putting Out Fires and Solve the Real Problem

What do dirt floors have to do with going to school? And what does any of that have to do with working more effectively?

Dirt Floors: How to Stop Putting Out Fires and Solve the Real Problem

In every company I’ve ever worked with, there’s a paradox: everyone seems to want to do things that make the product (or service) better, yet the work to actually do that never seems to get done.

This isn’t because everyone in the company is incompetent.1

In my experience, the problem is rarely incompetence. Instead, the problem stems from leadership2 missing the Big Problems and burning all available time and energy chasing little problems — which are really just the visible symptoms of the Big Problems.

Leaves on dirt.

Credit:Wes Hicks

What do dirt floors have to do with skipping school?

Let me veer off into a seemingly unrelated story to illustrate a point: imagine you’re tasked with getting kids to show up to school. If we approach this from a standard business angle, we might start by looking at the education system: is the curriculum engaging? Are the kids being supported? Can we incentivize attendance somehow?3 Maybe we should look at the buses and other transportation?

And if those efforts failed to improve attendance, we might throw up our hands and call the kids unreachable, or blame their parents and community: “Look, we tried! These kids just don’t want to learn! These people don’t value education!”

The schools, though, are only one part of a much more complex system. The kids going to school are part of a community, and that community is impacted by countless other variables that aren’t visible within the context of the schools themselves.

However, if we take a step back and look at the system as a whole we might start asking different questions:

Do these kids want to be in school? (They do.)

Why are they missing school? (They’re sick.)

If we slow down to ask questions before trying to fix the problem, we can see that the problem we actually need to solve is different than what we assumed at the start. This starts a deeper line of questioning.

Why are these kids sick? (They have parasitic worms and other infections.)

Why do they have worms? (They live in houses with dirt floors.)

Through this line of questioning, we’ve discovered a deeper problem. And it leads to a solution that might seem nonsensical at first: “if we want more kids to attend school, we need to address the dirt floors in their houses.”

But the data supports this: deworming children reduces absenteeism at school by about 25%, and replacing dirt floors with cement reduces parasitic infestations by 78%.

Where are the dirt floors in our projects?

In my experience, every organization has at least one “dirt floor” problem.

When I was a front-end architect at IBM, my team was supposed to be improving the performance of several problematic UIs. As we started our research, we realized that there was more than just front-end development involved: our teams were burning a huge amount of time and energy struggling with seemingly unrelated tasks4 — by the time they got to performance tuning, they were already stressed out, exhausted, and up against looming deadlines.

We couldn’t just say, “Hey, team, focus on performance!” They would agree with that — we all knew performance was what we’d agreed to prioritize. However, after spending multiple days fighting with all the unrelated-but-unavoidable work, there just wasn’t enough time or energy left to do the job properly.

Before we could fix our performance problems, we needed to fix our dirt floors. We built a few small, internal utilities to remove that frustration: a one-click configuration tool for development environments, a helper library that eliminated a bunch of busywork, an improved data layer to make it easier to understand what was going on.

Once we fixed the dirt floors, we started making incredible progress on timelines that seemed bureaucratically impossible.5

By dedicating time to correcting the underlying problems, we went from every developer in the organization wasting multiple days setting up their development environment, to a couple developers spending a week building helper tools.

We slowed down, fixed the root problem, and as a result saw sweeping improvements across our entire organization.6 Our developers were able to actually focus on the performance of their project, and other teams were able to work on their actual goals instead of yak shaving7 for days to get there.

Where are your dirt floors?

What problems might be at the root of other problems in your career? In your life? What are you ignoring that might be at the root of your other problems?

Take a few minutes to Find the Why behind some of your biggest frustrations, and see if you’ve got some dirt floors to get rid of.

  1. Yes, yes, I know that your bosses and coworkers are all idiots. But that poses an interesting philosophical question: if a company is operated by incompetent people who only hire other incompetent people, what does that say about you, the person who was also hired work there?

    It seems more plausible that the people you work with are pretty good at their jobs, but aren’t prioritizing the things you want them to.

  2. In at least one of these scenarios, leadership was me.

  3. Beyond the traditional incentive, of course, which is, “If you graduate, you never have to come back here again.”

  4. An incomplete list of things a front-end developer inside the organization needed to do before they were able to actually start working:

    • Learn where multiple code projects lived
    • Install each of those code projects
    • Find the developer who built the project to ask why it isn’t working and get help troubleshooting it
    • Install networking software
    • Configure that networking software
    • Find about a dozen secret keys and other credentials that weren’t documented anywhere
    • Wait for Chuck (not his real name) to get back from lunch so he could restart the service that had locked up
    • Read through hundreds of lines of undocumented code to figure out what the hell was going on in the first place

    This isn’t a problem that’s unique to IBM.

  5. It’s an incontrovertible law of business that the timeline for a project increases exponentially by the number of people who have to approve it.

  6. This embodies a value where I work that we call “going slow to go fast” — before acting, take a minute to think things through, plan, and then act. Otherwise you risk doing the wrong thing and wasting a bunch of time chasing the wrong problem.

  7. “Yak shaving” is one of my favorite developer colloquialisms, which means “all the work you have to do before you can start working” — imagine wanting to mow the lawn, but finding out that the lawn mower is out of gas, then realizing you don’t have a gas can; those trips to the hardware store and the gas station are the yak shaving required before you can do the real work, which was to mow the lawn.