Why we embrace failure

Two of my teams here at Redgate have experienced a failure in the last week, its not a big one, but it was useful to acknowledge it and understand what we have learnt from the thing going wrong.

Its also gives me an opportunity to talk about why failure is a good thing sometimes.

I have two teams currently working on a big programme of work across a number of our existing products. The way we structure our development teams here means we have a technical lead (A very experienced senior software engineer with people management responsibility for their team of engineers) and five to six software engineers.

These teams generally hold responsibility for one or more products cradle to grave. On the programme these two teams are working on they have been required to work much more closely with one another, to the extent of operating in and around the same codebase.

Now normally this would mean us demarcating boundaries for each team to operate in, perhaps something as simple as team A being responsible for web front-end work and Team B being responsible for backend goodness in the product. But here at Redgate we don’t like to create unnatural boundaries in our products or teams, so instead we racked our brains as to how we could have two teams (That’s 12 developers and 2 technical leads) operating in the same codebase.

We had some existing technical debt to deal with and new feature demands coming in which the teams also had to contend with.

So after some discussion we agreed to introducing a new role of Maintainers. These roles would hold accountability for particular architectural decisions, areas of the code or even things such as the programme management of the product (You can guess which lucky person got that one!)

We worked up a description of the roles and responsibilities of Maintainers and even agreed to sit aside half a day per week every week for the Maintainers to spend time together or with some of the development team on working up process and procedures for their areas. This could be something as simple as the rules around how PR’s are submitted to ‘what good looks like’ for PR’s to be committed.

In principle the above sounded like a great idea at the time.

But 3 months on we’re abandoning this role and doing something slightly different.

Why?

Because the role of Maintainer has failed to generate the outcome we wanted. We never consistently formed into groups of maintainers to own areas of the codebase, nor did we produce a definitive list of rules and procedures for the development teams to follow.

And this is perfectly fine in my book.

Instead, what we found is the team used this half day per week to work on operational risk activity — all of the juicy goodness of software engineering that isn’t attached directly to feature development. So things such as technical debt reduction, test creation, removing unnecessary lines of code, introducing better monitoring and tooling such as SonarQube to the codebase and generally making our lives easier.

So, not a complete failure, and if anything we’ve done awesome work without having to brand it as something with a badge of ‘Maintainer’

I love when teams discover failure like this as it always serves a greater purpose. It’s something we positively encourage our teams to experience at Redgate and without fail (no pun intended) we always learn something from these experiments. We’ll try something new, maybe even create a new process or two, some things work, plenty don’t. But the net result of this experiment has been that we found badging a role for something we should just be doing anyway meant the role of Maintainer failed but we still vastly improved our codebase, had some great conversations about how two development teams could operate together in one codebase and made said codebase far better.

So when it comes to failure, embrace it!

You never know what you’ll learn from it