A Day in the Life of a Senior Leader

Chapter 32. Three Mistakes

A few yesterdays ago, I made a call. We needed a major rearchitecture of an application. This long-in-the-tooth project was in dire need of an update to its indexing engine. Every bug fix against the existing code was duct tape. When we did code reviews on these fixes, there was visible discomfort from everyone involved. “It works, but…” But what? “But this hack might be one that causes the whole fragile system to collapse.”

The full story is for another chapter at another time. The point for this chapter is that it’s incredibly difficult to get approval for fix work that:

• Doesn’t present an obvious user impact

• Isn’t a current fire

But we did it. We convinced the powers that be to assign three engineers for an entire product cycle to address this core technology. Off we go.

The first signs of the problem appeared at the end of our first of three milestones. Not only were we wildly outside of the planned schedule, but the engineers responsible for the work had the same expression on their faces we had when we patched the prior version of the engine. “Yeah, we’re making progress, but…”

I should have asked, “But what?” But I didn’t. That was mistake #1.

Mistake #2 was at the end of the second milestone. We were still way off schedule, and the expressions of the engineers hadn’t changed. I’m going to jump to the punch line right now and tell you that, obviously, we significantly underestimated the work. What was scheduled as a year of work was closer ...