Building effective teams
Teams at Purepoint
High performance teams are extremely rewarding. Both to the individuals, and to the team as a whole. However, building a high performance team is far from straight forwards. Beyond the simple requirement that the members must be talented and motivated, they need to understand each other and their relative roles, respect each other, and build trust and energy.
Based on the Tuckman model
It is easy to dismiss these sorts of graphics as management nonsense. However, when it comes to teams there is a very real pattern which is captured here perfectly.
By understanding these phases, and guiding a team through them, members can better understand where they are and what they need to help make happen to improve the team and move it forwards.
- Team is polite, people tend to work on their own
- Task is often not fully understood, false starts and misunderstandings are common
- Some people may be anxious or overwhelmed
- People slowly start to work together
- The team starts to tackle the problem in a meaningful way
- Roles begin to emerge, leaders, followers, specialisations
- Relationships form, tensions can grow, but trust is built
- People start to understand each other on a more personal level
- The team gains an identity. There is consensus built around rules and values.
- People develop a stronger belief in the goal, including previous doubters
- As tasks change and progress is made, teams often go backwards and forwards between storming and norming
- Individual team members take responsibility for outcomes, but in the context of the whole team
- Trust is built, leadership is respected
- People are energised, the task is well understood
- Relationships are strong, though there may still be tensions
- Tasks are delegated throughout the team
The psychological element of teams is often ignored in software development. But understanding what makes each team member tick and leaning into that is extremely important. Teams dominated by an overly-extrovert leader, or that don’t give more introspective members their platform are doomed to never reach the fourth stage of the cycle and realise their potential.
When a project ends and a high performing team moves on, it is often quite a sad moment, and the whole process must start again with different goals and members.
Structuring projects and teams
Operating a flat structure means that team members’ roles can change on a per-project basis.
Everyone has their strengths and weaknesses, as well as their own personal lives. While it may have made sense to have someone be the lead architect on one project, we do not think it should be a certainty that they would also be lead architect on the next project.
Teams perform best when they have challenging work, and a good team dynamic. If you take either of those things away you start moving away from a high performance team. The diagram above shows how team dynamics can shift as you change the level of challenge or the team cohesian.
Revolving team members in this style gives everyone a different perspective into the challenges and rewards of different positions in the company. It is a perk of project-based or feature-based teams.
Management typically decide who works on what projects and how many people are allocated to a project. Team members can most certainly express a desire to be allocated onto a specific project. All things considered, we must perform a balancing act and remember that team composition for a project is a choice largely dictated by budget. Additionally, having unassigned team members sitting on the bench is not ideal. We therefore must plan and assign people to projects early-on and depending on their skills.
Understanding ‘cloud based’ teams
Cloud based teams need to be managed differently to co-located teams. Though there is much overlap, it is important to at least understand the key differences.
|Enables access to specialisations that are globally dispersed||Distance makes building trust and purpose more challenging|
|Enables access to localised knowledge||Communication and coordination are more complex|
|Cultural diversity brings different mental models||Cultural boundaries can lead to misunderstanding|
|Expands the working day through time zones||Time zones create management challenges|
|Increases flexibility and agility||Distance makes picking up on social cues more challenging|
|Allows for focused working environments||More difficult to socialise and build relations outside of working hours|
Purepoint was founded as remote-first, so we have many years of experience, tools and processes geared towards supporting cloud based teams. Obviously not all our teams and projects operate this way, but for those that do we have to guide our customers through what may be a new way of working for them.