Team Building For High Performance
Team Building For High Performance
I’ve recently been writing a post on building high-performance teams (I’ve spent most of my career either building high performance teams myself, being part of a high performance team under construction, or helping others build high-performance teams). The post in question is rather getting away from me, in terms of length, and I might choose to convert it into a small book instead.
But I did want to post something on the topic, not least because during my research for the post I’ve come across so many instances of advice contrary to my own experience, advice which I believe if followed would undermine any such effort, and result in mediocre, under-performing teams, at best. Compared to what’s possible.
So, skipping over the definitions of “teams” and “high performance”, the rationale for teams, and the detailed ins and outs and how-to’s, in this post I’ll just cut to the nub of the challenge, as I see it: whole-part thinking.
Most teams I’ve seen being built exist as a part of a larger whole (team, development organisation or silo, company).
That larger whole usually holds all the aces when it comes to stipulating what is and is not permissible. Hiring practices; compensation practices; incentives and motivational practices; working practices; internal and external communications practices; management structures, doctrines and practices; ways in which folks can relate to each other a.k.a. social norms; influence over the workplace, tools and equipment; remote vs on-premise working; working hours and locations; and so on. All these and more are generally under the control of the wider organisation (sometimes explicitly, more often, implicitly).
So, the constraints on our team building efforts are legion. And these constraints are generally antithetical to our achieving high performance. For successful builders of high performance teams, the biggest challenge they have overcome is the challenge of circumventing these constraints, without alienating the larger whole (and the powers that be) to the extent that they lose their credibility and influence. And sustaining their circumventions, credibility and influence, over the long haul.
I’ve written at greater length about these challenges in my 2012 posts “OrgCogDiss” and “French Letters” (the latter specifically about Agile teams, but equally relevant for all kinds of high-performance team).
In a nutshell, then: whole-part thinking leads organisations to believe that a development team or silo is a more or less independent entity, masters of their own performance, and can be held accountable as such. In reality, the constraints of being a part of the larger whole impact teams to such an extent that they have little to no independent control over their own performance.
Enable High Performance For the Whole
Organisations that truly value performance over rules change the rules (constraints) to enable high performance across the whole organisation. Many prefer to stick with their existing assumptions, beliefs and rules.
Why Agile is No More (or Less) Than a Skunkworks ~ Think Different blog post
Innovation ALWAYS Demands We Change the Rules ~ Think Different blog post
I Want You To Cheat ~ John Seddon
i couldn’t find your article “french letters” anywhere? do you have a link?
Apologies. I intended to insert links to the mentions posts. I have now updated this post to include those links. Please let me know if you have any more trouble finding them.
Should teams be called “High Performance” teams at all? In the old world of command and control, these means squeezing more out of these teams and getting higher efficiencies and productivity from the “resources” aka people/humans.
I try to use the term “High Practice teams” – the teams are responsible for the mastery of their practices, the results are up to the market (value goals are also difficult in these old school organizations)
Or should we call them “High Mastery teams” or “High Competency teams”… now I am rambling…