Why GitHub is investing in its own developer experience

GitHub’s engineering organization is also a GitHub customer. That means the tooling and infrastructure used to build GitHub.com directly shape the experience of the developers who use the platform—and of the engineers who ship it. The faster those internal systems run, the more quickly new features reach production.

The company is now launching a series of posts that look at the work happening behind the scenes to improve that internal experience. The focus is on efforts across engineering to modernize the development environment, strengthen system reliability, and reduce the time from idea to deployment. Early results include running on the latest version of Ruby, cutting application boot time, and rolling out smoother progressive deploys.

Measuring progress with the Four Key Metrics

To decide where to invest, GitHub’s teams are aligning with the Four Key Metrics of high-performing software delivery, as defined by DevOps Research and Assessment and drawn from the research of Dr. Nicole Forsgren:

  • Deploy Frequency. How frequently is the team deploying?
  • Lead Time for Changes. How long does it take to get code successfully running in production?
  • Time to Restore Service. How long does it take to recover from an incident?
  • Change Fail Rate. What percentage of changes to production result in degraded service?

The goal is that any investment in internal tooling moves the needle on at least one of these areas.

Cross-team work yields unexpected benefits

The projects have pulled in teams from across the organization, often asking engineers to dig into parts of the internal system they had not worked with before. That structure opens the door to new technical approaches and to collaboration across teams and disciplines. Engineers report that the payoff goes beyond metrics: faster boot times and easier debugging are exciting, but so is the chance to work closely with peers in other parts of the company.

The series opens with a look at how the CI workflow was made significantly faster. Future posts will cover additional goals, lessons learned, and the specific impact of the work.