Here's some coverage of our recent deal with Akamai to use their DSA product. iProperty…
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.
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?