This post argues that as startups grow, the initial high-trust environment often collapses into chaos. The common leadership mistake is to push for more speed; the real solution is to slow down and rebuild trust through predictability. The author outlines a four-stage journey where a team matures by making and keeping progressively more abstract promises: evolving from committing to specific tasks (via ticketing systems), to achieving monthly goals, and ultimately, to delivering business impact measured by KPIs. This entire process is driven by retrospectives, which help a team understand its current level of trust and take the next step.
This post explores the critical component of a 'strong' team: trust. I believe building a strong team means listening for the level of trust through frequent retrospectives. The team improves by incrementally adopting practices that either build trust or leverage the team's existing trust.
I have not joined a company that had a clear roadmap for how a team progresses from 'new' to 'strong'. Without this vision, conversations about team practices were often frustrating and left newer teams feeling attacked.
With a vision for how a team builds trust, we can help teams advance to the next level rather than applying uniform standards to teams at different stages of development.
How Trust Is 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 environment, and I thrive in this kind of work. However, I have struggled to maintain this creative, high-trust environment as the startup achieves success.
The fall…in velocity
If the startup succeeds, the team will quickly transition into an environment with minimal trust.
New teams with new stakeholders, new team members, and shifting business needs all work to erode trust. The team has plummeted from the best kind of team to the most challenging kind of team.
The team was soaring, shipping at the speed of light. Now, the team is climbing the Rocky Mountains with people they barely know from Zoom meetings.
The team has lost trust. Teams can no longer agree on what to promise, who to make promises to, or 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 focusing on '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 effectively, 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, it can evolve from making specific promises (e.g., "we will build you this exact API endpoint by next sprint") to more general promises (e.g., "we will help you solve your data access problem this quarter"). More general promises can have greater impact at lower cost by allowing the team more creative freedom and encouraging deeper collaboration (i.e., understanding the business need).
We build trust to handle bigger challenges.
This trust-building process 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: Retrospectives
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 setting off on the Oregon Trail, take stock of the team and resources, plan for the challenges ahead (dysentery!), and then embark on a journey toward a known destination.
The team should be able to start the journey knowing they are on the same page as leadership.
Running great retrospectives shouldn't hold you back from running retrospectives at all. You can't learn if you don't share. In general, retrospectives should capture what went well, what didn't go well, and other notable events. It helps to have someone who can energize the event to maintain high participation. Once things are going well, I highly recommend occasionally inviting stakeholders to see how you work.
If you would like to learn more about running retrospectives, here are a few resources I found helpful:
I highly recommend using EasyRetro to facilitate the process
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 it is having any impact.
I had a new manager join the team who said, "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 scope was 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 documenting work or making their efforts visible to the PM or their manager. Engineers thought they were working at peak efficiency, while 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 retrospectives. If there are retrospectives, there are likely a few dominant voices expressing frustrations without seeing 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 temporarily slow the team's work. 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 retrospective to get people talking and healing. Then, begin bi-weekly retrospectives. Bring in stakeholders to help them understand the team if they can engage productively. Ideally, the team's 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 methodical 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 significant change as the team decides what to embrace and measures the impact of those changes. Those changes might include:
Get people excited about measurement by trying out a new tool (Clickup, or Linear)
Kanban vs sprints
1, 2, or 3-week sprints
Story points or time tracking
Trying a tagging system and altering the ticket structure
Using Slack bots and GitHub integrations to make work less monotonous
Standup should be daily and conducted around the board. Before starting work, the team must break down user stories into tasks, estimate each task, and then determine what amount of work can be completed in a given timeframe. 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 more engaging.
What are common attributes?
The team usually starts with longer sprints (3 weeks), and team planning meetings are conducted synchronously. PMs are often involved in the 'who' and the 'how' of work items as they do not yet fully trust the Technical Lead.
What are common retro topics?
Unanticipated technical debt issues
Lack of understanding of business goals
Team members are brought a solution rather than a problem
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.
Communication
Each team member needs to practice communicating in retrospectives and effectively use standup and messaging to share unanticipated changes in a productive, non-inflammatory way. Team leaders need to develop skills to be both active listeners and swift problem solvers to address unanticipated setbacks.
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 prevent system stability issues from eroding trust.
Address Technical Debt
In addition to improving system health, the team should improve its 'internal health' by addressing factors that slow progress or add unpredictability (e.g., a flaky test suite or a stakeholder who intervenes inappropriately).
Value each team member's time
As the team becomes more consistent in hitting its goals, diligent estimation may not be the best 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.
Morale
Celebrate wins as widely as possible, such as at larger department or company-wide meetings. Share progress and learnings in retrospectives—smart failures are progress, and progress builds morale.
Celebrate 'heroes' but do not depend on them. Ensure no work done by team members goes unrecognized. If people need to go above and beyond or take on unplanned work, make sure to acknowledge it but not incentivize it (a delicate balance!).
3 - Strong trust: Goals
At this point, your team should have strong fundamentals. The PM and tech lead need to excel 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 skilled 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 deployments and have sufficient test coverage and/or monitoring so that developers can build reliable software.
With those fundamentals in place, the work can become more creative. Rather than building to a specification and breaking down all tickets far in advance, 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 using feature flagging or versioned interfaces.
PMs and stakeholders will become less involved in the 'how' and more focused on the 'what', the 'why', and metrics around 'how we will know if we hit our goal'.
Note: This 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 that 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 80% focused 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 engaging. Engineers are able to think longer-term and move at higher velocity due to less ticketing overhead. PMs spend less time with engineers on the 'who' and 'how' of tickets and more time with stakeholders, socializing the next initiatives.
What are common attributes?
~2 week sprints or effective kanban
Less 'overhead' to running sprints (fewer group meetings and/or shorter team meetings)
Smaller meetings, such as a TL and PM planning the sprint
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.
TL and ICs on the team collaborate to break down work with less involvement from the PM.
ICs can pull from a general pool of work.
What are common retro topics?
Our goal was not well articulated, or a shared understanding of the goal was not achieved
Too many meetings / meetings are too large
Isolation from other teams
What should you be doing to get to the next phase?
This is when you start looking beyond your team. By this time, you are likely one of the stronger teams in your organization. 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 understand 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-term 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 company's stage, that may simply not be possible.
The KPIs need to be communicated repeatedly and remain consistent 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. The business needs to trust the team to deliver without imposing rigid timelines.
In my experience, this is the hardest phase to achieve when the team is relatively close 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 have 0% focus on tickets, with approximately 50% focus on goals and 50% on 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 improve significantly. Team members are involved in decision-making.
What are common retro topics?
Too many meetings / meetings are too large
Team isn't handling tactical requests effectively
Metrics may not be correctly aligned with goals
What should you be doing to get to the next phase?
I don't have a definitive answer. I have never been able to maintain this phase for long. Often, personnel changes or shifts in business strategy reset the team to 'phase 1'.
In Summary
The type of process you employ on your team is a function of the trust between team members. As a leader, you can run a more effective team that derives satisfaction from their work by meeting them where they are and working with the team to adjust processes as the level of trust changes. You can maximize your team's potential by working with them to improve trust among team members and between the team and the business.
The journey to rebuild trust—from 'functional chaos' to an 'impact-driven' team—is lengthy and will encounter challenges. At a high level, the journey will look something like this:
Start regular retrospectives with a more extensive retrospective 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 technical or process debt).
Reduce focus on task-level prediction and increase focus on delivering larger projects or hitting goals.
Reduce focus on work delivery and increase focus on the impact of work.
If the team changes significantly... return to step 1.
Key Points
Early teams commit to tasks or features, while mature teams commit to abstract concepts.
Rapid growth necessarily disrupts early trust patterns. (ref)
To rebuild trust, focus on predictability, not speed.
The journey to rebuild trust begins with the team developing a shared understanding of the current reality and then aligning expectations about future developments. This is where the vision for effective teams comes in.
Grow gradually. Similar to an individual progressing from a new engineer to a team lead, the team will incrementally handle work with increasing levels of uncertainty.
Return to the measurement phase if the team changes significantly to reinforce fundamentals.
'Significant change' means a substantial team size change or a new leader like a TL or PM.
While traditions from being a more mature team should persist and help the team quickly return to its previous state, new team members have not built the same fundamentals as the rest of the team.
This post argues that building successful software for value-based care (VBC) requires a shift in mindset: create a Customer Relationship Management (CRM) tool, not just a better Electronic Health Record (EHR). VBC realigns healthcare incentives around long-term patient outcomes, succeeding through proactive, relationship-based care rather than transactional services. Technology's role is to support this relationship by helping care teams orchestrate interventions effectively. The most valuable tools are often simple and pragmatic, focusing on the unique, core needs of the care model and enabling proactive management of patient health.
Reflections on pausing the contextual recommendation tool, Kelp, concluding that its goal—getting people the right information at the right time—is nearly impossible for a third-party app to achieve. The core problem is technical: without deep, OS-level access to user data and behavioral signals, recommendations remain mediocre. True contextual help must be built into the operating system itself. The key business takeaway was the need to solve a highly specific, paying use case for a narrow audience before attempting a broad, cross-platform solution.
This reflection on leadership in a hyper-growth startup argues that self-management is the most crucial skill. Management in such a chaotic environment is inherently reactive and emotionally draining, not strategic and proactive. The key to effectiveness is to abandon "ruinous empathy"—the futile attempt to please everyone—and instead fiercely conserve personal energy for high-impact moments. This is achieved by accepting failure and tradeoffs as constant, communicating them transparently, and focusing on maximizing success in key areas rather than fighting every fire.
Brooklyn homeownership is not "worth it" as a financial investment. After accounting for renovation costs, high transaction fees, and the opportunity cost of not investing in the stock market, my profitable-on-paper sale was actually a financial loss. The true costs were the non-financial headaches: months of living in construction dust, battling city bureaucracy over permits, and fixing bank errors over property liens. I conclude that you buy a home not for the return, but for the control and satisfaction of making a space your own.
