Team rituals for continuous improvement

As your startup grows, responsibilities that used to belong to a single individual will be owned by teams and, eventually departments. This transition is where startup operations become critical. Things that used to be easy to achieve without procedures or policies become increasingly ineffective and complex as teams grow, and standardisation/operational innovation is usually the solution. So, while building teams starts with recruiting and fostering great talent, establishing sensible and effective ways of working is increasingly important as your team grows and their responsibilities become more complex. As new teams emerge within your startup, rather than sticking to what has always worked (or the way the progenitors of each team worked), you should adopt practices and rituals for self-improvement.

Self-improvement starts with metrics. For some teams, it is easy to measure effectiveness because feedback loops (i.e., the delay between action and outcome) are tight. By measuring effectiveness, you can quantify the positive or negative impact of any changes to your ways of working. For example:

• Customer Service teams can be measured by how many support cases they can complete, which can also be broken down by individual or sub-team. You can also quantify their effectiveness by measuring how long it takes to respond to support cases, how many responses they submit to resolve a customer problem, and how satisfied customers are with the service they receive (i.e., CSAT).
• Account executives can be measured by how many deals they close, the revenue value of these deals, the average size of each deal, how long it takes to close deals, and how likely the customers they sell to are to churn.

Tracking metrics like these will allow you to identify opportunities for improvement and observe how changes to your ways of working impact your team’s effectiveness. They also empower you to compare different individuals in similar roles to identify personal habits that do or don’t work. For example, you might notice that your account executives who mention pricing early in the sales process have a worse conversion rate but close deals much more quickly, ultimately leading to better results because they can filter out prospects who cannot afford your solution early in the sales cycle. Over time, performance baselines will emerge from metrics like these. You’ll know that effective customer service staff should be able to resolve a certain number of support cases each month, making recruiting, onboarding, and individual management much more straightforward.

Beyond metrics, there are several team and individual management rituals that promote self-improvement. While these will vary by startup and team, I recommend considering the following rituals:

• 1:1s between managers and individual contributors can be a critical venue for coaching. I’ve found that these work best when employees rather than managers lead them. This format empowers employees to manage their workload and outcomes, relying on their manager for support. When managers lead 1:1s, they often turn into delegation sessions with the individual contributor in the passenger seat.
• Team-wide retrospectives are opportunities for teams to reflect on results and propose strategic and operational improvements. For these sessions, it’s valuable to look directly at the data: review your metrics or backlog in real-time rather than reflect on how you felt things went. These should occur regularly (e.g., each sprint or month), and you should organise ad-hoc retrospectives (i.e., post-mortems) after particularly disruptive incidents.
• Peer-to-peer work reviews. Individual contributors should review each other’s work. For example, engineers should review each others’ pull requests, and support agents should monitor each others’ calls for call coaching. While many managers will try to own this work for quality assurance purposes, doing so relies too heavily on the availability of managers, is challenging to scale, and deprives individual contributors of a pivotal opportunity to improve their technical and leadership skills.

As a leader of a single team or division, it can be tough to affect change in groups other than your own. However, for your startup to improve, every team needs to be responsive to feedback from customers, the market, and internal stakeholders. Many teams struggle because they receive much more feedback than they can reasonably respond to. This challenge is tough when feedback is given in an anecdotal format because it is difficult to equate individual anecdotes with real business impact. As a team leader, you should make it easy for other teams to give you feedback in a format that will be useful. Similarly, if you’re struggling to convince other teams and leaders to take your input seriously, try to capture and format your feedback in a way that will be valuable to others. For example, it’s difficult for product managers to prioritise new features based on anecdotes about lost sales. By instead capturing product feedback against every lost sale in your CRM, you can empower yourself to make a well-informed argument for how the development of a particular feature could impact the business. By taking a data-driven approach to collecting feedback for your team and handling feedback you provide to others, you will better encourage change across groups.

Lastly, teams that receive a lot of inbound work from others should embrace asynchronous backlogs. By receiving requests via chaotic means like email, messages, conversations, and calls, teams are constantly disrupted by demands and spend too much time managing these requests. Instead, teams should standardise how others submit work, and inbound work should live in backlogs that can be reviewed and prioritised asynchronously. For example:

• Technical writers are partly responsible for improving existing product documentation. People should submit feedback regarding these documents to the team via a standardised form (perhaps a feedback form embedded directly with each product document) that funnels requests into a team-wide backlog (e.g., in JIRA or GitHub Issues).
• Sales engineers responsible for delivering technical demonstrations to customers could provide a calendar booking link that enables account executives to organise demos easily.
• Support engineers responsible for helping customer service staff with customer escalations might receive support tickets in help desk software.
• UX designers responsible for gathering customer feedback might receive leads for interviews in a team-wide backlog that can be prioritised and organised.

When you funnel requests into an asynchronous backlog, you remove the need to respond immediately to each new request. This gives you the freedom to tackle your backlog on your terms. You might run a monthly prioritisation session and give each team member a few weekly tasks from the top of the backlog. You might flag urgent requests for immediate response and group lower-priority requests into larger projects.