How can you take a bunch of T-shaped developers and upskill everyone to be a 🟩-shaped developer?

You might know a few ways you can do this already:

  • Knowledge sharing sessions
  • Pairing/Mobbing
  • Giving regular, honest feedback

You might know why it could be a good idea:

  • Employees want to be empowered
  • Learning, teaching, and broadening horizons can be rewarding & fun
  • Reduced “bus factor”

But what would something really extreme look like? Enter: “Rota Driven Development” Note: You might even want to experiment with this setup if you already have pairing/mobbing as your main way of working. Otherwise, this might sound quite terrible! But let’s see how it might be valuable. This post isn’t about why pairing is good or bad - but what an extreme variant of it could look like

Illustrative example

Let’s say we have three developers:

  • BackEnd expert (B), with a bit of Cyber (c) [Bc_]
  • Cyber expert (C), no other experience [C]
  • FrontEnd expert (F), with a bit of BackEnd (b) [b_F]

When you pair these developers, they’ll level up by working on tasks together:

  • [Bc_] + [b_F] -> [Bcf] + [B_F] (let’s say the BackEnd expert didn’t share much on Cyber this time)

  • [B_F] + [C] -> [BcF] + [bCf] (they worked across all three topics)

  • Already, the team is becoming much more well-rounded. Everyone has picked up at least the basics of every field.

Of course, it’s an extreme example. More realistically, there could be many domains (framework, syntax, literally domain knowledge, etc.) within any of these three fields - so it can still make sense for e.g. BackEnd developers only.

In a real team, there would probably be a few more people as well - so everyone can Always Be Transferring Knowledge

Your team’s “skill matrix”

To find out what some quality pairings would be, you can make a shared table of people and how they feel their skills are out of 5. It should highlight gaps, and if you update it few weeks/months you use it to track progress.

Planning work for maximal learning

In “second language acquisition”, there is a theory called “i+1”: To have a smooth, low-stress learning environment, you feed someone content that is slightly more complex than their current level. In other words, don’t throw people in at the deep end. If you can estimate the complexity (via story points or some other metric), you could combine that with the skill matrix to optimise growth in your employees’ skill set.

But tickets and rotations don’t line up nicely

There’s a few approaches you could try:

  • Set pairings for a whole sprint
  • Set pairings for only the first ticket in a sprint, and then let people self-organise

How can my team see if this works for us?

  1. Check if your team is even interested in such an idea
  2. Make the up-front investment (skills matrix), and continued effort investment (changes to planning/ticket preparation)
  3. Run a trial for a few weeks. Maybe run a retro on the rotation process, and iterate if you see value there. Scrap it and move on if not.

Conclusion

For teams that have already bought into pairing and want to try a more focused approach to maximise their learning: “Rota Driven Development” could be an interesting experiment to try.