Read or buy our book, Build: Elements of an Effective Software Organization →
- Product
- Pricing
- Customers
- Learn
BlogInsights for software leaders, managers, and engineers
ChangelogCheck out our latest product updates and improvements
Engineering Unblocked↗Catch interviews with software leaders on our podcast
BenchmarksFind the biggest opportunities for improvement
Book: BuildRead for free, or buy a physical copy or the Kindle version - About us
- Careers
Learn what “good” looks like with Swarmia’s software engineering benchmarks
Your best benchmark is your own baseline. But if you’re interested in quickly identifying opportunities for improvement, start here.
Drive engineering effectiveness with sensible benchmarks
Use benchmarks from modern engineering organizations to understand where your organization stands compared to peers.
Learn how to use these benchmarks→Change target:
Great
Great
Good
Needs attention
Engineering investment
A sustainable engineering organization requires investment in non-product work.
The distribution of engineering work, according to the Balance Framework
10% KTLO,
15% productivity,
60% on new things &
improving things
15% productivity,
60% on new things &
improving things
30% KTLO,
10% productivity
10% productivity
50% KTLO,
or < 10% productivity
or < 10% productivity
Flow efficiency
Idle work suggests frequent interruptions and priority changes.
The share of days an issue was actively worked on during its lifetime.
> 95% of in-progress
time is active
time is active
> 70% of in-progress
time is active
time is active
< 70% of in-progress
time is active
time is active
Batch size
Smaller batches of work tend to move through the system faster and have less risk.
The number of lines in most changes.
< 200 lines
< 500 lines
> 500 lines
Change lead time
Long lead times might be a symptom of overly large increments, frequent interruptions, or too much WIP.
How long it takes for a task to go from start to production. This includes:
< 24 hours
< 3 working days
> 7 working days
PR cycle time
Speeding up code reviews is often the most effective way to improve cycle time.
How long it takes for an open PR to be merged. This includes:
Coding time
Review time
Merge time
Coding time
Review time
Merge time
< 24 hours
< 3 working days
> 5 working days
Deployment frequency
Frequent deploys encourage smaller changes and enable rapid iteration.
How often new code gets released to users.
Continuously
Daily
Less than daily
Time to deploy
Rapid deploys enable quicker incident mitigation and encourage smaller changes.
How long it takes for most approved changes to reach production.
< 15 minutes
< 30 minutes
> 1 hour
Swarmia instantly gave us a baseline, and we could see historical information on where we were in terms of key metrics.
Tim Nott
CTO, FactoryFix
Find your engineering organization’s biggest opportunities for improvement.
Ready to go beyond simple benchmarks?
Swarmia gives everyone in your engineering organization visibility into three types of insights: business outcomes, developer productivity, and developer experience.
Swarmia both feeds and empowers our insights. It allows our engineers to dive deeper into the metrics in a specialized environment, which would make no sense for us to build for ourselves.
Walter de Bruijn
Head of Engineering Productivity at Miro
Get your baseline metrics by connecting to Swarmia.
