A common fallacy in team working is the assumption that productivity and continuous improvement are strongly correlated, meaning that when one improves so does the other. In fact, we need to juggle both at the same time, and that means paying attention to the subtle differences in approach this requires.
While working on improving productivity in teams, I have even noticed a negative correlation in situations where I did not explicitly address both productivity and continuous improvement at the same time. Even when using the full spectrum of Scrum techniques and ‘ceremonies’ in conjunction with good hybrid team practices, such as replacing meetings with asynchronous working, I found I was improving productivity, but not necessarily seeing continuous improvement.
My favourite tactic for driving productivity in teams is working in the open; if anybody needs any information on what somebody is doing, it is accessible without the need to bother anyone with questions. But this sometimes risks minimising the opportunity for relationship development through an over-focus on productivity, especially in remote teams.
Relationships as a Pre-Requisite to Team Improvement
Nicola Burgess and Emily Rowe, writing about social networks, make an important point on how driving quality improvement requires relationships to be viewed as pre-requisites. Social networks in highly performing organisations are distributed, connected, and reciprocal, and thus vital for knowledge sharing and continuous improvement:
”relationships send the message of whether improvements will make a beneficial change to practice and determines whether improvement activities embed within an organisation. Organisations that exhibit high levels of social connectedness have the highest capacity to facilitate knowledge exchange and co-ordinate activity for meaningful collaboration and improvement.”
While finding ways to drive productivity in teams is often a priority, doing so by eliminating opportunities to form distributed relationships can limit quality improvement and continuous improvement in general. This is because key elements of quality improvement such as knowledge sharing are dependant on the formation of organisational relationships. We need to strive for a balance that promotes productivity but also the development of meaningfulrelationships that can trigger beneficial knowledge-sharing communication. We might need to prioritise certain types of relationships, boosting those that could facilitate meaningful communication, collaboration and knowledge sharing, and de-boosting those that provide uncritical agreement, which risk diluting the quality of ideas.
Returning to the example of driving productivity in teams, in these cases, people typically think of their team as ‘Agile’, but in reality are so focused on process and productivity over people and product that they have inadvertently created an environment full of uncritical head-nodding opinions, which affects the team’s ability to continuously improve. They have fallen into the trap of Agile theatre, driven by a productivity obsession that leaves no space for relationship forming and reflective improvement. Willem-Jan Ageling puts it simply: ”Agile is all about challenging assumptions.”
Beware Agile Tunnel Vision
Following specific Agile methodologies religiously while having productivity-oriented tunnel vision is a common negative pattern. This is why we need to normalize (and not always fear) conflict. Tuckman’s model of Team Development starts with the idea that conflict or ‘storming’ is not a bad thing per se; conflict is important for improvement and we need to let it develop naturally.
We need behaviours and a culture that supports healthy conflict. Dan Rosen summarises the necessary behaviours for healthy conflict as:
- keeping the four walls of confidentiality
- object and commit, where you know your objection can cause conflict and that is ok
- having a collective responsibility for all decisions
- replacing blame for a future focus
This is not a recipe for easy, comfortable conversations. But we can make these conversations smoother by knowing opinions beforehand to minimise surprises, asking questions and using the appropriate tone to have the hard conversation (commonly referred to as radical candour). Good leaders sometimes need to have difficult conversations.
But to make it work, a leader needs to have a good balance of humility and confidence. It is something we need to practice over time to make sure we do not become “two-faced”. Lissa Rankin describes this process as:
”Just like you might do 10 reps of a bicep curl, you’ll need to practice every day tempering your nervous system to handle conflict so you can do the right thing, be loyal to the safe people you love instead of choosing to fawn narcissists, and become trustworthy to yourself and others.”
Balancing Humility and Confidence
Vinita Bansal offers an additional perspective on balancing humility with confidence that is essential to giving critical opinions and creating healthy conflict. In Vinita’s words:
“Humility doesn’t translate into incompetence or lack of self-confidence. It means staying grounded, admitting that you don’t know everything, and accepting that you still have a lot to learn”
It is a fine line between imposter syndrome and the Dunning-Kruger effect. We need to appreciate that while we need to give critical opinions, we cannot seem like know-it-alls, but we also cannot pretend to not know anything about what we are discussing. When we find the right balance, we can start giving critical opinions that can lead to the continuous improvement in the team.
It really is one big juggle. We want our teams to have healthy conflict, to give critical opinions, to follow Agile methodologies, to be productive and to continuously improve; but if we focus on one of these balls too much, we might drop the other balls, or toss them so gently that we are not really juggling at all.
Don’t obsess with productivity at the expense of continuous improvement. If we’re lucky, we will be able to outsource a lot of our productivity to AI anyway, but that’s a conversation for another link*log…