I recently joined Co-op Digital as a Tech Lead in Co-op Funeralcare. The team I’m working with is a true multi-disciplinary team including UX specialists, subject matter experts seconded from the wider business and even a dedicated user researcher. It’s a talented and varied group of people. You can read more about what the team have been doing in the past 9 months before I arrived on the Co-op Digital blog.

In common with the other teams in Co-op Digital, the team I’ve joined is well set up to do Agile product development 2017-style as opposed to water-scrum-fall or other broken variants you often find out in the wild. It’s still a bit of a culture shock for me in some ways since, although much of my work over the past 10 years has been working in organisations that have been attempting agile transformations, they have rarely had the top-level support that allows a critical mass of people who “get it” to be assembled. I’ve been impressed with the attitude and abilities of the people I’ve met in the wider organisation including engineers from other digital teams, specialists bridging into the existing IT organisation and the senior leadership in the digital space.

I’ve joined my team at an interesting time (for once it’s not like the apocryphal old Chinese curse 🙂 ) since the service we are working on is entering a new phase . During this phase it will have wider exposure through the business as we continue on the journey of proving benefit and adapting as it heads towards a fully-fledged service used across the whole organisation. From my perspective as a Tech Lead, I have a lot of the interest in the level of debt accumulated so far. Various forms of debt inevitably accrue during the initial phase of founding a digital product or service. A large part of that first phase is about proving the value of building the service and getting something tangible into the hands of real users who can validate or disprove the myriad hypotheses that are built into the service as it evolves. It is vital to deliver working software to gain trust and prove that you can deliver on your promises. When you’re doing this in a large organisation which has worked in a more traditional way, it is sometimes characterised as the “move fast and break things” phase.

You might split the types of debt that can be accrued into four types:

• Technical debt. This is the obvious one. When people say “technical debt” they are usually talking about issues with the software developed to support the service. The problem is that most of the things described as technical debt are usually just bad implementation whereas the original concept of technical debt was of intentional decisions taken to defer work you know you need to do in order to gain some benefit such as wider trust or belief. Often paying down this debt takes the form of cleanup or larger refactorings that will make subsequent development easier and hence quicker.
• Infrastructure debt. As a service is evolving, decisions will be made about the platform and infrastructure used to underpin the application software. Loads of stuff will be learned especially when you have multiple teams firing up in parallel. An organisation must balance delivery with consistency across those teams that are employing commodity cloud components. Over time technology evolves and patterns emerge that suit the specific organisational context so you can start defining a commodity platform within the organisational context. This lifts some of the burden off the service delivery team since other people can pick up the construction and operation of such a platform. However, unless you are really lucky, the platforms evolved by the service delivery teams will all be different from the evolved common platform so some remedial work will be needed to get each team’s service onto this common platform.
• Relationship debt. Part of the challenge of changing “the way things are done round here” is how to work with the existing organisation. That existing organisation consists of people who are, for the most part, doing really important work including keeping the lights on for the systems that currently support the business. However, because such work tends to value stability and predictability, it would be very easy for the teams doing things in a new way to see the existing organisation as getting in the way of change. Conversely, resentments can build up the other way if it’s perceived that the new teams “get the glory” while the existing organisation is effectively bankrolling them. Even if this is well managed, it is inevitable that antagonistic situations will arise as what feels like the irresistible force of the new teams hits what seems like the immovable object of existing rules, procedures and governance. Some people will end up with their noses out of joint on both sides of the fence (for any given values of “noses”, “joint” and “fence”) but if that bad blood persists it will put at risk any gains from the work so far. An effort has to be made to address legitimate concerns and build a way of working together on an ongoing basis to allow a form of “rolling governance” around the new service that allows for frequent delivery into production.
• Cultural debt. If you are changing the way things are done then almost by definition the skills you need aren’t found in large quantities in house. To bootstrap efforts you need a critical mass of people who understand the new way of working and have experience in working that way. Consultants or contractors provide a quick way of bringing in this experience but to make the change stick you need to gradually blend in permanent people. Part of the challenge is then to reshape the culture as you go. These new people may need to pick up domain or technology context in order to be fully effective and they will definitely need time to learn the shape and structure of the application/codebase. There will be a need to (re-)form a shared understanding of the system and the team way of working. This may need more pairing, some explicit training, time to study the system, etc. If the early phase of the service’s life needed periods of intense work to gain further backing, in later phases the team will need to learn how to work at a sustainable pace to deliver a constant flow of value on an ongoing basis.

OK, so you may need to address some or all of these types of debt, but it’s highly unlikely that you will be given the opportunity to take a long break to rest and re-stock. Any repair work has to be done alongside ongoing development of the service which will now be rolling out to a wider audience who will provide more feedback and suggested improvements. To get those improvements out to them rapidly you will need to have smooth governance processes that allow you to deploy into production frequently. The live service will also need supporting; fixing defects, scaling capacity and improving support for operational processes. There will be lots of work to do alongside your delivery duties.

You might describe this as the “move fast and fix things” phase. This is the phase I’m landing in now. I’m not sure which of these types of debt I’ll have to help to fix but I do know it should be an interesting time.