Is 10x Really Possible?
There's a lot of talk in the industry about whether or not the "10x developer" really exists - is it possible that there are developers that are as productive as ten of their peers? I won't weigh in on that here, but I will say that there are 10x and 100x organizations. There are places that get far more productive work done with the same number of people at the same level of skill. How do you know if you're one of them? What's the yardstick you'd use to measure your organization?
Authors Gene Kim, Jez Humble, and Nicole Forsgren in a multi-year research project found the following four metrics serve well to indicate a technology organization's efficacy:
- Deployment Frequency - How often do you deploy to a production environment, app store, or similar?
- Lead Time for Changes - How long does it take to implement, test, and deploy a single change?
- Mean Time to Recovery (MTTR) - When a deployment causes a problem, how long does it take to fix that problem?
- Change Failure Rate - How often do changes cause problems?
Here's how this breaks down for high, medium, and low performing organizations:
| Metric | High | Medium | Low |
|---|---|---|---|
| Deployment Frequency | On demand (multiple times per day) | Between once a week and once per month | Between once a week and once per month |
| Lead Time for Changes | Less than one hour | Between one week and one month | Between one week and one month |
| MTTR | Less than one hour | Less than one day | Between one day and one week |
| Change Failure Rate | 0-15% | 0-15% | 31-45% |
For some organizations, the high performing column might be terrifying! Many organizations can't conceive of a scenario where deploying to production multiple times a day is possible or even desirable. The idea of a change that could be, start-to-finish, in production in an hour might seem like abject chaos. Such organizations have lots of seemingly good reasons why such things would be bad: change management takes too long, you can't test fast enough, you want to wait for off-peak hours to deploy, and so on. The challenge is that these "reasons why" are probably causing quality problems and are likely preventing growth in capabilities. If you don't measure up the way you'd like to, we can help you figure out how to improve the pace of delivery without sacrificing quality. Let's talk.