Engineering Speed
In context
Engineering Speed: In context
Today's topic covers part two of my three-part Product Metrics for Platform Product Managers series.
If you missed my article last week, we covered high-level definitions of platform metrics, questions to ask yourself when you start thinking about measuring, and a few concrete examples. You can re-read it again here.
Before we dig deeper into Engineering Speed, I must confess that I have a love-hate relationship with Speed. If you have been reading my newsletter for a while, you know that I am a long-distance runner, and I have spoken about some lessons I brought from running into PM'ing some time ago.
You also know that I am big on definitions so going back to basics, let’s look up the official definition of Speed. If we use it as a noun, Speed is defined
as the rate at which someone or something moves, operates, or is able to move or operate.
Simple, right? Not really.
One of the most inspirational runs I ever did was a 75-minute guided run with Nike Running Global Head Coach
and Evan Jager. Evan Jager is a two-time Olympian and American record holder in the 3000m steeplechase. He is one of the few runners I admire and listen to when running. Him and Joanie Benoit Samuelson but I digress.This particular run stuck with me because Evan said something significant about Speed, which often gets missed.
"You often think you need to be faster or get faster but must ask yourself, faster than what? What's your starting point?"
I am paraphrasing the quote from the guided run, but hopefully, it gets the point across.
If you are still here and didn't give up when I started talking about running, this is a key question to ask yourself when thinking about Engineering Speed.
If the organisation wants and needs to move faster, you must know your baseline and set an ambitious target within your current context. But first, start from the beginning.
Defining Engineering Speed
Defining Engineering Speed is essential for several reasons, but crucially, it brings clarity so that everyone in the organization understands what engineering speed means. This shared understanding is excellent for effective communication and alignment of goals.
Once something is defined, it is also easier to measure. Without a precise definition, it is challenging to quantify pretty much anything, let alone Engineering Speed.
To put this in context, here is a sample from an initiative I previously worked on to define and measure Engineering Speed.
At a team level, Engineering Speed is the rate and ease at which Product Teams deliver value to the users.
At an organisational level, Speed is the rate and ease at which we deliver value to our customers.
How to measure Engineering Speed
Measuring Engineering Speed is essential for understanding the rate at which you deliver value to your customers and staying ahead.
To achieve this, you can track key metrics that measure the efficiency and responsiveness of engineering processes. These are industry standard metrics and are for guidance only.
They should be tracked and measured but not be considered the gospel of Speed.
Examples:
Cycle time is the total time taken to complete a task or process from start to finish.
Lead time measures the time taken from when a request is made to when it is completed.
Throughput measures the number of tasks or processes that can be completed in a given period.
Bug resolution time measures the time taken to identify and resolve defects or bugs.
Test automation coverage measures the percentage of tests that are automated.
Change failure rate measures the percentage of changes that fail.
Deployment frequency estimates how often changes are deployed to production.
Customer feedback loop time measures the time taken to receive and incorporate customer feedback.
Feature adoption rate measures the rate at which customers adopt new features.
I can't stress this enough, but different industries and engineering domains may prioritise specific metrics based on their unique goals and objectives. Therefore, choosing metrics that align with the organisation's overall strategy is pretty crucial.
In continuation to the example, I gave you earlier about how I worked on defining Engineering Speed? These are some of the metrics I used in the same context:
Time to first PR
Lead Cycle Time
Adoption rate of internal tooling
Developer Happiness
Time to Recovery
Stale time
What not to do
Remember, at the beginning of the article, the second part of defining Speed? That part about being able to move or operate?
The one typical pattern that I have observed in my experience is the lack of understanding that other factors impact Speed in your organisation: hiring, culture, tools, lack of communication, lack of alignment on goals, bad hires, and the list goes on. Ignoring your context is the first (and probably the main) thing to avoid. What works for one team might not work for another.
Another no-go is focusing solemnly on Speed. While Speed is essential, it should not be the sole focus. Prioritising Speed at the expense of quality can lead to rushed, subpar work. But those two don't necessarily need to exclude one another, either. A tricky balance to strike!
While there are other no-gos, such as using vanity metrics and micromanaging based on metrics, the last one that I want to call out explicitly is neglecting feedback and qualitative data.
Any quantitative metrics you get that are useful should be complemented with qualitative data and feedback from engineers and stakeholders.
This provides a more comprehensive understanding of the factors affecting engineering speed.
This article is an oversimplification of Engineering Speed, but if you are to take one main thing from this, let that be that if you want to be faster, know your starting line.
See you next Friday!