Ownership = Fast Delivery

Michael Carr
Jul 20, 2017 · 2 min read

How many times have we tried to speed up delivery with faster deployments and dealing with tech debt? Has it worked? Does it really make that much of a difference when adding to your product? To a point it does, but there are bigger wins that refactoring your booking logic.

I’ve seen businesses struggle to agree and release simple changes that take minutes to fix. The leadership will argue back and forth around wording and logic flows. The engineering teams wait, twiddle their thumbs with content people have to sit and review before pushing their change live. In these scenarios is improving your release pipeline time going to make the big difference? Nooope.

A tale of two search result pages

I’m going to talk about two different business, both working on improving search results

The first company, let’s call Agile Corp, is about searching and delivery results to it’s customers. They see themselves as a lean, bleeding-edge business at least in regards to lean and technology. However for the past six months they have been slowly changing search results, granted there is an on-going mammoth refactor but when they are trying to release changes and measure the difference there seems to be politics at play.

The team doing the work don’t own it, they aren’t scrutinising the data. They don’t own the project — the “product owner” does. So, the engineers come in, write their code and their tests, ship it, pick up the next ticket. There isn’t much ownice on “did my change make a difference?”

The next company, Startup X, again is about delivering search results to it’s consumers. They base their tickets on trying to change a specific metric. They analyse the problem e.g. “Bounce rate is too high”, try to explain why that is, write down possible solutions, pick one, implement and release. This is all done in 45 minutes.

The key difference is ownership. Startup X own the product they are working on. They have full access to Google Analytics, they understand the metrics they are trying to change. Agile Corp, the engineers are so far removed from the problem that they don’t feel that ownership. “Product Owners” cannot be the ones driving the project — it has the be the full team, and if they product team and engineering team are in different locations, the slower the delivery.

The take-away

Teams need to be breathing analytics, every-day. If they aren’t, they won’t know if their work is creating any value. Yes, their code may be beautiful and complex, but if it isn’t changing the business metrics like revenue then it’s a waste of time and money.

Teams need to be given more ownership of the business objectives, and allow cross-functional teams to own a problem, not just for the quarter but until the problem is solved. By having teams taking ownership, they can identify problems and offer quick solutions in the same day.

An action to try out

Why not try a Monday analytics session? Get the team talking about what’s going on with the metrics on a weekly basis.

)
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade