‍How can I accelerate developer velocity?

Cultural & Process Tactics:

Ask your team what matters & follow through. Your team probably knows best what’s slowing them down; ask regularly and take their word at face value. Identify the biggest, most common problems, and tackle them. 

  • Simple version: conduct a post-sprint developer happiness index. “Are you happy?”; “What worked well this sprint?”  These are simple questions that lead to powerful insight.
  • Leverage emerging tools like getdx.com, the developer experience platform. GetDX offers surveying… and benchmarking (“yes, build time is slowing devs down… but is it worse/better than other orgs?”)
  • Actually fix things. If something is slowing your team down materially, put resources against it and make sure to fix it now. Don’t let challenges fester.

Establish a clear vision, be clear about “great”, hold the team accountable.

  • Clear vision: most developers want to do great work; but sometimes they lack a clear understanding of where the business is going. Leaders should paint a clear picture of the near- and long-term vision.
  • Be clear about “great”: are you intentional about what great work looks like at your company? What high-quality code looks like? Are these standards clearly defined and documented?

Look beyond the Engineering organization; what role is Product playing? One member  found a huge source of friction: Product introducing new requirements mid-sprint

  • Simply acknowledging the issue helped resolve it, almost immediately;
  • A secondary benefit: Engineering and Product collaboration improved significantly once this was an honest and open discussion.

Issue detection & resolution in focus. Think about optimizing these independently. 

  • Detection: how do we minimize time from introduction to identification of an issue? Solutions include, e.g., investment in instrumentation and metrics.
  • Resolution: solutions include, e.g., investing in better roll back / roll forward tooling
  • Culture: “lower the cost” of making a mistake; rather than team members trying to obfuscate production issues, make clear that what matters most is finding & fixing them.

Performance Management & Metrics:

Measuring team efficacy through DORA Metrics

  • A large number of unicorn-scale CTOs have embraced DORA metrics as a more objective measure of team performance
  • Overview here: “The four metrics are: Deployment Frequency, Mean Lead Time for Changes, Mean Time to Recover, and Change Failure Rate”
  • Additional details at DORA Research overview, DORA diagram

Augment or replace some OKRs with SLOs?

  • SLOs: a number of CTO have recently moved toward SLOs to replace OKRs in some instances; see Atlassian on their hybrid of OKRs and SLOs.
  • Is your metrics tooling part of the problem? One team’s OKR tool was too rigid and caused delays and frustration; they replaced it with a lightweight reporting structure customized to their business.

Active & transparent performance management. Case study of one company’s process:

  • Managers force-rank each of their specific team members
  • Team-level rankings are feather interlaced, e.g., by comparing a median engineer to the median engineers on other teams
  • For the top 10%: invest heavily. How do you make sure they’re content & maximally productive? How do you create a career path for them?
  • For the bottom 30%: have an open conversation; how do we improve your performance?

‍

Novel ideas for cost reduction

Save money by moving certain workloads on prem (!). 

  • Several companies have taken isolated workloads (e.g., asynchronous recurrent ML / data processing) and moved them to owned hardware
  • In practice, this was as simple as buying previous generation (old/used) equipment, and siting it at a colo.
  • As one leader put it, “dumb boxes sitting around will be better than even the most optimized AWS instance in the world”

Look critically at all of your developer tools. If you could save $X/yr across Y developers, where would you invest the savings?

  • If you look at the all-in cost of your tools on a per dev, per year basis, you can evaluate total ROI, turn certain things off, and reinvest capital 
  • Can you consolidate two tools into one? One team stopped using Jira and started tracking issues in GitLab, saving money and centralizing all data in one place

Choose boring technology. Fear, Uncertainty, and Doubt (FUD) are among the biggest killers of developer productivity (see boring technology.club)

  • If developers aren’t certain how something will behave in production; don’t trust their tools; or are spending time learning new tools… you’re destroying productivity
  • Choosing simpler (or more boring) technology rather than the “hot” technology of the moment, generally results in more reliability and higher dev velocity.

Additional Links:

Additional Tools Mentioned:

  • GetDX - “helps you clear bottlenecks so you can increase your pace”
  • CodeClimate - “align initiatives with strategic priorities, accelerate software delivery, and drive continuous improvement”
  • JellyFish - “data-driven insights show how your engineering efforts align with strategic goals.”
  • Nave for tracking team metrics - “We Help Organizations Get Things Done Quicker”‍
  • Atlas - “The first teamwork directory to connect the dots across teams, their apps, and work — wherever it happens.” Atlas can be valuable if used at the product level, engineering level, or both