Symptoms of high-performing teams

Thread by Susanne

I’ve worked with lots of agile teams, and some of the symptoms of a well functioning high-perfoming teams that I see are:


They start their daily standups on time.

They tend to laugh a lot and have fun.

Everybody in the team gets to express themselves.

They correct and edit each other when they go off track.

They try out new things with appetite. But they are quite willing to admit those things didn’t succeed.

They often don’t care very much if it looks like they’re working hard.

They encourage each other to leave on time.

They talk about how “we built” or “we failed”, rather than “I built“ or “I failed”.

They have lunch together, or some other time within work hours where they talk about other things than work.

They welcome more junior members of the team, and enjoy mentoring them.

They have inside jokes.

They share responsibility for communicating with outside stakeholders.

They don’t agree on everything.

They debate between short term benefits and long term strategy. They reach compromises.

They question each other on topics like accessibility and inclusivity in design and development.

When they finish a task, they check if they can help someone else finish theirs.

There’s room in good teams for extroverts and introverts. And those in between.

Team members are aware of their needs and communicate those to others.
I’ve seen some great teams have some seriously stubborn people in them. They can be great when the team needs reminding of why they came up with a certain rule: specifically so the team wouldn’t compromise when they were in a hurry.

Good teams often fight for independence to make their own decisions.

They ask “why” a lot.

They discuss the users of their products every day, and the user experience is viewed as everyone’s responsibility.

If they are remote, they try new ways to make everyone equal, even if it means compromising the experience of those people that are in a shared space.

They are not dogmatic.

Testers and designers are included in discussions of estimations and backlog refining.

They respect agreed decision making structures, but argue their points.

The people are not too similar to one another. They think about problems from different angles.

If someone on the team is ill, the others figure out how to get by without that person.

They have quiet time. In whatever amount is valuable to them.

They don’t interrupt each other. They take equal turns in speaking.

They get each other tea/coffee/water.

They have one-to-one chats with each other to discuss points of agreement or disagreement.

They know each other’s personal and professional goals and aspirations, and try to support them where possible.

They are not all equally skilled at everything. But they try to work on things where they can learn.

When people pair on a task, the less experienced person is usually the “driver”.
Senior team members ask for advice and feedback from more junior team members.

They don’t have to give positive feedback every time they give negative feedback.

They thank each other for favours, for tea, for good ideas, for bad ideas, for observations…

They use the products they’re building.

When someone has an idea, other team members build on it and add to it.

They accept that people have “off” days.

They are generally resilient when it comes to change – including change of direction, goals and vision.

They can work quickly, but it’s not always crunch time. There is a sustainable cadence to work.

They regularly talk about how they work together, and try to improve that.

Team members generally know what every other team member is working on, and what kind of issues they’re having.

They encourage each other to share work early, rather than wait for it to be “perfect”.

They have some shared values or principles that guide their interactions.

They try new tools and methods quite easily.

They might defend each other to people outside the team.

Before they ask for feedback or reviews from other team members, they read through their own code/work.

They have time to / they prioritise automating tasks that are not valuable.

They talk about technical debt, and teach stakeholders about it.

The work they do feels important.

They argue.

They talk about how well they’re doing compared to expectations. If the estimates turn out to be off, that’s not a disaster.

They take turns dealing with boring or time consuming tasks.

They are interested in each other personally.

They talk about problems without talking about people’s characters, rather they focus on the work.

In meetings, they put their phones down or close their laptop lids when they’re listening.

They have a say in who joins the team.

They have shortcuts for common communication (like signals for when the conversation is derailing, or when they’re losing focus).

They don’t mistake fun for a lack of discipline.

They consider different communication styles. Meetings are not just held so the loudest speakers are heard the most.

They care that other team members and stakeholders understand the work they’re doing.

Documentation is updated whenever errors are spotted, by the person who spots the error.

Team members feel a shared sense of pride and ownership of their work.

It’s not ok to notice a problem, and not do something about it, even if it’s not in an individual’s immediate area of responsibility.

Developers participate in sketching sessions, designers understand how git works.
Team members reach out to their personal networks to ask for help for other team members.

Everybody tests.

Team members let each other try things out even if they think it will fail (sometimes, if constructive).

They notice when other team members seem worried or down. They ask about it.

They don’t grow too quickly.