This week, Lee reflects on different approaches to teaching leaders how to build, support and run high-performance ‘business agile’ teams…
Building high performance teams
Recently, I have been reflecting on how to ‘teach’ the right combination of skills, techniques and ways of working to help established leaders and managers build, support and run high-performance teams that aim to operate some form of business agility model. I firmly believe this kind of small, multi-disciplinary agile team is a key building block of a more self-managed digital org structure that is laterally connected rather than vertically divided. There is also plenty of evidence that when such teams get it right – e.g. when they own an outcome, achieve flow and manage dependencies well – they can create significantly more value, and at a lower cost, than traditional structures in a process management model. A great deal of the leadership development content that L&D functions are comfortable with, and continue to buy, strikes me as abstract platitudes that start from the premise that the key to better teams is all in the mindset and ‘values’ – in other words it is treated as a culture and behaviour issue, rather than structure or practice. As Geoff Marlow wrote in his recent piece about the myth of ‘culture as shared values’:
Not only organisations, but the whole mainstream organisational discourse, is so deeply in thrall to the myth of culture as shared values, senior executives believe that if they define and roll out the right set of shared values, they’ve magically ‘fixed the culture’. So, once the posters with the list of shared values go up on the walls, the illusion that the culture is now on track means there’s zero incentive to attend to what’s actually required to create a future-fit culture.
This approach also tends to have very little to say about how to build a high-performance online collaboration and data sharing environment to support the team, despite the added importance this has taken on for remote or hybrid working. There is also a lot of content that you might call ‘agile methodism’ run by often inexperienced – but fully “certified” – agile coaches whose religion believes that adherence to the language and methods of ‘formal agile’ will inevitably lead to agility. But when you ask leaders and managers what prevents them running and protecting agile spaces for teams, they will often tell you that the mind is willing, but the surrounding process landscape, employee appraisal systems and reporting requirements and top-down KPIs are among the biggest barriers to success. To be fair, there are some decent practices out there that offer more practical (less Gloopy) advice on running teams, such as this short explainer from Nobl. But overall, I can’t help thinking that too many educators and consultants (and L&D teams who engage them) put this in the ‘too hard to fix’ bucket, which is why so many double down on values, mindsets and beliefs.
Photo by Chris Montgomery: https://unsplash.com/@cwmonty
The purpose of a system is what it does
A useful adage that emerged from cybernetics is POSIWID: the purpose of a system is what it does. If an organisational system does not trust people to exercise autonomy, if it ranks people on basic metrics in a bell curve and cuts the lower ranked adrift, and if it generates such a blizzard of top-down KPIs that nobody has time to think, then that is its purpose – control – and we are making a mistake if we imagine the intent is to maximise productivity or value creation. Culture and behaviour are usually at least partly a product of the underlying system that shapes them. In the short term, a good team lead can act as an umbrella that protects an emerging agile team from bureaucratic rainfall, and as an interface, which can translate the team’s outputs to meet corporate or regulatory reporting requirements. But over the long-term, this is destined to fail unless we face up to and reform the blockers and barriers the system creates that act against agility and new ways of working. This is hard, and sometimes impossible; but it is necessary if we are to expand the spaces in which agile teams can operate – especially non-technical teams, since corporate management still don’t really understand how tech teams work, so they get a pass to wear t-shirts and use kanban boards and CI/CD pipelines. I know it’s a cliché at this point, but we have to address the systemic issues that prevent fluid, agile team working, and that means we have to be teaching leadership, org structures, technology/tools, incentives and system design in combination.
The frustrating limitations of digital workplace tools (and where are my epistemic agents?)
It’s great to see such a visionary leader as Satya Nadella engage with and understand the value and potential of world design in the future of online experiences:
We are building, quite frankly, metaverse applications, if I could call them that. Or experiences in business applications, in productivity tools, and meetings and games — all three on a common platform. And avatars, 2D avatars . . . are showing up in our Teams [application] . . . people just want to be able to have an avatar that is taking signals from both your face and your audio. And it’s a very comfortable way for somebody to participate in a meeting.
The problem is, of course, that right now the key enabler of this idea in Microsoft’s digital workplace – MS Teams – is slow, clunky and unforgivably behind the experience that the non-corporate world is able to enjoy with Slack. The world design of M365 is closer to the original Doom than RDR2. Even some of the most basic features, such as persistent chat in meetings and collaborations, is too frustrating to use effectively. And yet the scope for using this kind of tool and its various integrations to truly help with world building for high-performance teams is immense. Tools we had in the pre-Google 1990s (for goodness sake!) such as personal search agents are still barely present in the digital workplace, despite being potentially useful as a way of helping people cope with so much information. For a taste of what could have been (and might yet be), I recommend this piece by Tom Stafford on Alvin Goodman’s Knowledge in a Social world and the idea of espistemic agents:
… it seems like one epistemic agent ate all the others – recommendation. Whether it is new music, concurrent purchases, or which the best take-away is in my area, most epistemic tasks can be looked at as recommendations. Recommendation algorithms have their own wikipedia page, their own academic conference. If there are sibling areas for other epistemic tasks, they aren’t immediately obvious (at least to me. Maybe data mining? Maybe filtering?).
One further thing – recommendation algorithms have themselves been eaten, by social information.