Power of Shifting Left

There’s a concept you find in a lot of domains about how valuable it is to find problems earlier in the process.

  • In software engineering, engineers are taught that the cost of a bug goes up exponentially the longer is exists — it’s cheap during a requirements gathering meeting to clarify something, or ask how A related to B; but it’s dramatically more expensive to fix something in production
  • In counter-terrorism, people sometimes refer to Left of Boom to refer to how critical (saving lives critical!) it is to solve problems before (on the left-to-right timeline) an explosion
  • When you’re writing a long, complex document (like a detailed proposal for a customer), you can save an enormous amount of time by fighting the urge to start writing, and instead carefully craft an outline, and then a few key, organized talking points by section (bullets, not prose), and then layout key graphics, and then start writing the actual prose

Similar to this, I often use the metaphor of the desire to mature the teams I work with so they can spend more time “upstream”, acting like a smoke alarm, and less time acting as a firefighter. While it’s fun to jump into an emergency and be needed and important, it’s critical not to enjoy that so much that you fail to mature your organization you need fewer firefighters and instead spend more time on smoke detectors. For example, instead of staffing a teams of people who wait around for a software engineering project to fail and then jump onto the project to ‘put out the fire’, it’s dramatically better, cheaper, and less stressful for you and your customers to instead proactively identify, quantify, and monitor risk throughout a project to reduce the risk of needing to pull the fire alarm.

How can you mature your role, or the role of your team(s) to be more proactive and less reactive? (Don’t assume you can’t — think about how you break that cycle.) For example, should you invest time in a monthly discussion of risks? Or setup templates and meetings to plan new initiatives/projects and how to launch them consistently and effectively? Or should you ask your customers for feedback earlier in the process, before they may become even more frustrated over something you could have fixed earlier and avoided huge frustration?


  1. Hey Tom, I’m a fan of using recurring meetings (e.g. retrospectives, monthly process improvement meetings) or reminders (e.g. monthly email reminder to reflect on areas for improvement/automation).

    It’s also powerful to think about this in meetings when you’re struggling with a problem, and thinking about fortifying (e.g. adding redundancy) to your procedures instead of trying to attack the root of the problem (instead of adding a double-check to a procedure, how do you instead design the trigger/system to more likely set people up for success?)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s