Enabling the mycujoo tech teams to successfully deliver
“A lot of people, when a guy scores a lot of goals, think, ‘He’s a great player’, because a goal is very important, but a great player is a player who can do everything on the field.” — Pelé
It’s been a couple of weeks since I started as Director of Tech for mycujoo. Since then I found a tech organisation in which a lot of motivated engineers worked tremendously hard to deliver value to our customers. It became obvious we were not delivering as much (and as fast) as we could. It was not because we didn’t want to; everyone was eager to deliver. It was mainly because the teams were not adequately set up for success.
The issue of functional teams
The teams in mycujoo were structured after a traditional model, in which different functions were grouped together. There was a mobile team, an web/API team, a DevOps team, an UI/UX team and a product team. The reason for this was that the team in mycujoo grew from a small (cross functional team) into a larger team. And as such it made sense to separate the different functions by specialisation. This allowed those teams to work together on the same area (and thus with the same tech, tools and processes). Although this seems to be a sensible approach, by definition it leads to a problem in delivering.
Lack of agility or ability to deliver
All the teams depend heavily on each other to deliver a feature end-to-end. Which means that delivering a feature on our mobile app would need to be discussed with the mobile team. During those conversations, the mobile team would identify they would need functionality and API endpoints to be delivered by the web/API team. In turn the web/API team might have a dependency on the DevOps team, as they would need a new database. When one of the dependent teams (web/API or DevOps) delivers, there might also be small bugs or refactors needed. That would in turn take days (or possibly up to a sprint) to fix. Considering the above, it will take a considerable amount of time to deliver the actual feature to customers.
How do we solve the above with cross-functional teams?
The above problem with delivery comes mainly from having different teams, with their own priorities. The time it takes these teams to both capture the requirements and subsequently deliver, results in an increase of delivery time. When we realised the above was the main issue with the teams, it’s only a small step to change the structure of the teams. Instead of grouping the functions together in one team, we decided to split them within domains we have to deliver on. In our case, it meant creating a team around the features that enable our partners to create video content and a separate team around the consumption of content. As we wanted to reduce any dependencies on other people or teams, we’ve created teams with all required functions: back- and frontend engineers, UI/UX, DevOps (where necessary) and a product owner. As all those functions work off the same prioritized backlog, there’s only one conversation about the requirement. After this the whole team will work on the same feature at the same time. When there is need for more conversations or whenever refactoring is required, the team themselves are set up to do this. This will allow the teams to deliver a lot faster than they have been.
Additional benefits of cross functional teams
Shared purpose
On top of the increased agility above, there are some other benefits of creating the cross functional teams. As said above, the whole team works on the same stories of the same backlog, of the same roadmap. This also means that every member of the teams shares the objectives and goals of the team, and as such a shared purpose is automagically formed. Having a (shared) purpose usually means people are more motivated and will feel more attached to the features they deliver.
Increased accountability
In mycujoo we also give the teams a lot of freedom on how they solve the challenge we ask from them. This means that the teams are (and feel) empowered to use the technology or tools they see fit to solve that challenge. By feeling this empowerment, they also feel more in charge of their own success and more proud of the product they work on. It also increases how accountable the team members feel about their product and will result in a higher quality and stability of the product.
Challenges of cross functional teams
Although the above might seem to be the holy grail of setting teams up for success, there are also challenges to overcome when doing so. One of the biggest challenges is to make sure that the different functions which are now in different teams are still sharing their ideas, experiences and opinions. In order to accomplish this, we will start creating different types of communities. More about our efforts to create these communities in a follow-up blogpost!
