Busy being busy
By busy, I mean maximizing ‘resource efficiency’ over ‘flow efficiency’— either through overloading teams or people. (see: The efficiency…
By busy, I mean maximizing ‘resource efficiency’ over ‘flow efficiency’— either through overloading teams or people. (see: The efficiency paradox).
I’ve been exploring the nature of teams, cross-functional and whatever the opposite is called (functional?) and the relationship between them (see: Should every team be cross-functional).
If your teams interact with other teams / individuals for support / help, they may have to reach out to those teams on an ad-hoc basis which leads to unpredictable demand and creates a potential tension for when people have enough time to interact.
This creates additional communication overhead not only between the cross-functional team and the individual group, but between the groups themselves e.g. the architecture team and the security team. It also makes it difficult for these other teams to plan their own capacity when demand is unpredictable, this either leads to lengthy delays or people working overtime to help people, either of which are not great for the individuals, the teams, or the organization.
Sooner Safer Happier talks about Safety teams which is a more advanced version of the topic. Effectively it involves creating another type of cross-functional team of experts from various teams / departments who serve a group of teams with related concerns (e.g. a team of teams or beyond).
This allows for trust to increase between the teams, as the relationship will be one of partnership and professionalism rather than chaotic 11th hour escalations for help.
Teams may not need help from a lawyer on a regular basis but may have to interact with an architect more frequently. Whilst you may not interact with every single member of your safety team every week or month, it is important that everyone has transparency of the work (visualized) so that everyone can see what the team are working on and when people should engage (a roadmap, a Kanban board, an Obeya wall etc.).
The implication is that your backlog needs to be written so that others can read it, rather than in cryptic language only your team understands.
If you are in a cross-functional team and improving your ways of working, you will very quickly realize that other areas or experts you need are likely to not be able to work at the same ‘pace’ or cadence of the team. This is no fault of their own, it is simply a way of working and crucially interacting.
Rather than having a huge team with ‘one of everything’, you setup a way to interact with the individuals or safety team on a regular cadence to interact with them so that it is predictable, transparent, and enabling a shared understanding across the people involved.
In some organizations you can imagine each department having their own risk specialist, one for technology and one for operational risk. I’m sure they have some overlap of concerns and need to work together occasionally.
If you bring the distinct groups together and create a shared understanding, you can reduce the need for separate / offline conversations on the same topic.
You can have core team members that really are long lived, and a group of individuals you interact with semi-frequently or infrequently and there is also in between which I might explore in a subsequent article. All of these are valid, what is more important is maintaining the relationships and building a sense of trust so that shared understanding of the domain can be achieved, and you don't end up needing those experts at the 11th hour.
People tend to get annoyed when they are required on a random basis, and it makes collaborations strenuous at best. I’m sure you’ve experienced a team wanting to release software, only to realize they need their architecture to review and sign off before they can go live. The most expensive time to change something (architecturally) is after it has been built and the team are committed to what they are trying to release.
If you had brought in your architect at the beginning, then everyone could have been on the same page and agreed to what was needed at the beginning to then set a glide path for the team.
There are other skills which will vary depending on the nature of the team, the product they work on e.g. a Designer may be needed if you are involved in a user facing product they may act as a long-lived team member on a temporary basis (please hire more designers — see John Cutlers video below).
In summary
If you work with supporting / enabling teams on a semi-regular basis, I suggest bringing them into your planning or review / demo events more often. They don’t have to attend all such events but if they are brought in to support and given guidance on a more predictable basis you are far more likely to have a shared understanding. That shared understanding allows those people in the safety teams to engage with you more effectively and with other teams too.
If they can then see the work, you are doing and how that relates to their concerns e.g. risk story etc. Then you can start to introduce others into better ways of working that are compatible with yours. You never know you may end up finding some allies and form better relationships as a result.