Why we formed cross-functional business teams

Late last year we decided to divide our three development teams and have them join the six business teams. Previously we had a hard time coming up with meaningful OKRs for the development teams. We figured only goals with business outcomes would make sense. Having the engineers work together with business experts in the same teams seemed like the logical consequence.

The previous setup made it hard to prioritize the requests to the development teams from the different business teams. This got frustrating for pretty much everyone involved — especially those whose requests didn’t make the top of the backlog. Today this issue all but disappeared.

We also hoped this would make the business teams more independent and thus allow them to move faster while at the same time allowing the engineers to focus on one area of our business model. This feels a whole lot more like the spirit from the founding days.

The former teams included developers (backend, frontend, iOS, Android), designers and UX experts. One might call those in itself cross-functional development teams. Including business experts seemed again like the logical next step — effectively turning them into cross-functional business teams. From my experience in working with teams in several companies a common progression for cross-functionality tends to be: developers + testers + design + UX experts + business experts — in that order.

Having gained some experience with the new setup, we realised that the choice between specialist teams and cross-functional teams is not black or white, but rather a tradeoff — as per usual.

Pro cross-functional business teams

• no handovers
• faster learning about business
• more innovation
• shorter development cycles
• broadened perspectives through diversity of experiences, expertise and knowledge
• greater sense of purpose by working on the full (or at least a greater part) of the value stream

Pro specialist teams (aka silos)

• get work done more efficiently when it can be described precisely and handovers are cheap
• learning from specialists in same field
• higher consistency of outcomes within silos
• easier agreement with people that speak the same lingo

How to remedy the short-comings of cross-functional feature teams

• use communities of practice (CoP) for knowledge sharing amongst specialists
• express yourself in the lingo of the addressed person when talking to a specialist in another field
• get to a novice level of understanding in the specialist fields of your team mates (“become” T-shaped)

Cross-functional teams rock!
Christina, Online Marketing Manager SEA

By now, nobody is questioning the general setup anymore of having dedicated developers working with business teams. What we have realized though, is that the skills needed within a team is not constant but varies. The need for a UX expert is much higher in the beginning of an epic (a bunch of coherent user stories), than it is towards the end; therefore, the concrete team composition is a choice we have to keep making. As we believe that permanent teams outperform short-lived ones, we are trying to make as few changes in team membership as possible. Having T- or M-shaped people helps with that. But more on that in another blog post.

Image by James Case