The team that learns together stays together

I prefer to build long-lived teams where the same people stay together over an extended period of time. I believe in the immutable team:

Teams are immutable. Every time someone leaves, or joins, you have a new team, not a changed team.

— Richard Dalton (@richardadalton) February 21, 2015

However, there’s also valid reasons for people to move between teams. Two of the most common are to stop people getting stuck “in a rut” and to bring new knowledge into the team.

What if a team could continue to learn and develop in new directions and bring new knowledge into the team? The good news is that they can; and we’ve done it.

One of our teams is a great example of a jelled team. They’ve recently been developing a new app that started out as a prototype built with React Native. Having successfully tested the prototype, stakeholders from outside the team asked them to implement a production version of the app using Swift. The team were primarily experienced in JavaScript development and not native iOS development. The two options were to hand the work over to another team to reimplement or to bring new people into the team to reimplement.

Neither option was attractive to the team – they were engaged with the product and with each other; they didn’t want to go through a process of re-forming and they didn’t want to let go of a product they believed in. Instead we gave the team space to try and find a solution. The team wanted to figure out Swift before suggesting the next steps; they completed some Swift lessons online, built a couple of screens and flows and realised that there was no need to introduce someone else into the team. The production app was built by the original team using a technology that they learned as they built.

When you have a team who are curious to learn and passionate about the product they’re working on, they will do whatever it takes to solve problems. Despite the fact that the technology direction changed, the team wanted to stay together and continue developing the product. If they’d handed over the project to another team or changed the team makeup, we would still have got the app out. But would it have been as good? And, more importantly, would the team who created it still be performing at the same level?

Before you jump to the usual solutions of moving people around, consider – is there a way a jelled team can stay together, learn together and grow together?

Archives