I recently came across this great post – Unlocking Data with Durable Teams – by Anna Shipman, Technical Director for Customer Products at the Financial Times, about moving from a project or initiative focus to one based on product or service ownership. High performing digital teams are increasingly organised by product, following the lead of startups and Silicon Valley giants. Product focus, with clear product ownership brings a number of advantages over traditional IT project-led approaches, not least around responsibility. If you build it or change it, and it breaks, then you fix it. One area that has not received enough attention though as an advantage concerns technical debt.
According to the post:
Orphaned technology is an operational risk that you don’t know about yet.
If the team is disbanded to move onto other projects, the technology they have built often does not move with members of the team to the new project. For example when the podcasts team disbands to work on other initiatives, none of the work they’ve done may fit into the new teams.
This is a problem waiting to happen; it is a security and operational risk. Without ownership of tech, if any future development or maintenance is needed, it may be hard to find someone who has time to do it. In some cases, everyone who worked on a project may have left the company.
Even if no security risks arise, it slows things down. If an unowned piece of tech has outlived its usefulness, there won’t be anyone to take care of decommissioning it, meaning that over time your tech stack gets clogged up with code that is not adding value but is adding complexity and slowing everything down.
This is exactly right, and a growing trend. We’re even seeing very traditional IT organisations, including those for example in UK Civil Service departments adopt similar service led approaches. You literally can’t afford to have orphan technology in your organisation. If it doesn’t have a service owner it should be decommissioned.
I was talking to a UK startup called Iotics, specialising in federated data integration, this week that talked about one of its clients that had an Oracle database in production, but didn’t know what it did. The client literally had no idea which applications or services touched that particular database, so they had to keep paying the license fees and were simply afraid to turn the database off in case it broke something important. This kind of scenario is all too common. In a post ITIL world we can’t rely on the fabled configuration management database to help us here. The alternative is to refactor infrastructure, code bases, and teams around service ownership, or as Anna describes it, around “durable teams”.
As Anna argues:
We can create teams that between them own our entire estate. Each team can take responsibility for the strategic direction of that area and kill things that no longer add value. We will no longer have unowned tech, which leads to security and operational risk.
For an excellent discussion of technical debt in financial terms please read this excellent post by my colleague Rachel Stephens (TLDR – it’s not always bad, rather it’s a business issue to be managed).
I am increasingly contextualising digital transformation in terms of product management. The most successful digital companies are successful because of their focus on, and way they are organised around, product management. See the structures of Apple, AWS, Netflix, and Google for example. Product management is the real differentiator.
I recently talked to Optimizely about this trend in a joint webinar.
What makes these FANNG companies so successful when it comes to delivering great products and services? One of the commonalities between these companies is that they all have strong product development teams and product delivery processes. These teams often have tight-knit, collaborative groups of engineers, product managers, designers and analysts that are all in lock-step when building products and services. There is deliberate focus on how teams are set up such that each has complete ownership and are able to define and manage software delivery in a data driven manner with the right controls in place.
Optimizely is a client. To watch the webinar sign up here.
Irit Gillath says:
May 5, 2021 at 1:57 pm
We at Pillir see this scenario quite often where SAP customers have custom code built over the years around their core system, they have no idea what it does, what is the business logic behind it but they are too afraid not to keep maintaining it. This becomes even bigger issue when looking to migrate to newer technologies and have all this technical debt resulting of customization.