# Drive continuous improvement

Continuous improvement works best when teams can drive it themselves, rather than routing everything through leadership. Surveys, signals, notifications, and working agreements are the tools for that. Leaders should make sure their teams know how to use them — and have the mandate to do so.

The process follows a cycle: make work visible, spot patterns, take action.

<figure><img src="/files/6ZAxd0M5H9F7RHNqwSHk" alt=""><figcaption></figcaption></figure>

## **Make work visible**

[Developer surveys](https://help.swarmia.com/features/run-developer-experience-surveys) give your team a structured way to surface friction that doesn't show up in metrics — unclear processes, lack of autonomy, poor tooling. Twice a year is a common cadence, but you set it. Results help you spot when something is off and inform which working agreements to introduce or adjust.

Pair surveys with [investment distribution](https://help.swarmia.com/features/focus/balance-engineering-investments) to see how much time goes to KTLO — bugs, incidents, and maintenance. A healthy target is under 30%. If it's consistently higher, that's worth addressing.

## **Spot patterns**

Before setting up any agreements, check what Swarmia's [signals](https://www.swarmia.com/product/signals/) are already telling you. Signals proactively surface patterns in your team's work — too much work in progress, stale pull requests, an unexpected spike in cycle time — without you having to go looking. For each signal, Swarmia explains what happened, why it matters, and suggests next steps, such as adopting a working agreement to prevent the issue from recurring. Benchmarks help you understand whether what you're seeing is normal or an outlier compared to similar teams.

## **Take action**

Clear norms around pull request hygiene and work in progress protect engineers from the most common sources of friction. Limiting batch size and the number of open pull requests keeps work focused and reduces context switching. Shorter cycle times and review times help changes move to production without sitting idle.

Enabling an agreement in Swarmia is just the starting point — real change requires team commitment. Discuss it with your team first: agree on what you're trying to improve and why. Start with one or two [agreements](https://help.swarmia.com/features/working-agreements) so the team can build new habits before adding more.

Each working agreement can have a team [notification](https://help.swarmia.com/settings/team/team-notifications) attached. Exceptions — a pull request that exceeds the batch size limit, or a review that's taken too long — surface automatically in your team's daily digest.

## **Treat it as an ongoing practice**

When you run your next survey, check whether changes to working agreements have had an effect. Improved results mean you're on the right track. If they didn't change, that's an equally useful signal — and a prompt to revisit and adjust.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.swarmia.com/guides/drive-continuous-improvement.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
