#1
❓ I have never seen a “high-performing” team described in books or on social media. Are they real?
💡 Of course they are real; it is just that they might not be as common as people like to think.
💡 Vanity, fear, pride, and inexperience also tend to distort our perception of workgroups, so we confuse them for actual teams; so TEAMS, let alone high-performing ones, might not be that common either.
The “State of DevOps” reports showed over the years that stability and throughput are the most important metrics for having high-performant teams. They typically achieve this using test automation, trunk-based development, deployment automation, and several more practices.
📚 However, as explored in my previous post, the latest “State of DevOps” report hints that the actual landscape of teams all over the industry might not be capable enough to employ the required techniques.
It is really unfortunate since both companies and teams leave in frustration due to unrealistic expectations. For example, setting continuous delivery as a goal implies that the team would be capable of continuously integrating their changes; continuous integration requires reliable test automation; it also requires the ability to make really small incremental changes, so it all can be merged into the trunk frequently and all the time, etc.
However, none of those practices is trivial nor readily present in any of the inexperienced team members. Moreover, companies are either forced to make teams of such inexperienced people with not enough skills (e.g. due to unavailability of talent) or are willingly seeking to do so for all the wrong reasons (e.g. “cost reduction”.)
All the wrong reasons also extend to compromises companies make while trying to compose a team. Some of those decisions include creating “geographically distributed teams” or “teams” spanning multiple time zones.
This prevents such groups of people from actually forming a team, let alone a highly-performing one.
💡 Bear in mind that not every group of people tagged with “team” actually forms one.
💡 Vanity and pride aside, the sooner you recognize such dysfunctions the sooner you would be able to address them.
#2
❓ I understand there are different kinds of teams. How can I tell which one is mine?
Before we talk about what types of teams there are, let’s examine types of contribution first.
❓ How do individuals and groups contribute to group results?
The obvious but quite ambiguous distinction of contributions is the first one that comes to mind:
➡️ By individual contribution
➡️ By group contribution
Although correct, it does not recognize different kinds of group and individual contributions, though.
There is also a distinction by the level of trust related to contributors:
➡️ Low-trust environments
➡️ High-trust environments
Turns out that these classifications can be combined, so we have a spectrum (or rather a matrix) ranging from, e.g., low-trust individual contributions to high-trust group contributions.
However, as with most things, it is a little more nuanced than that.
There is also an aspect of results ownership related to contribution. For SW development, an important part of it is code ownership. So, looking now from that perspective we have:
➡️ No result/code ownership (i.e., inattention to results)
➡️ Individual result/code ownership (i.e., “I wrote this, you wrote that,” or “my code, your code”)
➡️ Collective result/code ownership
The final aspect, and arguably the most important one, is the way contributions affect group knowledge:
➡️ None (i.e., knowledge kept within an individual)
➡️ Siloed (i.e., knowledge kept within sub-groups, specialties, etc.)
➡️ Collective (i.e., knowledge distributed within a group)
💡 Apply these perspectives and get a better understanding of your team.
I’ll explore this further in the upcoming posts.
#3
❓ How come my team is not a team? How can I tell?
💡 Simply labeling a group of people with a “team” label does not make that group a team.
📚 Combining different perspectives of contributions discussed above can help us understand the effectiveness of various SW team organizations.
It is one of the main reasons why most discussions about teams are either ineffective or derailed from the start.
The common delusions include, but are not limited, to:
❗️ “Distributed teams”
These are groups of contributors that are physically separated and spread over multiple locations.
Common justifications related to “distributed teams” include:
➡️ “We communicate constantly over Slack”
➡️ “We solve problems together all the time”
➡️ “We paired yesterday”
➡️ “We have effective work breakdown, so there are no dependencies”
❗️ “Teams” spanning multiple timezones with little to no overlap
These groups of people are both physically separated and time-shifted, so effective collaboration is impossible. Possibly, they might have tighter groups within time zones.
Common justifications related to such teams include:
➡️ “We use our overlap time effectively”
➡️ “We minimize dependencies between timezones”
➡️ “We concentrate specialties within timezones”
➡️ “We have core hours” or “We have overlapping hours”
❗️ “Hybrid teams”
Groups of people having “remote team members.” All the dysfunctions and justifications listed above apply here as well. These and all the above are mainly “Slack buddies” rather than teams.
💡 Regardless of what kind of team you believe you have, Conway’s law applies.
📚 In the words of Melvin E. Conway: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
Think about that when analyzing your team. Think about communication within the group and with other groups.
💡 Whenever there is difficulty or significant cost required to start or conduct communication, there is a tendency to create a line of separation within the system, resulting in unnecessary complexity (e.g., introducing interfaces)
As a direct consequence, it also results in silos and siloed knowledge.
💡 Don’t fall victim to what you THINK your team is. Understand your team how it REALLY is.
#4
❓ We have code reviews all the time. Isn’t this the best practice?
💡 Read how synchronous code reviews make you believe they help your team’s effectiveness ⤵️
📚 As discussed above there are types of contributions not suitable for teamwork, and not every group is a team.
❗️ Beware of your teams being low-trust environments!
Having a synchronous code review phase is a clear indication of a low-trust environment. It typically happens when a developer creates a pull request (in Git lingo) after coding is done.
❓ Why is this an indication of a low-trust environment?
Initially conceived as a tool to facilitate and enable open-source contribution, Git serves that purpose perfectly. However, just break down the wording of that particular part of the process – *a pull request*. It simply means: “You don’t know me, but I have something to contribute to your open-source project. Please pull my changes into your codebase.” Actually *requesting* changes to be *pulled* into a codebase.
Since an open-source setup is a low-trust environment in its own right, such a mechanism of *reviewing changes* and *approving them* is more than needed.
❗️ Now, put that procedure in a context of a team, which is supposedly a high-trust environment.
In what scenario is that a reasonable procedure in a high-trust collaborative setup? There is hardly any justification for doing so.
Here are a few common examples of justifications from teams using such an approach:
➡️ “We need code reviews to make sure that there are no mistakes in the code being merged” 👉 shows a low level of collaboration within the group and individual contributions are the main type of contributions; strong chance that the group is not an actual team, but a workgroup of individual contributors; results have to be reviewed and individually approved, instead of being co-created.
➡️ “We need code reviews to learn about the changes added to the codebase” 👉 low-collaboration setup again; the false hope of effective learning post-festum (after-the-fact.); a strong indication of siloed-knowledge culture; do you have an actual team there?
➡️ “We need code reviews to verify what junior developers are doing, so they can learn from code review comments” 👉 a rather ineffective way of introducing a junior team member to a team; there are far better alternatives.
💡 Be careful about adopting “best practices.”
💡 The more widespread the idea or practice, the greater chance of semantic diffusion (i.e., lost or watered-down meaning); not every “best practice” is best for your context!