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?