Add skills not people to your cross-functional teams
Balancing roles vs. skills in your cross-functional teams.
Balancing roles vs. skills in your cross-functional teams.
TL;DR — we know from Brooke’s law that the more people you add to your team, the more communication pathways there are and the greater impact it has on trust levels (see Dunbar’s work etc.)
Communication overhead increases as the number of people increases. Due to combinatorial explosion, the number of different communication channels increases rapidly with the number of people. Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing. — Wikipedia Brooke’s law
A cross-functional team should have the necessary skills needed for the regular delivery of customer value. If your teams end up having lots of individual contributors where work is handed over between the people in the team to each other, you are not likely to be able to increase flow. This is where bottlenecks arise and if you are not careful, teams end up starting too much work out of fear of not being sufficiently busy.
It is hard for organizations to let go of being ‘busy’ and instead being ready to swarm around work and pair together. This is often due to people having come from a background or education where optimizing for cost and resource utilization was seen as a better measure than have spare capacity that is used to create fast flow and respond to change.
One of the common behavior anti-patterns is where people want to hire more people / experts to do work, rather than learning how to prioritize and sequence work so that teams can learn to do it themselves. Often teams are super competent and just need a nudge and some capacity to pick up some new skills. The challenge is amplified by managers who aren’t willing for people to free up capacity to slow down and learn something new.
A lot of product development work is complex, we build things we’ve not built before. Learning by doing, is a way to quickly acquire those skills (task based, broader skills take longer time and more specific learning / deliberate practice).
This is where the notion of an enabling team from the book Team Topologies can be helpful. Rather than experts going into a situation and doing the work for the other team, (this applies to contractors as well), the enabling team can do in and help the team and effectively teach them to ‘fish’ rather than simply giving them a fish. People often say that they want ‘a fish’, when they mean they don’t have the capacity to learn something new or they aren’t confident to learn the new skills themselves.
Another practical solution (if someone else in the team has the necessary skills) is to pair and cross-skill and the pair work together and learn from each other. This not only increases trust and cross-skilling it allows the pair to build quality into their work since there’s two pairs of eyes looking at the work, rather than one. For example, if you have a tester, have them pair with a developer so they both learn and build quality in, they can and should take turns coding and writing tests. That same ‘tester’ should then work with other developers in the team, so they can share and learn across the team. That way you end up building a stronger mesh of skills within the team.
A typical composition of a cross-functional team is product, delivery, and engineering (gold star if you have design / UX).
If you hear someone say ‘Only person X can work on that’ then you know this is an opportunity to learn. Warning - apply pragmatism, clearly not all skills and capabilities can be easily / quickly acquired or transferred. A lawyer cannot easily become a surgeon and vice versa. An engineer and a tester may be more likely to learn from each other. Another perspective is that the lawyer and surgeon may not require the full set of skills to do the work, they just need enough to get some more repetitive work done. So, both roles would still be required but one person could take on some of the other person's work if needed. That wasn’t a great analogy, hopefully you got the point.
Learning from your own team and often outside of your team too (think team of teams etc.) is a brilliant opportunity to pair up on work and have the less knowledgeable person on a given task take the lead and the more experienced person work with them to pair up.
This way you are building up knowledge with support and not falling for the ‘bus problem’ (what happens if person X gets hit by a bus). You also have a safe pair of hands to guide you, so you aren’t on your own.
Teams get stuck on work waiting for other teams all the time. That leads to teams and individuals within a team to start new work before they finish what is already in progress.
Stop starting, start finishing!
Outside of your own team, you might be relying on a skill set from another team — which can be for many reasons, sometimes skills, other times due to specialization or access (e.g. the Database Administrators). This is another opportunity for your team to find the team they are waiting on and help them with the dependency, dependencies come in many shapes and sizes as I’ve written about before. That database administration team may not have the capacity to invest and automate their services so if you go and help them, you may also be allowing them to get additional capacity to further automate their offerings. This is how dependencies can be resolved and how collaboration happens instead of a culture of blame.
You might depend on another team for many reasons: knowledge, tasks, or resources — analyzing your blockers and known dependencies will allow you to plan for them, ensure the other teams are ready for you when you need them and can be resolved through collaboration, simplification, skill acquisition or automation.
We release quarterly because it takes too much time and effort to do it faster. I’m not sure who said it first ‘if it hurts, do it more often’, I’ve heard Martin Fowler and many others say the same. (it also features in the book Continuous Delivery by Dave Farley and Jez Humble)
This is often a symptom of large batch sizes and lack of quality being built into the process, so it is all pushed to the right at the end of the planned release. This is when re-work occurs, bugs crop up and quite often the developers have moved onto new code, which means they’ve forgotten the context of the code.
Reducing your batch size and releasing code more frequently is how you reduce and impact of your release.
You don’t need to be a magical DevOps unicorn to do this, making minor changes and building quality as you go, will allow you to improve your coverage and quality as you go.
“I didn’t have time to write you a short letter, so I wrote you a long one.”
— Mark Twain
Before you start complaining that the teams now have too many things to learn, you are in fact correct. This is where Team Topologies helps yet again, with a clear focus of empathy to the teams and leveraging the notion of cognitive load. Teams should have the necessary skills that they need to deliver value, if there’s a lot of skills required to get something out the door and into the customers hands, that is potentially an opportunity to look at a platform-based approach where you can take complicated activities away from the individual teams and solve such problems for a large group of teams instead. I frequently use Cloud provides are the example.
I don’t call up AWS / Google Cloud / MS Azure if I need a server / database etc. I trigger an API based on the documentation and I am up and running in no time (excluding your companies many layers of bureaucracy of course). Condensed version: don’t create platforms that require even more coordination to use them. Platforms should solve common problems and do so far better than an individual team could.
Additional resources
Skills Liquidity — Chris Matts
Situated Learning
Situated Learning: Legitimate Peripheral Participation — Etienne Wenger, Jean Lave
Troy Magennis (thanks to Nick Brown for the recommendation)
Maturity mapping
Maturity mapping — Marc Burgauer, Chris McDermott
Emily Webber
Mapping Skills and Capability
I have loved QCon and I've learned so much about what is hot in the industry, what's coming up next and what are people…www.infoq.com