How do we measure engineering team success?
In manufacturing, as well as software development, there are three, and only three, metrics that matter:
throughput - how fast customer requests are satisfied. AKA "velocity".
investment - discretionary time or money spent to increase throughput.
cost - non-discretionary time or money spent in normal operations.
The three can be used in combination with each other to fully express all that you need to know about engineering team success.
Throughput is how many customer requests are satisfied per unit of time:
It is very important to distinguish the completion of a customer request from the satisfaction of the customer. The request is relayed to the engineering team by Product, say, and is not directly elicited from the customer. This is exactly similar to how a waiter relays orders to the kitchen. You wouldn't want your engineers talking to customers anyway.
If the engineering team is pumping out requests at high throughput, and yet your customer is not satisfied, you have a problem elsewhere in the supply chain.
You wouldn't blame your chef for making the wrong dish, if it was the waiter who remembered the order wrong.
So: throughput is how many customer requests are completed per unit of time.
# Axiom
throughput = num_requests_completed / time
Investment is discretionary spending per unit time that is intended to increase throughput.
Examples of time spent with the intention of increasing throughput: Mentoring (pairing), meetings, refactoring or mitigating technical debt, direct education, code reviews.
Investment done deliberately and with care is the single highest leverage tool in software engineering. All Engineering protocols (and sadly most engineering leaders) simply do not understand this piece of the puzzle. They believe it is a mystery why some teams succeed and some teams fail.
The truth is the difference between a successful team and an unsuccessful one is there is at least one senior IC who is so bothered by the chaos of the status quo, that they invest their free time in improving their quality of life (which is to say, the team's throughput). Forget 10x engineers - these guys are the unsung heroes of engineering. They 10x everybody else.
Formalize this guy. He is your lead investor. Your Portfolio Manager, as it were.
(Engineers, Nota Bene: this is how to make the case for that rewrite)
So: Investment is discretionary spending that is intended to increase throughput.
# Axiominvestment = (hrs_in_meetings + hrs_tech_debt + hrs_learning + ...) / time
Cost is the expense of normal operations per unit time.
Cloud costs, hours spent fixing bugs, hours spent supporting software. These are not hard to find nor are they hard to classify.
Of course, we want to minimize costs because that directly increases net throughput. But cost minimization is a form of investment.
Important to note that we do not include wages as a team cost because it is not a number under the influence of the team. Put another way, the team cannot invest its time to decrease its wages. Wages are a higher level metric.
So: Cost is the expense of normal operations per unit time.
# Axiomcost = (cloud_costs + hrs_fixing_bugs + hrs_support + ...) / time
You will of course want to combine these three fundamental metrics to create useful derivative metrics:
net contribution - throughput minus cost
return on investment - d(throughput)/d(investment)
productivity - throughput / cost
I'm not sure why software is never broken down this way. My best guess is that existing engineering protocols (e.g. Agile/Scrum) create a strict policy that can be enforced asymmetrically by leadership. In effect, it removes autonomy from an engineering team while forcing all responsibility and accountability onto them. Heads I win, Tails you lose.
An entire book could be written on that topic, but if that's not what you want on your team, then you know what to do.
Throughput, investment, cost. Don't overcomplicate it.
To reply you need to sign in.