What is your developer experience like? How do you measure your team’s performance?

It’s very hard to define what a good developer experience is. Every engineering team wants to provide one. Some things are table stakes, such as: automated deployments to production for a given branch and git commit, tests running after each push on CI/CD, PR workflow with review step. There have been some highly-regarded attempts to measure devops objectively along these lines of common practices and capabilities of high performing teams, like DORA. At Coherence, we want to build tools that make it easy to measure and improve the KPIs that matter to you.

But high performance does not mean developers know how to use all their tools or that they feel that they’re empowered to do their best work. Something like developer NPS - can also be used for DevOps and in general teams that have invested in good tooling are happy about it in my experience. We believe that quality tooling helps with retention, time to value, and overall performance and productivity.

Not all metrics matter to all orgs, at least not equally. You should think about which KPIs matter to you. Metrics that might be important to your org:

Time to deploys (faster is better)
Time to detect errors (faster is better)
Average size of deploys (smaller is better)
Average frequency of deploys (higher is better)
Number of metrics monitored with proactive alerting (more is better)
Number of false positive alters (less is better)
Average time spent in QA stage (less is better)
% of bugs found in pro-prod (higher is better)
Time to recover in disaster recovery location (faster is better)
Lead time for changes (shorter is better)
Change fail rate (lower is better)
% of PR reviews where code is ran (not just diff viewed and tests ran in CI) - [higher is better]
Vuln detection time (faster is better)
Vuln detection rate (higher is better)
Vuln remediation time (faster is better)
Usage of dev tools
E.g. % of team looking at APM or logs
How quickly can they find the right data under duress?

Once you know what metrics you want your team to watch, you need to make sure that they’re able to do so. And also almost as important - kept up to date as metrics and definitions change. How current are your Devops documentation pages? Is your developer experience consistent between different services? Do all of your developers know:

where to observe metrics?
where to find logs?
where to see exception traces?

If you’re doing well on the above observability and knowledge metrics, how much time do you spend maintaining those tools and systems? If you’re asking yourself questions like:

How much expertise should it require to develop top-notch software?
Are you really giving your deployment tools the time they deserve?
How much does one hour of engineers time cost for new load in training and full loading?
How many hours do you think they waste on these kinds of issues?
How much more productive could they be if they didn’t waste all that time, especially when you consider that compounding in knowledge and skills overtime accumulates most of its returns at the end, marginally.
What if your development environment was a retention helper instead of an attrition excuse?
What if you had tools that helped your team focus on what you needed them to do to make your business better?

Come talk to us and take Coherence for a spin!

‍