Some characteristics of a great team

Note: Credit for most of this goes to @susannehusebo

• They start their daily stand ups 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 that don’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 “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 compromise
• 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 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’re 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 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, the 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’s a sustainable cadence to work
• They regularly talk about how they work together, and try to improve on 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 that 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
• Everyone knows that it’s ok to be wrong, as the rest of the team have your back
• Everybody participates in user research
• Everybody’s involved in pairing or non-solo work
• They have a shared history and sense of purpose
• They argue like siblings. Intensely, but when it’s over they’re still teammates
• There’s an awful lot of trust sloshing around the team. All of that trust has been earned by people doing what they say and looking out for each other
• Work is criticised. People aren’t
• No-one is “keeping score”
• “I don’t know” is not a dirty phrase. “Let’s find out” is an even better one