Own it for the long haul

Its been almost 10 years since Y2K so I guess a lot of people reading this were not yet in the workforce at that time. It was an interesting node for the software development role: a combination of incredibly boring work that was incredibly well paid for a short period of time.

Y2K was really nothing unusual for me because at the time I was at the dead end of a product line, holding up the fort while the company developed a replacement. Maintenance was my mainstay so checking and re-checking for unintended rollover effects fit right in with the plan.

Two things about my Y2K experience are worth explaining so I’ll pack ‘em both into one episode and spare you the cliffhanger.

The first of the two was something we called project Gauze. Back then we were constantly thrashing over the support call logs trying to figure out ways to reduce costs (thereby increasing profit margins) on the help desk. It is frustrating to fix defects that late in a product lifecycle because clients don’t want to incur the cost (pain) of rolling out updates, especially when they can call the helpdesk at no additional charge. Y2K updates, however, were widely anticipated to touch every installation. Governance auditors and other paperwork leeches created a fin-de-siècle culture of fear and charged big bucks to ensure compliance. If we could inject some support call fixes into the Y2K patch, it would make the whole thing have a positive impact on our customer’s experience, and our costs.

Of course there were arguments against this idea. The main one was the catch-22 scenario whereby we could poison the Y2K upgrade by introducing new insurmountable problems in the release. We fought that one off by making the whole thing modular, meaning we could pick-and-choose what to roll out. The other argument was that we needed to tell clients what we were doing, and they would say “no” to the risk. That one, like much other speculation about client responses, turned out to be unfounded. Most any client will provide a reasonable answer to a request if the person asking is trusted and empowered to do the job right.

Gauze made a huge difference. We dropped the call volumes by about 40% on a product that pretty much everyone had thought abandoned. The added stability extended the life of the product, resulting in a few more years of lucrative maintenance fees and headaches for our competitors who predicted the product’s demise prematurely. The lesson? A new idea can take hold even when hundreds of people with established processes across many departments in a big business have to be convinced. Its not easy and the idea has to pass a lot of scrutiny but stick to it and make it happen.

The second Y2K notable was fast by comparison. The CEO called for everyone to join in and sit a shift or two on the help desk as midnight rolled around the world. So much for my 1999 new year’s eve. I had taken support calls during the early days of the product but ever since it got big and was pushed into thousands of sites, the help desk operation was a complicated machine that I knew nothing about. December 31of 1999 was an eye-opening experience for me. The tools and utilities that I had written years earlier to diagnose and fix problems were still being used, bugs and all. The knowledge that I had shared with the first few people we hired full-time onto the help desk had been immortalized in a sort of repository that was consulted and interpreted quasi-religiously. Procedures that I had conceived quickly and never optimized were being repeated thousands of times with exacting detail.

It was frustrating to me that people managing the help desk would not build their own tools and improve their troubleshooting processes. But then it dawned on me that the mistake was mine. The help desk is an operation that exists to scale and implement processes with a guaranteed service level and profit margin to the business; they are not responsible for re-designing the product. Arguably they could have invested in some development but would the company have allowed it? I don’t think so because anyone doing good development would be re-assigned to work on products.

The lesson here is that you have to build in care-and-feeding tools for the runtime-operation of a product. You can’t go overboard but you have to do something and stay on top of updates for the tools as the product matures. Otherwise, you face the mounting costs of hordes of people trying to fix problems that you (or your team) caused. When you emerge into a leadership situation, this is the kind of tough message that you have to enforce; it won't be popular with inexperienced people from any department but it will help you build a solid career of long-term successes.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozens of other use cases for leadership. Please see more at www.youdotnext.com.