This post is about the critical component of a 'strong' team: trust. I believe building a strong team means listening to the level of trust through frequent retros. The team improves by incrementally adopting practices that either improve trust or 'cash in' on the team's trust.

I have not joined a company that had a plan for how a team goes from being 'new' to 'strong'. Without this vision, conversations about team practices were frustrating and left newer teams feeling attacked.

With a vision for how a team improves trust, we can help teams get to the next step rather than applying a uniform standards to all teams.

Early on in a startup, you are bound together with risk takers making a singular abstract promise - find product market fit! For me, this is the ideal team and I live for this kind of work. However, I have struggled to maintain this creative, high trust environment as the startup actually gets successful.

If the startup is successful, the team will quickly move into an environment with no trust.

New teams with new stakeholders, with new team members, with shifting business needs all work to destroy trust. The team has cratered from the best kind of team to the worst kind of team.

The team was soaring in the sky, flying free and shipping at the speed of light. Now, the team is climbing the Rocky Mountains with a bunch of new people they met one time in a zoom meeting.

The team has lost trust. Teams can no longer even agree on what to promise, who to make the promise to or likely why they are making promises in the first place.

Leaders mistakenly push these dysfunctional teams to move faster, but at this stage, you need to slow down. Instead of attacking 'iteration speed' or 'quality', the first challenge is to build trust between stakeholders, leads and collaborators.

Trust is about predictability and not velocity.

We build trust to handle bigger challenges. To collaborate, teams make promises to other teams and then keep those promises. Making and keeping promises allows groups of people to depend on one another.

As a team matures, the team can evolve from making specific promises (ie: we will build you this exact API endpoint by next sprint) and to more general promises (ie: we will help you solve your data access problem this quarter). More general promises can have greater impact at lower cost through allowing the team more creative freedom and encouraging deeper collaboration (ie: understanding the business need).

We build trust to handle bigger challenges.

This trust building is broken into four stages. In each stage, the team makes incrementally more abstract 'promises' to the business (and each-other) and then builds trust by delivering on those promises. The four stages of trust are:

Before starting out, the team must arrive at a shared understanding of the present reality and then align expectations about what will happen in the future. This is where the 4 stages of trust come in.

Much like starting off on the Oregon Trail, take stock of the team and resources, plan for the challenges ahead (dysentery!) and then kick off on a journey toward a known destination.

The team should be able to start on the journey knowing they are on the same page as leadership.

Running great retros shouldn't hold you back from running retros. You can't learn if you don't share. In general, retros should capture what went well, what didn't go well and other notable events. It helps to have a hype person or someone to make the event fun to keep participation high. Once things get going well, I highly recommend bringing in stakeholders occasionally to see how you work.

If you would like to learn more about running retros, here are a few posts I found helpful:

A lot of work is happening but the promised work rarely gets done. It is unclear if the work being done is the 'right' work or whether the work is having any impact.

I had a new manager join the team and she said was 'this is not a lean team, this is an emaciated team'. She was right. Each team member individually managed multiple pieces of infrastructure and had no real metrics for success. Sprints were difficult to predict since the surface area was just far too large and the number of stakeholders was staggering. The team was highly motivated to get things working. But, that left team members scrambling to put out fires, rarely ticketing work or making their efforts visible to the PM or their manager. Engineers thought they were working at peak, and stakeholders thought nothing was getting done. A terrible situation.

What do team meetings look like?

Standup feels like a waste of time since the day's plans are never realized.

What does success look like?

Success is being able to plan forward day over day and then week over week.

What are common retro topics?

The team is probably not having retros. If there are retros, there are likely a few dominant voices expressing frustrations and not getting results.

What should you be doing to get to the next phase?

Stop. Just stop.

The leaders need to get buy in from the company/partners to slow the team's work to a halt. Stop hiring. Do NOT bring in external consultants or additional headcount to a team in this phase.

The team should have an offsite or much longer retro to really get people talking and healing. Then, begin bi-weekly retros. Bring in stakeholders to help them understand the team if they can engage productively. Ideally, the team stakeholders can be part of the solution by finding ways to limit work in progress.

This is where a leader (you?) can present a more hopeful future. As mentioned above, the most important (and most difficult) challenge for the leader is to share their views with the team and then together with the team, arrive at a shared understanding of reality. Once you have that shared understanding, the team can share experiences working on 'dream teams' and the leader can help articulate that north star. Then, together, chart the path toward that north star.

I deeply believe that the next step to repair trust between both team members and the company, is the tedious practice of measurement and acting based on data.

People find they cannot trust what others say, so they find a tool they can trust instead. The tool serves as an intermediary for all work.

This is when the team makes serious use of a planning tool like Jira (or one of the many alternatives) with estimates. User stories are added ahead of time and broken down into small units of work (tasks) and then each task is assigned and estimated.

As a manager on a team like this, your job is to find fun and creativity despite the rigid structure. This phase involves large amounts of change as the team decides what to embrace and measures the impact of those changes. Those changes might include:

Standup should should be daily and conducted around the board. Before starting work, team must break town user stories into tasks, estimate each task and then find what amount of work can get done in a segment of time. You can’t fix what you can’t measure.

What do team meetings look like?

Team meetings are 90% about tickets and unanticipated blockers. People rarely reference the big picture quarterly goals or business needs.

What does success look like?

The team anticipates roadblocks and delivers on timelines accurately.

In my experience, the big 'win' at this phase is being able to successfully add people to the team. The process work is dull, but adding new energy to the team often helps this phase be a bit more fun.

What are common attributes?

The team usually does longer sprints at first (3 weeks) with team planning meetings are done synchronously. PMs are often involved in the ‘who’ and the ‘how’ of work items as they do not trust the TL.

What are common retro topics?

What should you be doing to get to the next phase?

The measurement phase is when you build the team fundamentals - the foundations of trust.

At this point, your team should have strong fundamentals. For the PM and tech lead, they need to be strong at communicating the business context, user stories and/or project documents in whatever form works best for the team (tickets, slide deck, documents). Individual contributors should be good at asking questions and flagging blockers. The team should collaborate using 'blame free' and supportive language. The infrastructure and tooling should be reliable enough to support frequent deploys and have sufficient test coverage and/or monitoring so that developers can build reliable software.

With those fundamentals in place, the work can get more creative. Rather than building to a spec, and breaking down all tickets far ahead of time, the team is trying to address a user story or business need. The team should have the trust to ship experiments or small tests to see what will address the need and will likely start making use of feature flagging or versioned interfaces.

PMs and stakeholders will get less involved in the how and be more focused on the what, the why and metrics around 'how to will we know if we hit our goal'.

What do team meetings look like?

Team meetings are 20% about tickets and maybe 80% on discussion of goals, questions about different implementation tradeoffs, upcoming blockers and improving system/usage metrics.

What does success look like?

Work should feel much more fun. The engineers are able to think longer term and move at higher velocity due to less ticketing overhead. The PMs are spending less time with the engineers on the 'who' and 'how' of tickets and start to spend more time with stakeholders and socializing the next initiatives.

What are common attributes?

What are common retro topics?

What should you be doing to get to the next phase?

This is when you start looking outside your team. By this time, you are likely one of the stronger teams in your org. You are delivering value quickly, but you are often still being told what problems to solve and when to solve them. You may struggle to know how your work helps the business.

There is an even better way of working ahead. But, it requires the business to change.

The major difference between this and the prior phase is that work is connected to a longer strategy. In each phase, the team makes progressively more abstract 'promises' to the business. To move beyond user stories, you need the business to leverage KPIs or some system that can give you direction, autonomy and a way to measure your success. Depending on the stage of company, that may simply not be possible.

The KPIs need to be socialized repeatedly and really stick for at least a quarter so that teams understand what other teams are doing at a high level. The team alone can't make this happen, the business needs to be willing to focus on specific drivers without major distraction for an extended period of time. The business needs to trust the team to deliver without giving hard timelines.

In my experience, this is hardest phase to achieve when the team is close-ish to the business. At Cityblock, one team built software for doctors who then cared for patients. If the insurance company’s total cost for those patients was lower this year than last year, Cityblock made money. The time horizon and indirection make it difficult to tie success or failure to the software used by the doctors. A team that is closer to the business, like an e-commerce checkout team or further from the business like an infrastructure team, can have an easier time here (though they often have challenges in the 'goals' phase).

What do team meetings look like?

Large team meetings 0% about tickets and maybe 50% on goals and 50% moving metrics. There are still discussions about features, but there are more debates on how to test whether they will have the anticipated impact

What does success look like?

Key business metrics move like never before. Team members are involved in decision making.

What are common retro topics?

What should you be doing to get to the next phase?

Well, I don't know. I have never been able to stay in this phase for long. Often some people changes or business strategy changes punt you back to 'phase 1'.

The type of process you employ on your team is a function of the trust between members of your team. As a leader, you can run a more effective team that gets joy out of their work by meeting them where they are and working with the team to adjust process as the level trust changes. You can get the most out of your team by working with them to improve trust they have with each other and the trust between the team and the business.

The journey to repair trust - from 'functional chaos' to an 'impact' driven team - is long and there will be problems. At a high level, the journey will look something like this: