Failure and Ultimately Fixing It

I’ve been debating writing this because it requires me to open up in a way that isn’t all that comfortable for me. Specifically, I want to talk about making mistakes and then dealing with the fallout from them. It’s good to talk about this—“Tell me about a time you screwed up and how you overcame it” has been asked in every single management interview ever since the dawn of time. But, while knowing how to answer interview questions well is more theater than reality, it’s good to address the hard questions for personal growth’s sake.

Here’s how it went down. I was juggling many projects, and to borrow a flight metaphor, operating each from about 50,000 feet. That in itself isn’t bad. In fact in my opinion if managers are too low to the ground then they aren’t managing, or are teetering too close to micro-management range. But, and here’s where my mistake was, I didn’t have a timely way to know when I needed to get closer to the ground. The only mechanism was for someone to say, “Hey Scott, how’re your kids? Getting big huh, wow. Oh, you know that year long project that makes up a big chunk of our revenue? Yeah, there’s no way that’ll ever ship. K, byyyye.”

Uh oh. I obviously had a mess on my hands and needed to jump in and coordinate the effort. The specific actions to land that sucker aren’t necessary to list out so I’ll skip ahead to the ending, which was a mixed bag. The thing did ultimately ship, but at a great cost. Many extra, stressful weeks were needed (which meant our bottom line was garbage) but even worse was that there was turnover directly associated with it. People left the company because of this. Ugh.

Failure can be a great teacher, so here’s what I was able to pull from that in the hopes of not doing it again.

Many things went wrong, but here’s where I think my failure was. I needed better tools to know the state of my team and my projects. Word of mouth is a lousy way for critical information to be relayed. It gets changed, filtered, and takes too long to propagate. I want to be clear that the mistake was not that there was a cluster of a project brewing. As long as you have people, you’re gonna get some clusters. The mistake was that it took me too long to see the need to get closer to the ground to coordinate the effort. I needed to be at 10,000 feet months earlier. Had I done that, the actions would have been more course corrections than dire changes. The impact would have been smaller.

The solution to that is hard. Better intel can come from automated reports. Getting reports is easy, but getting the right information out of reports is not. For example, a burn down chart can offer a valuable data point, but if the slope of the graph doesn’t perfectly match the ideal scenario, you can’t immediately parachute in to “fix” things.

Further, any additional processes or tools introduced cannot introduce friction. As a manager you need to reduce that. At one point some years ago I was on one project where every single commit to source control had to have an issue tied to it. There ended up being multiple “Stuff” or “Misc” issues that junked up the system, negating any info that a report could provide.

Fixing a problem like this is gonna take some iteration. It’s like a mini-project all on its own, so don your project management hoodie and get to work. You have stakeholders (your team), and you need to solicit their feedback and understand the problem and what the ultimate solution looks like. And like software, this is never done.

I’m pretty sure this won’t be my last failure. But as I do fail I will continue to seek to understand what my part in it was and push myself to improve. Once I do have it all figured out I’ll be sure to share the results.

Written by Scott Williams who lives and works in sunny Phoenix, AZ. Twitter is also a place.