There's no magic, 5-Hour-Energy-drink-infused punchbowl that'll help your engineering team suddenly start performing at accelerated levels.
It's a similar thing with any sort of team though: process, consistency, leadership, trust, talent, culture, retention, and intangibles all have roles to play. Tools can also help (ahem.) Dynamics, though, ensure you can't control every aspect of a team at once (and sometimes not at all.)
And yet the importance of teams upping their game is becoming more of a priority. Gartner predicts that "by 2023, 90% of organizations will fail to meet required release velocities to deliver full business value to their customers if they use a centralized release management approach in DevOps environments.”
So how can software delivery be accelerated while also mitigating risk and adhering to governance? We dive deep into that question in our ebook, "Reconciling Change Management and Continuous Delivery," however, we've gone one step further.
In a recent webinar, Cody De Arkland, Director of Developer Relations at LaunchDarkly, spoke with author, researcher, and the founder of IT Revolution, Gene Kim, about how teams can become high performing.
Even if becoming a high-performing powerhouse is an aspirational goal at the moment, getting your team's collective brainpower focused in that direction is a good start. You can watch the full webinar below or scroll down for some of our key takeaways.
What is a high-performing team?
We're not going to argue with DORA about what constitutes a high-performing team. In their 2021 assessment, a high-performing team:
- Deploys between once per week and once per month
- Has a lead time for changes between one day and one week
- Has a time to restore service of less than one day
- Owns a change failure rate of between 16% and 30%
In our recent report, Release Assurance: Why Innovative Software Delivery Starts with Trust and Psychological Safety, we surveyed 500 engineers and found that a lot of teams are already either releasing several times a week (43%) or several times a month (30%). Could those numbers be higher? Absolutely, but let's give some context.
According to DORA, elite teams, which could be considered a notch above high-performing teams, do the following:
- Deploy multiple times per day
- Have a lead time for changes of less than an hour
- Have a time to restore service of less than an hour
- Owns a change failure rate of 0%-15%
In our Release Assurance report, from a simple deployment cadence standpoint, only 12% of teams met the criteria of even deploying multiple times per day.
So whether you're a low-or-medium performing team looking to up-level to the high-performing category, or even a high-performing team that wants to become elite, Gene had some pieces of advice that we've listed below in no particular order.
1. Measure lead time
It's tough to know whether or not you're a high-performing team if you're not tracking it. There are a variety of metrics to use, depending on what you're trying to accomplish, and DORA offers plenty of suggestions for what to track.
The most-well known DORA metrics are:
- Change Lead Time
- Deployment Frequency
- Change Failure Rate
- Mean Time To Recovery (MTTR)
Among Gene's favorite DORA metrics are lead time. "The one I really love there is code deployment lead time," he says. "We specifically start the lead time clock when changing to the version control, through integration, through testing, through deployment, so that customers are saying thank you. High performers are doing that in one hour or less, whereas lower performers might take two orders of magnitude more than that. That is so important because, in my mind, it's the measure that we have the most control over."
2. Culture predicts performance
During a talk at LaunchDarkly's Trajectory conference in 2021, Dr. Ron Westrum detailed the disparity in performance between different types of company cultures. For instance, companies that have cultures where frequent and transparent communication was encouraged, without the fear of retribution, had higher rates of success.
On the flipside, according to research, in the worst organizations, information is kept secret, those who share bad news are disciplined, and failures are covered up.
"On the other hand, in the highest performers and the safest organizations, we seek information," Gene says. "We train messengers to tell bad news. We encourage bridging between teams because we know that it is everybody's job, just like uptime and availability isn't just an office job. It's everybody's job, especially developers. When bad things happen, it causes a genuine sense of inquiry.
"I love that because in a system where deployments are terrifying, consequential, globally catastrophic, and we punish messengers who deliver bad news, if you connect those dots together it doesn't take you to a good place; however, if we have lots of visibility, lots of feedback at work, when things go wrong they cause small problems not big problems, we can do that across the entire organization. We can deploy safely and when bad things happen, we can have honest conversations about it, have deep conversations about what we can do to make it safer. That takes you in a totally different direction."
3. Architecture is everything
How your software is architected has enormous ramifications for how teams communicate and collaborate.
"Nothing impacts the daily work of developers more than architecture," Gene says. "I think it just shows how important it is that if you want teams to work independently, safely, collaboratively at the edges without being dependent upon everyone else in the organization, you have to have an architecture support center. You can't get teams innovating and unleashing the full creativity of everyone on those teams if you're coupled to everyone else."
4. Increase visibility
Being able to see the impact of your software in real time wasn't something that was always available to developers. Now that we have the ability, we should be using it.
"Can we actually see what is going on in production?," Gene asks. "Do we have to open up a ticket and wait a week just to get a metric production like in the old days, or can we get that on demand? No authorization allowed, any developer can do that. Telemetry was certainly one of those things. You can actually see what you're doing. I love the quote, 'Whether we are launching a rocket or performing surgery, it helps to see what you're doing.' In the game of software, it definitely helps to see what you're doing."
5. Reduce deployment anxiety
If your team is worried about deploying, that's not going to help your overall trajectory. Creating an atmosphere where it's okay to fail is crucial. Sometimes, that looks like breaking down a release into smaller pieces, so the risks are less. In any case, starting with the simple act of trusting your teams is a great start.
"If deployments are painful and we have fear of them, that's going to be highly correlated or inversely correlated with how good we are at doing deployments," Gene says. "This shows how good the human brain is at associating fear with pragmatic activities."
6. Decoupling deployments with feature flags
Releases need to be decoupled from deployments to improve the quality of your software. "In the old days, the only way we could get a feature to a user is by doing deployment," Gene says. "The notion that we can actually get all the capability in production and then change it with a feature flag? That is a complete game changer."
Gene used an example of the launch of Facebook Chat in 2008. At the time, it was one of the largest undertakings the company had ever done. And a reason the launch was so successful was because the company did not just ship the release and wait to see what happened.
"The fact that they could do testing in production for nearly a year is what enabled them to scale up to hundreds of millions of customers and get it right 'the first time,' Gene says. "It looked like the first time, but in reality, they were testing in production with ever larger subsets of customers. That's what made it look like a flawless release. It was only by decoupling deployments from the release."
7. Deal with technical debt
Technical debt is one of the least tantalizing terms in all of engineering, and yet the importance of managing it cannot be understated. Gene points to a response given by Jean-Michel Lemieux, formally the former VP of Engineering at Atlassian and CTO of Shopify. When he was asked how he allocated resources to R&D cycles, he gave an interesting response. According to Gene, Lemieux said that he spends 50% of R&D cycles on platforms: infrastructure platforms, service platforms, or even libraries. With the remainder of his budget, he then spends 40% on features and 10% on experiments.
"Just to show how different that is," Gene says, "most organizations, even the great ones, probably spend about 80% on features and then they jam everything else in that 20%. The quote (from Lemieux) is: 'If you don't spend 50% of dev cycles on these platform-like capabilities, failure is preordained.' That notion of having these hard boundaries between systems can only come through this notion of what's called platforms."
Looking ahead
There is no endpoint to becoming a high-performing or even an elite team. Much like keeping your stack optimized, it'll always be an ongoing process. There are lots more pieces of advice to be found in our talk with Gene, and we remain committed to helping you make the most of your next release.
.webp)
