One of the aspects that makes working on digital transformation so challenging (but also interesting) is that you have to try many things in order to get some things right. You inevitably try and build things that don’t work (or at least not as well) as intended. And that is fine. Fail fast, fail often, as they say. But what does that actually mean?
Developers use the term technical debt to describe the implicit cost that comes from constantly building new things without taking the time to get rid of old code by refactoring. The complexity of the system grows, moving forward becomes harder and harder. The same can be said of teams or entire organisations — something that has been called organisational debt.
Too many tools, structures, processes — once introduced with good intentions — reduce a team’s ability to focus on what really matters. Any tool or process that is in place commands a bit of attention, even if it is hardly ever used. Actually, something that has no clear ownership, tends to come up in unexpected situations, which makes it even more disruptive when you have to deal with it.
This is how we proceeded:
- We complied a list of things that we once built or introduced — tools, infrastructure, processes — that are not core to what we do and lack clear ownership. We came up with 17 items, ranging from an old tool for creating teaser images from screenshots to a Chrome extension that serves as a workaround to some shortcomings in the CMS.
- We created a spreadsheet with all items, and for each, we gathered information on what it was originally created for, who still uses it and who might have a hard time letting it go.
- All three people leading this effort (Beni Buess, Anna Wiederkehr and I) made an initial assessment for each of the items. We limited our choices to «own» or «kill» — doing nothing was not an option.
- For any item we unanimously agreed to «own» or «kill», we created a task list with the necessary steps to solidify its ownership or remove it altogether. Sometimes this required a conversation with the original creator of the item or simply a review of the things this item has directly affected in its lifespan.
- For those (few) items we didn’t initially agree on or where the next steps were not straightforward, we initiated discussions. We started asynchronously on Basecamp, and cracked the most resistant items in a 1 hour workshop.
- From there, it was only a matter of execution. Migrate stuff, communicate changes, shut things down.
So, how did things turn out?
Most of what we killed was nobody’s darling, which of course made things easier for everyone involved. And we actually had to break with our intention to only either «kill» or «own». Since the three of us are leaving the company soon, we deferred decisions on two items we thought our successors need to be able to have their say on.
Still, we got rid of more than a dozen processes and tools that have distracted us from focusing on what really matters.
Overall, it was a good exercise in letting things go — I think we might have found an appetite for cutting back even more.
If you have questions or have experiences of your own to share, write us @nzzvisuals on Twitter.