A Simple Method for Fighting System Proliferation and Reducing Technical Debt

Here’s a modest proposal – how to fight the ever-growing list of legacy applications, spreadsheets, reports, customizations, and processes that no one knows how to maintain, but nobody seems to want to get rid of (aka Technical Debt)?

Where Do These Things Come From?

Often they are the brainchild of a Driven, Capable Leader that has a particular metric they are accountable for. This could be high level strategic stuff (decrease Working Capital! … increase On Time Delivery! …) or block-and-tackle operational stuff (track expense exceptions! … monitor critical WIP! …). When implemented, these new processes and tools were absolutely the right thing to do – yes, because the objective was correct, but primarily because they were supported, even suggested, by the Driven, Capable Leader.

Does it matter if they were implemented by the IT group? Not really – shadow IT is a known concept, and agile companies should stay out of the way of these enabling technology efforts – hopefully assuming that the Driven, Capable Leader invests the correct amount of time in support and cross training as time goes on.

Unstoppable Entropy?

Time inevitably moves on, objectives and requirements change – but these apps, spreadsheets, reports, customizations, and processes seem to stay around forever, growing roots into the organizational turf, benignly resistant to periodic efforts to prune. People also change – but these “systems” take on an aura of legend and permanence, and the folks that follow in the founders’ footsteps are loath to spend any time rethinking their set ways.

IT will often launch efforts to reduce the footprint of multiple “systems”, driven by the promise of freeing up resources for the Really Important apps, spreadsheets, reports, customizations, integrations, and processes that are filling their backlogs. How might we break from this cycle?

Congratulations on your New Position

Here’s an interesting approach to try to break free; monitor the personnel changes in your organization. When someone leaves – to take on a higher role (yay!) or move to another company (alas!), it’s quite possible that the Strong Preference for Using (or Strong Resistance to Changing) this particular app, spreadsheet, etc. will leave with them.

Also – the new Driven, Capable Leader may want to do things differently. Yes, it’s typically good leadership style to spend the first 90 days listening and learning (not changing), but the opportunity may be there to pause and question current legacy practice before they get indoctrinated into local lore.

So use this change event to engage with this new Leader – learn about their objectives, the metrics they are accountable for (and what objectives and metrics they will use to drive their teams), and what methods – information-based or other – are important to them. And question all systems – not just shadow IT, but systems the IT department had a hand in creating as well.

Minimal, easy success here will deliver a good opening relationship with the new leader, and a shot at awareness of the IT group’s capabilities and focus. Best case – you can reverse the inexorable growth of internally developed “agile” solutions, reduce the complexity of your environment – and free up resources (money and people) to reallocate elsewhere.