Outcomes, not codebases

One of the greatest challenges in setting up a Product & Engineering org to succeed is the team structure. Team structure dictates the collaboration that can be fostered, the bottlenecks that can occur and the ability for teams to run autonomously without stepping on each others toes and cannibalising product strategy efforts.

To complicate this, there are multiple ways to setup teams — for example there’s the much publicised and overly adopted Spotify model, there is arrangement around subject matter expertise (e.g. codebases), there are pirate metrics (AARRR) and then there structuring them in a manner that enables your very unique org to be successful and not treated as a cookie cut team — I’ve frequently plumped for the latter because lets face it, your org is unique.

It wasn’t always like this though — I’ve inherited orgs focussed around codebases the majority of the time and while it makes it easy to pigeon hole colleagues into functional silo’s it rarely creates the outcome desired — which is around the customer. A cursory search on Google reveals a volume of literature that instructs, educates and coaches organisations on being customer centric. If the internal teams aren’t setup to think about the customer, then why would the outcomes they strive for produce an outcome for the customer?

A Google search around focussing on the customer — pretty popular reading.

Organising around codebases also leads to shared responsibility, people tripping on each others toes and accountability gets lost somewhere down the line. It’s not clear who owns what outcomes and when there is a question to be asked it’s also not clear who can answer it succinctly. In an automotive marketplace for example with a website and native apps — who owns the car buying persona? Website or native apps? The answer is both, which is a problem.

The Spotify model has rarely crossed my mind when setting teams up to succeed. I know others in the industry who have adopted it because it seemed like the right thing to do and squads, tribes, chapters and guilds are part of every recruiter’s vocabulary these days — but that’s not enough of a reason. From listening to a few talks about it there are also a few rumours swirling around that it’s actually a marketing ploy and was never really used internally there. Jurriaan also makes a few great points about whether the model transcends verticals that aren’t music and whether or not the trade off of full autonomy is worth the adoption.

Something I do believe strongly in however is co-ownership of team outcomes between product and engineering and deep focus on the customer with customer outcomes front of mind.

Credit to Rich Mironov for articulating what end-to-end ownership looks like.

Layer the above structure (with the key part being frequent, in-depth, non-sales learning conversations with the customer) against a matrixed, cross-functional team (DevOps, Engineering, Design, Data) and you have a team that can own their own outcome and be successful in achieving meaningful customer outcomes.

Next time you’re wondering who owns what outcome and why it’s important for the customer, irrespective of whether you’re in the B2C or B2B game take a look at the way your teams are setup. How they are setup dictates team focus and what the teams focus on dictates which customer outcomes you are able to deliver on — and since businesses exist to serve customers this is the only outcome you should be organising for.