Ship better software, faster, with the Atlassian Software Collection
Help your engineering teams measure and improve developer productivity, software quality, and team velocity with Adaptavist as your partner from activation to enterprise scale.
Why time-to-first-commit is the business metric you're not tracking
Share on socials
From 80 days to four: why time-to-first-commit is the business metric you're not tracking
Philip Papp
Published on 6 May 2026
3 min read
Philip Papp
Published on 6 May 2026
3 min read
Jump to section
Jump to section
Why this number reveals so much
What good looks like
Where DX fits in
The competitive case
Most engineering leaders can tell you their deployment frequency. Far fewer can tell you how long it takes a new hire to make their first commit to production. That gap matters more than you think.
In conversations with engineering leaders across industries, we consistently hear the same story: a new developer joins, spends days chasing access, weeks decoding undocumented dependencies, and months before they're genuinely contributing. One organisation we worked with had driven that window down from 80 days to four. Not through heroics, but through relentless automation of onboarding and self-service provisioning.
The difference between those two numbers isn't a people problem. It's a systems problem.
Why this number reveals so much
Time-to-first-commit isn't just a measure of how quickly someone can push code. It's a proxy for how well your engineering environment is actually working. How discoverable are your systems? How automated is your provisioning? How clear is ownership across your services?
If a developer can't make a simple change on day one, that tells you something important, not about the developer, but about the friction built into your platform.
There's also a hidden cost that rarely gets calculated. Getting a new hire up to speed doesn't just consume their time. It draws in managers, team members, HR, and platform teams. That overhead compounds across every new joiner, every team transfer, every contractor onboarded mid-project.
Automating the process doesn't just help developers. It gives everyone else their time back.
What good looks like
The organisations making real progress here share a few common characteristics. They have a single, well-understood onboarding process, not a patchwork of team-specific rituals. They've instrumented that process so they know where time is actually being lost. And they've built self-service tooling so developers can provision environments, access documentation, and understand service ownership without raising a ticket.
Internal developer portals play a central role in this. A well-implemented IDP gives new joiners a single place to understand what their team owns, how services connect, and what standards apply, without needing to interrupt a senior engineer to ask.
Where DX fits in
This is precisely the kind of friction that DX, now part of Atlassian's Software Collection, is built to surface. By combining quantitative signals with qualitative developer feedback, DX makes the onboarding experience measurable and connects it to the broader picture of developer productivity across the organisation.
Integrated with Atlassian's existing tooling, it means engineering leaders can move from gut feel to data. Not just "onboarding feels slow" but "here's where time is actually being lost, and here's how it's affecting delivery."
DORA metrics are a solid foundation, but they won't tell you this story. Deployment frequency doesn't capture what happens before a developer can deploy anything at all.
The competitive case
Organisations that invest in this now will retain better engineers and onboard them faster. That compounds quickly. Two years from now, the gap between those who've built this capability and those who haven't will be visible in delivery speed, retention rates, and how quickly they can absorb growth.
Time-to-first-commit is one of the simplest signals of organisational health. Start measuring it.
Want to learn how engineering leaders are turning developer experience and platform engineering into a competitive advantage?
Watch our fireside chat webinar where our experts explore the real business case for investing in developer experience.
Related content
Read more
Written by
Senior Strategic Advisor
Philip Papp is a DevOps leader combining deep technical expertise with strategic leadership across AWS and Kubernetes. With 8+ years of experience, he helps organisations build secure cloud platforms, lead high-performing teams, and modernise their infrastructure.
Related content
Read more