Introduction
In this post I’m going to describe a series of indicators that you can use to see if a team that you manage, or are part of, are ‘high performing’. I’ll explain what the terms we use to describe the attributes of a ‘high performing’ team mean, the reasons we encourage particular team behaviours, and what we can do to move a team towards becoming ‘high performing’.
Terminology
What is a team, and how are you related to them?
A quick refresher with help from Google Re:work. A team is a term that is used to describe a group of people who are brought together to get work done. Re:work use these definitions:
A team is; “Teams are highly interdependent – they plan work, solve problems, make decisions, and review progress in service of a specific project. Team members need one another to get work done.”
As a counterpoint, a workgroup can look similar, however their behaviours and so the manner in which they are empowered is different;
A workgroup is; “Work groups are characterized by the least amount of interdependence. They are based on organizational or managerial hierarchy. Work groups may meet periodically to hear and share information.”
If you’re running a workgroup, the ‘signals’ described in this post may be less apparent.
What do we mean by ‘high performing’?
I’m paraphrasing Anita Williams re:work presentation & Amy Edmonson’s TED talk on Psychological safety. A high performing team is one that has a higher than average collective intelligence. Let’s assume that an individual has the requisite intelligence to fulfill their role within a business, it’s reasonable to assume (ok, I’m aware of the mass of environmental influences that can affect this) that they will be able do this.
When groups of people assembled as teams introduce new dynamics come into play. If a team dynamics are moving in a positive direction, then we can see traits emerge, including;
- Group dynamics enable divergent opinions to be discussed
- Skills are shared so that roadblocks are quickly removed
- Team members are reliable
- Team has a high emotional intelligence
Why would I want a team to be ‘high performing’
The benefits of a high performance team is that they are more likely to succeed in a project, they are more able to manage pivots, they will remain within the business for longer, they are able to solve problems more effectively/creatively, and they represent the company as a strong positive statement.
High performing teams are a joy to work with, and be a part of. As the Google Re:work research discovered, they don’t have to be populated with exceptionally gifted individuals, nor do they have a failure rate that is lower than normal. However, they self manage, deliver with greater consistency, have significantly lower staff attrition rates, and have magnetic properties for recruitment.
The indicators
I’m assuming for the purpose of this post that you’re in a position where you’re able to have an external view of the team. I envisage the roles that can do this are: Delivery manager, Program manager or similar. These roles share an ability to objectively view the team, and are not subsumed by the minutiae of daily project delivery.
Indicators, or ‘smells’ are behaviours that a team will show when interacting internally, and externally. Each indicator can be reduced to a root cause, which could then be discreetly managed.
- How is feedback managed within the team?
- Do retrospectives produce debate with actionable outcomes, does the team encourage feedback, is it delivered and received without fear?
- How does the team generate ideas (in fact, do they generate ideas?)
- Is there a method for generating ideas, are they developed, and does the team’s culture enable them to openly discuss ideas?
- How are ideas accepted and used within the team?
- Does the team have a culture of open question asking, and are domain experts happy to share their knowledge?
- Dependability of individuals within the team
- Is every member of the team able to describe where the project is (from a task perspective), and what the current priorities are?
- Do team members have clear responsibility for individual tasks within the project?
- Are the team members able to describe the tasks they own, and how they integrate into the project as a whole?
- Structure and Clarity of tasks
- Is it clear how a task’s ownership is received, is there a negotiation process?
- Does the project have a clear direction, and are all the team members working to move the project in that direction?
- Are the team members able to take ownership of a task without being micromanaged?
- Meaning of work
- Do team members treat each task as an opportunity to learn, mentor, share and transfer knowledge? Or is each task simply a job to be done by a team member with the appropriate skills and availability?
- Does the team celebrate individual and collaborative success?
- Impact of work
- Does the team consider itself to be continually firefighting?
- Is the team so overwhelmed with the project scope and goals that they feel that they’re making little headway?
- Are there symptoms of burnout? (physical and emotional exhaustion, cynicism and detachment, feelings of ineffectiveness and lack of accomplishment)
- Working with failure
- If the team feels safe enough to openly discuss failure, which is a key part of many design methods (E.g. Hypothesis driven design), then failure can be used as a learning method rather than a reason for punishment.
- Quality
- Is quality being maintained by the team? There are many dimensions in which quality can be compromised (ill defined features, poor documentation of the code written, inconsistent code styling, etc.) Any failure will result in the team taking an ‘uncomfortably’ long time to recover from a quality issue.
- Recruitment
- Growing a high performing team is (almost) an easy task. A team that radiates psychological safety, trust and respect will have a magnetic effect within the organisation. Recruitment is a lower priority when team retention is significantly higher due to the team being a great place to be.
- Deployment
- Are team members trusted to deploy their own code? A software team’s inherent agility, trust, quality and ability to rely on one another can be seen by how they ‘ship’ code. Though it could be argued that deployment methodology is an environmental factor, outside the influence of the team.
How do we move towards becoming ‘high performing’
A team is affected by a myriad of factors, some of which cannot be managed by a team culture (Global pandemic anyone?). However the team’s ability to respond to external influences, and how its culture reacts to internal issues can be hugely influenced by a few factors. Once again my source here is Google Re:work.
Psychological safety
Psychological safety is the foundation that underpins a high performing team (and all the other dynamics). If this is absent, then the team cannot perform strongly. A team with a strong sense of psychological safety will confidently “take risks on the team without feeling insecure or embarrassed”.
Dependability
Dependability is the ability to rely on team members to not only be able to do work, but be able to estimate how long it will take, and can be confident that the work will be of adequate quality.
Structure and clarity
This could be argued to be an external factor when considering a team’s dynamics, however my expectations are that a team will negotiate and own the goals, roles and execution plans. If these are clear, and demonstrable by any team member, then they will be adding to their ability to be high performing.
Have meaning for work
Here’s a tricky dynamic, if a team member is not motivated by the work the team is tasked with, they will have problems being motivated and delivering on time and to an acceptable quality. A person who is primarily motivated by financial gain, career opportunity or fear will not make a good team member.
Impact of work
My area of expertise is protecting and promoting the end users’ interests within any project. The close contact with the users begins at the research stage, and often involves deeply understanding the motivations for their behaviour. I know this level of engagement gives me a strong motivation for all the projects I’m involved with. “Do we fundamentally believe that the work we’re doing matters?”
Anecdotal breakout:
In the summer of 2016, I was running a 2 week Inception (rapid agile project startup) for the digital transformation of Virgin Money Giving. The existing service was 10 years old, definitely pre-smartphone and showing its age. I was facilitating a persona goals workshop, where we determine what it’s reasonable for various users to be able to achieve with the service. So far, a run of the mill engagement. Then I was introduced to the persona of a father whose child has recently died. This group of users make up a significant proportion of the Virgin money giving service, because aligned with the grieving cycle, the fathers motivation to ‘do something’ can be fulfilled through charity fundraising. My attitude to this project moved from a simple digital service rebuild, to building a service that could provide support and avoid crisis for grieving parents.
What’s next
This post’s aim is to introduce the concept of high performing teams, and hopefully cause you to consider whether you are enabling the teams you manage to perform as strongly as possible. An engagement with Made Tech has team building built in from the project Inception, through governance and the mechanics of deployment.
Please let me know if you enjoyed this post, and whether you’re interested in the method we use to build high performance teams.
If you are interested in learning more about this subject, you can download our “Building High Performance Agile Teams” ebook or order a physical copy from Amazon.
About the Author
Andreas England
Discipline Head of Product Management and Business Analysis at Made Tech
