How To Create Compound Efficiencies In Engineering
Improvements in your engineering team's workflow don't occur independent of each other.
If there’s one word that will define engineering and tech in 2023, it will be “Efficiency.”
From Meta to Google to early-stage startups, tech companies have gone from a “growth-at-all-costs” mindset to figuring out how to get more out of the teams they have. This focus on efficiency is usually seen as a way to drive two essential company goals:
Improve quality and speed of software delivery; and
Enable engineering teams to have a more significant impact on the business bottom line.
Yet most of the attention-grabbing “efficiencies” are one-time decisions, such as flattening teams, cutting middle management or moving managers into individual contributor roles.
Sustainable, ongoing improvements in efficiency come from tools, processes, and behaviors that touch everyone in your engineering organization every day. They happen without having to make conscious decisions to be more efficient all the time. These efficiency improvements are organizational habits.
As the milestone book Atomic Habits laid out, the key to life-changing habits is adopting one effectively and then layering another desirable habit on top of it.
The same is true for efficiencies in software engineering. When your team adopts one efficiency, sees it bear fruit, then adds the next efficiency habit on top of it, the result is compounding efficiencies and elite performance.
In this blog, we’re going to lay out in practical terms the power of compound efficiencies as experienced by real dev teams out in the wild
Compound Efficiency No. 1: Real-Time Visibility Into Metrics Paired With Guidance On What “Good” Metrics Are
A great way to understand the first compound efficiency is with an analogy to another commonly discussed goal: Losing weight.
If you ask a nutritionist what the most effective diet is, they’ll often tell you all diets are effective.
They’ll tell you the reason most diets help you lose weight is they give you conscious visibility into what you’re eating along with what’s a “good” amount of food consumption for your body especially if that second part is personalized.
By knowing your calorie intake, and getting guidance on what good eating is, you organically move towards a more healthy weight.
The same holds true for productivity in engineering teams. Proven, organic efficiencies happen when devs and managers in your engineering organization have:
Real-time visibility into important engineering metrics, like cycle time, review time, deploy frequency, planning accuracy, and more.
Guidance on what “good” metrics are for each of the above.
To understand just how impactful this compound efficiency is, LinearB studied over 2,000 dev teams as they implemented visibility and guidance on metrics, and looked at how they were performing months later.
The data was even more impressive than we had imagined. Teams who implemented this platform saw:
PR sizes improve (decrease) by 33.2%
Cycle time improves by 47.27%
Review time improves by 46.82%
Pickup time improves by 48.75%
With these workflow improvements in place, the engineering teams could now build on top of them with our second compound efficiency.
Compound Efficiency 2: Automating Pull Requests & Code Reviews
LinearB’s data scientists conducted a deeper analysis of the workflows in thousands of dev teams, uncovering further insights into industry-wide inefficiencies in dev processes.
The No.1 most inefficient part of the development process was occurring between coding and deployment. Pull (or Merge ) requests, and the attached code review process were by far the biggest bottleneck in software development.
Pull requests and code reviews are a natural source of friction - as they required coordination between several team members; are typically asynchronous; and may require multiple feedback cycles until code can be merged to the upstream branch. This leads to the following key findings:
The average cycle time for a piece of work (first commit to deploy) is 7 days
Half of all PRs are idle (e.g. no one is actively working on them) for at least 50% of their lifespan
Cycle time and idle time doubled for pull requests of 200 lines of code, compared to pull requests with just 100 lines of code.
With this huge drain on productivity identified, researchers dove in to figure out the cause of these poor performance metrics. After qualitative and quantitative investigation the developers and data scientists found that the modern pull request and code review process was being hammered with 4 key problems:
There is typically no formal process for getting pull requests (PR) assigned.
No standardization or best practices guidance for PR size.
Teams treat all PRs with equal importance despite their different risk levels.
A total lack of visibility into PR context or how long it will take to review (until it’s opened).
With the problem and its causes identified, engineers went about ways to use automation to solve them. A tool named gitStream was released that would help streamline workflows between coding and deployment.
gitStream would allow engineers to automatically…
Auto-assign reviewers.
Add estimated time to review tags to pull requests.
Segment pull requests by risk to the repo (low risk vs. medium risk vs. high risk).
Introduce the option of auto-approving low-risk PRs.
After months of research seeing how teams who had already implemented the first compound efficiency performed with the addition of gitStream, data scientists were amazed to see the continuing improvements teams made.
Further efficiency improvements made after adopting gitStream were…
PR size was reduced by an additional 28.18%
Cycle time was shortened by an additional 61.07%
PR review time improved an additional 38.14%
Pickup time decreased by an additional 56.04%
To carry on with our analogy - these improvements are like adding exercise to your healthy eating habit - the effects compound.
Compound efficiency 3: Build & Protect Developer Focus
Something misunderstood outside of engineering departments (and also within them) is that developers need to be treated as true knowledge workers. This means engineers require time to problem-solve, think, and create.
Developers are not robots on a production line who can start being productive on demand, they’re creative builders.
That’s why, in addition to providing visibility into metrics and automating workflows, engineering leaders should provide developers with core blocks of uninterrupted time to code.
Two foundational data points to understand the importance of protecting an engineer’s focus time:
It takes developers 23 minutes of uninterrupted focus before they hit their flow state. The period where they are being truly productive.
Engineers at large companies have the least amount of focus time: 16.9 hours per week vs. 22.5 hours per week at smaller companies. This means some engineers spend over half of their week in an unproductive state.
The good news? The importance of building and improving focus time for its impact on productivity and the business as a whole is finally being recognized by engineering leaders.
76% of managers say more focus time leads to more revenue.
90% of leaders say more focus time increases productivity.
80% of engineers say more focus time translates to faster production.
Creating quality focus time isn’t something that can be solved by individual developers, it needs to be driven by engineering leaders who have the ability to help shape their team’s schedules.
Some proven ways engineering leaders can maximize their team’s focus time include…
Never, ever allow developers to have fragmented calendars.
Keep mandatory meetings at the same time all in one block.
Use a tool like CalendarHero to automate your meeting schedules.
3 steps to harness the power of compound efficiency in engineering
You need to improve your team’s focus time. The average developer has way less than they should. You need to provide them with blocks of uninterrupted time to code. Try CalendarHero to start out.
You need real-time visibility into your team’s metrics. You also need to use benchmarks to define “good” for your team–that way you can set data-backed goals and decide on what and how to improve.
Reduce the No. 1 inefficiency in cycle time - code reviews and the PR process - using automation tools like gitStream.
This article was written by Yishai Beeri
Like What You Read? Check Out “What Metrics Make Engineering Teams Elite: A Free Look Inside The Top 10% Of Engineering Orgs”
LinearB analyzed over 2,000 dev teams to create an exclusive report tracking what engineering metrics make teams elite. The report goes into detail on:
How elite engineering teams measure their performance beyond DORA metrics.
What makes engineering teams elite in terms of the development lifecycle, developer workflow, and business alignment?
Explore how your team stacks up in terms of metrics like cycle time, deployment frequency, and planning accuracy.
Learn what tools elite software teams use to hit these industry-leading benchmarks.
I think that this boils down to the quality of the processes inside the company:
If your *workflow* is correct - effectiveness is inevitable. You will see improvement very fast.
For example, if you set up "time to code" and the focus is there, but your devs are working on the wrong task, or an ill-defined one, you won't find the efficiency you're looking for. On the other hand, if your workflow guarantees that your tasks are well defined, and that you code the right solution, you are already 90% there.
Tools like Fine are trying to take this approach today: https://www.fine.dev/
Full disclosure: I work at Fine.