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.

How is trust broken

In the beginning…

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.

The fall…in velocity

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.

How to build trust on teams

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:

• No trust: Functional chaos

• Some trust: Measurement and ticketing (think: Jira and burn-down charts)

• Strong trust: Goals (think: multi-month projects delivered on time-ish)

• Deep trust: Impact (think: KPIs and quarter level projects moving business metrics)

Kickoff: Retros

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:

1. Growing our team with retrospectives

1. Running effective retros

1. I highly recommend EasyRetro using to facilitate

1 - No trust: Functional Chaos

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.

2 - Some trust: Measurement

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:

1. Get people excited about measurement by trying out a new tool (Clickup, or Linear)

1. Kanban vs sprints

1. 1, 2 or 3 week sprints

1. Story points or time tracking

1. Trying a tagging system and altering the ticket structure

1. Using Slack bots and github integrations to make work less monotonous.

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?

1. Unanticipated tech debt issues

1. Lack of understanding of business goals.

1. Team members are brought a solution rather than a problem.

1. Engineers are not effectively raising blockers or sharing setbacks in standup

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.

1. Communication Each team member needs to practice communicating in retros and be effectively using standup + messaging to share unanticipated changes in a way that is productive and not inflammatory. The team leaders need to develop the skills both be active listeners and swift problem solvers to address unanticipated setbacks.

1. Stability If bugs are regularly introduced or the system crashes, no one will trust the engineers who built it. Prioritize tracking system reliability metrics like 'mean time to restore' and 'change failure rate' (see: Accelerate) to limit system stability from hurting system trust.

1. Eat your vegetables In addition to improving system health, the team should improve its 'internal health' by addressing factors that slow progress or add unpredictability (ie: a flaky test suite or a stakeholder that swoops in inappropriately).

1. Value each team members' time As the team starts at hitting its goals, diligent estimation may not be a good use of engineer time. The team can gradually stop breaking down and estimating every individual task as a group and have engineers estimate individually as best suits their level of experience. Engineers should be able to help each other plan in less formal settings such as chat or quick pairing sessions.

1. Morale Celebrate wins as widely as possible such as at larger department or company wide meetings. Share progress and learnings in retros — smart failures are progress and progress builds morale. Celebrate 'heroes' but do not depend on heroes. Ensure no invisible work done by people on the team. If people do need to go above and beyond, or take on unplanned work, make sure to celebrate it but not incentivize it (very delicate!).

3 - Strong trust: Goals

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'.

Note: This is phase is easiest to achieve for teams doing 'feature work' as feature work is a notch bigger than a 'sprint'. Data teams or infrastructure teams may have many smaller projects on the order of days and then larger quarter level initiatives. This means there isn't a clear next step up. I believe it requires a technical leader to help break these quarter level projects down into milestones than can be 'goals' or a PM to group a set of smaller asks into a larger month+ 'launch' as a 'goal' but even so it is challenging.

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?

1. ~2 week sprints or effective kanban

1. Less ‘overhead’ to running sprints (fewer group meetings and/or shorter team meetings)

1. Smaller meetings such as a TL and PM planning the sprint

1. PMs not involved in the ‘who’ and the ‘how’ of work items but deeply involved in the ‘what’, ‘why’ and ‘when’. PMs spend more time bringing engineers along.

1. TL and ICs on the team collaborate to break down work with less involvement from the PM.

1. ICs can pull from a general pool of work.

What are common retro topics?

1. Our goal was not well articulated or a shared understanding of the goal was not achieved

1. Too many meetings / meetings are too large

1. Isolated from other teams

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.

4 - Deep trust: Impact

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?

1. Too many meetings / meetings are too large

1. Team isn’t handling tactical requests well

1. Wrong metrics

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'.

In summary

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:

• Start regular retros with a larger retro to kick things off.

• The team works together to predict the tasks they will complete.

• Team leads measure the team's delivery rate, failure rate and track issues that block or slow progress (like tech or process debt).

• Lower focus on task level prediction and increase focus on delivery of larger project or hitting goals.

• Lower focus on delivery of work and increase focus the impact of work.

• If the team changes meaningfully…return to step 1.

Key points

1. Early teams commit to tasks or features and mature teams commit to abstract concepts.

1. Rapid growth necessarily breaks early trust patterns. (ref)

1. To repair trust, focus on predictability not speed.

1. The journey to rebuild trust starts with the team arriving at a shared understanding of the present reality and then aligning expectations about what will happen in the future. This is where the vision for effective teams comes in.

1. Grow gradually. Similar to growing from a new engineer to a team lead, the team will incrementally handle work with larger amounts of uncertainty.

1. Return to measurement if the team meaningfully changes to reinforce fundamentals.

References

1. Storming norming forming

1. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

1. Akira Manga

1. Why it’s difficult to build teams in high growth organizations