How to Rekindle that Small-Team Feeling

When did our team start to feel so big? I haven’t had a conversation with Steve outside of a meeting in over a month, I’m not sure who’s going to finish the analysis that’s blocking a big feature decision, and (if I’m honest) I don’t know what features Nikki worked on last sprint or whom Andy is paired with this sprint. We started out small and agile with a strong focus on shared ownership and getting things done, but I’ve had more meetings this week to discuss roles and responsibilities than to move project goals forward.

Does that sound familiar? It’s easy for growth to change the feel and effectiveness of a team. Practices might not serve the growing team as well as they used to, and — more concerning — attitudes can shift away from the high-trust, shared-ownership mentality I love so much about small teams.

If we notice that shift starting, is it possible to regain some of that small-team feeling?

What Makes a Team Feel Big or Small?

In a short altMBA recruiting video I saw recently, Seth Godin describes the difference between large and small teams in a way that resonates with some of my recent experiences:

A big team is about compliance, roles, and bureaucracy. A small team is about accountability, cohesion, and getting somewhere that the team wants to go.

That description wrapped up what I’d been feeling about large- and small-team dynamics so concisely that I’ve gone back to watch that advertisement several times.

When a team’s focus is on compliance, roles, and responsibilities, I’ve seen the consequences:

• Work in the gray area between explicit roles falls between the cracks, and it’s a fight to get someone to own it.
• Protecting individual success metrics outweighs achieving team goals. People focus more on themselves — what they’re getting out of the team, their personal achievements — than on the team.
• Individuals make decisions within the scope of their responsibility but without including others in the process, demotivating and reducing engagement from other team members.

Conversely, on small teams where we’ve built a strong sense of accountability, cohesion, and shared team mission, I’ve witnessed really great things happen:

• Individuals make commitments to do work outside their wheelhouse, when needed, to keep the team on track.
• Team members know that team success is the ultimate measure of achievement.
• Involvement in decisions and the opportunity to explore motivates individuals and promotes deep engagement.

This isn’t to say that roles and responsibilities are bad. But when the focus is on compliance with those things at the expense of accountability, cohesion, and pursuing shared team goals, the team has a much more difficult time getting where they want to go.

Signs of a “big team” problem might include:

• Important work is getting missed, but we can’t really fault any specific individual.
• Team members don’t understand why they’re doing the work — how does it connect to a larger purpose?
• It seems like everyone is working on something different; priorities are scattered.
• Individual performance reviews show good marks, but the team isn’t achieving its goals.
• High performers aren’t stepping up to contribute in the way that you know they’re capable of.

How to Get that Small-Team Feeling Back

Short of actually breaking up the large team, what can you do to reinvigorate a team and reestablish some of the things you love about small teams?

1. Make Small-Team Opportunities

One of the most direct ways to inject a dose of small-team fervor into a larger team is to create opportunities for team members to engage in a small-team experience.

Set a compelling goal, assign it to a small cross-functional group, and give them autonomy and ownership over the outcome.

This could range from a full-time, short-term skunkworks project meant to identify a disruptive innovation for the team, to part-time, long-term ownership over some area of the application. For example:

• We need a way to speed up reporting in this system. Take two sprints, run experiments, evaluate the usefulness of the more expensive calculations, consider alternate designs, and give us a recommendation at the end.
• The CI/CD infrastructure needs to be better taken care of. Would you three take ownership over that for the next quarter, with a budget of ten hours each per week, and see what you can do to improve the situation? We’ll evaluate after the quarter and see if you think that will need to continue or change.

Assign end-to-end responsibility for a large, related set of features to a small group.

On my current project, we’re planning an experiment that will give three people — a Business Feature Lead, a Development Feature Lead, and a System Analyst — responsibility for:

• researching, coordinating, and reviewing design with our UX designer,
• leading development of the features, and
• reviewing and approving the finished work.

There will be others involved throughout, but those three will be ultimately responsible for getting it done.

We hope this experience will get people in the mode of identifying work that needs to be done, coordinating closely with the team, and ensuring that it all gets done well.

2. Refocus Team Goals, Values, and Expectations

It’s a good idea to revisit team goals, values, and expectations regularly to keep them fresh in the team members’ minds.

I like to run project charter exercises each quarter to give the team an opportunity to engage in the goal-setting process and values discussion. Those things can and do change over time, and it’s important that the team feels engaged in keeping them relevant. If you’re curious about project charters, read the chapter “Energize the System” in Mike Cohn’s book Succeeding with Agile.

Another source of inspiration I’ve been going to lately is Seth Godin’s manifesto for small teams doing important work. I’d highly recommend it.

3. Allow Experiments in Noncompliance

There are good reasons why members of a big team might need to comply with their role responsibilities. Can you imagine if fifteen developers were constantly asking big “what if” questions that would blow up the design direction? It would be chaos. Developers have to extend trust to the design team and generally stick to the direction that’s been set. But what if you could create some space for experiments that break down those barriers? For example:

• Let a couple of ambitious developers play out a big “what if” scenario that goes against some elements of the design direction but might provide some useful insights into technical possibilities.
• Flex on language and tooling choices for a spike.
• Put a developer and business stakeholder together to define how a feature should work.
• Let the team break process in some way for a sprint.

Allowing the process, roles, and responsibility to flex for experiments shows that those things need to serve the team, not the other way around.

4. Help Team Members Make Personal Connections

When people feel a personal connection to their team members, they’re more willing to engage in the work of the team and flex to help their team members.

One practice that can help people get out of work mode for a moment is to ask a fun, semi-personal question. For example:

• What’s the farthest you’ve ever ridden on a bike?
• What’s your favorite Halloween candy?
• What’s your favorite season?
• What’s the best thing that happened to you last week?

Creating team social time over lunch or outside normal hours can help too, if it works for team schedules. Just don’t make the mistake of assuming that everyone has the same availability.

How to Keep It

If you do manage to recapture some of that small-team efficiency and shared focus, how do you keep it?

1. Limit Team Growth – If your team has gotten back into an effective state, but you suspect you’re still on the edge of running into problems because of team size, don’t keep growing your team and expect to maintain that success. Instead, if there is more work than the team can do at its current size, look for ways to create additional teams. (See Mike Cohn’s book, Succeeding with Agile, for some good thoughts on team structure and scaling Scrum.)
2. Resolve Conflict – Conflict that isn’t resolved can break down the trust and shared ownership necessary to keep the team working effectively. Pay attention to tensions and disagreements, and don’t let them grow into something that harms the team.
3. Put People over Process – Involve people who care in important team decisions. Continue to adjust processes based on team feedback. Keep the office doors open for important conversations.
4. Keep Doing the Things that Energized the Team – If there were specific activities that helped the team improve, keep doing those things. It might not be possible to have a skunkworks project running all the time, but there may be something worth approaching that way once or twice per quarter. Keep refreshing your project charter.

Further Reading

If it’s not clear already, I love Mike Cohn’s book Succeeding with Agile. It’s excellent, and you should read the whole thing. If you need a quick injection of good content on this topic, start with the chapters 10 (Team Structure), 11 (Teamwork), and 17 (Scaling Scrum).