The measurement problem isn't technical — it's philosophical, and Stoicism has been solving it for two thousand years.
Have a question about this? Bring it to Aurelius.
35% higher revenue growth separates high-performing engineering organisations from their peers — and most CEOs cannot say, with any confidence, which side of that line their own team stands on.
McKinsey has confirmed what many executives feel but rarely say aloud: the engineering productivity question is now "one of vital importance not just for the CIO but also for the CEO and CFO." The Pragmatic Engineer documented the resulting tension with unusual clarity — non-technical leaders are "increasingly frustrated by CTOs throwing up their hands and saying software engineering is too nuanced to measure." That frustration is legitimate. A 2024 Stripe/Refactoring.fm survey found that developers spend only about 55% of their time on real development work, and 57% of engineers believe they could work more efficiently. Executives almost never have visibility into either number.
The gap between what leadership suspects and what they can verify is not a data problem. It is a conceptual one. And until you name the concept you are missing, no dashboard will close it.
Conventional advice says: pick a framework. DORA metrics. SPACE. Value stream mapping. Velocity. Cycle time. Deploy frequency. These frameworks are not wrong — they are simply answers to the wrong question.
The wrong question is how much are they doing? The right question is what are they causing to happen?
When you measure deploy frequency in isolation, you reward teams for shipping small, inconsequential changes rapidly. When you measure velocity, you reward story point inflation. When you measure lines of code, you reward verbosity. Each metric, applied without a clear understanding of what it is actually a proxy for, teaches your team to optimise for the number rather than for the outcome the number was meant to represent.
The demoralisation you sense in your engineers is not a side effect of imperfect metrics. It is the predictable result of people who care about their craft being told, repeatedly and systematically, that what they care about does not count — only the number does. Engineers with a serious inner life feel this as a kind of professional erasure. The ones who stay learn to perform the metric. The ones who leave were often your best.
The external framework imported to fill the vacuum — whatever the consultant sold the CFO last quarter — will not solve this. It will systematise the wrong question at scale.
In Book VI of the Meditations, Marcus Aurelius writes: "At every moment keep a sturdy mind on the task at hand, as a Roman and human being, doing it with strict and simple dignity, affection, freedom, and justice — giving yourself a rest from all other considerations."
The instruction is not to ignore output. It is to locate the standard of judgment inside the work, not in the instrument used to observe it.
This is the Stoic distinction between the hegemonikon — the ruling faculty, the part of a person that actually deliberates and chooses — and the external observable result that everyone else can see. Stoic philosophy does not dismiss results. It insists that results are downstream of something invisible: the quality of attention, judgment, and character brought to the task. Measure only the result and you are measuring a shadow. You are ignoring the thing that produced it.
This reveals the precise error most engineering measurement frameworks make. They are designed to be legible to non-technical leadership. Legibility is a legitimate goal — but legibility and accuracy are not the same thing, and when they conflict, most organisations choose legibility. The consequence is that you build a reporting system that is easy to read and systematically misleading.
What most people miss here is harder to accept than it sounds: your metrics are not neutral instruments. They are instructions. Whatever you measure, you are telling your engineers what you value. If you measure deploy frequency, you are telling them you value speed of release. If you measure ticket closure rate, you are telling them you value the appearance of progress. If you measure utilisation — hours logged, tasks completed, standups attended — you are telling them that their time is the asset, not their judgment.
Aurelius understood, from the position of someone who commanded armies and governed an empire, that the leader who cannot distinguish between effort and discernment will eventually lose both. The soldier who charges because the metric rewards charges, not because the situation demands it, is more dangerous than no soldier at all.
Therefore, the question you need to ask of every metric before you adopt it is not "is this measurable?" but "what behaviour does this reward, and is that the behaviour I actually want?" Cycle time rewards speed. But sometimes the right cycle time is long, because the problem is genuinely difficult. DORA's change failure rate rewards stability — but a team working on genuinely novel infrastructure will have a higher failure rate than a team maintaining a stable, unchallenging system. Raw comparison between them is not information. It is noise dressed as data.
For someone in your position today — a leader trying to establish credibility with a board that wants numbers, while maintaining the trust of engineers who know the numbers are incomplete — the Stoic path is not to abandon measurement. It is to be honest, in every meeting where these metrics appear, about what they do and do not capture. That honesty is not weakness. It is the examined life applied to organisational leadership. It is also, practically, the only thing that will stop your best engineers from concluding that you do not understand their work.
The harder truth that conventional advice consistently glosses over: flourishing engineering teams are not built by measuring what is easy to see. They are built by leaders who are willing to develop enough understanding of the work to see what the metrics cannot show — and who say so clearly, rather than hiding behind the dashboard.
There is no single framework that solves this, which is precisely why every consultant offers one. What works is a posture, not a product.
Start with outcomes, not activities. The question is never "how many pull requests did we merge?" The question is "what changed in the product or the system as a result of what this team did, and did it matter?" This requires you to know what mattering looks like in your context. That requires conversations, not dashboards.
Use metrics as diagnostic tools, not scorecards. Cycle time that is suddenly three times longer is a signal worth investigating. It is not a verdict. Before you present it as evidence of underperformance, ask what changed. New team members? A particularly complex domain? Technical debt that finally had to be addressed? The metric tells you where to look. It does not tell you what you will find.
Build in explicit qualitative review. Quantitative metrics will always favour what is easy to count. Counter this deliberately. Every quarter, ask your engineering leaders one question: "What did we do well that the metrics did not capture, and what problem are we carrying that the metrics make invisible?" Make that conversation as formal as your sprint review. Write it down. Act on it.
Separate measurement from evaluation. The moment a metric is attached to performance evaluation, engineers stop using it as a mirror and start using it as a performance. This is not a character flaw — it is a rational response to incentives. If you want honest data, keep measurement separate from consequences for as long as you can.
If your team is carrying structural debt that is distorting every metric you try to use, the course Kill Technical Debt Before It Kills Your Engineering Team's Velocity addresses the removal process directly. If the problem is that your architecture has grown in ways that make output measurement almost meaningless, Stop Your Microservices from Becoming a Distributed Monolith Nobody Can Debug is worth your time. And if what you are actually trying to do is build the team structure that makes measurement meaningful in the first place, Build an Engineering Team Structure That Actually Ships Products starts there.
Before you close this tab, do one thing: pull the last metric you reported upward about your engineering team and ask a single question — what behaviour did reporting this number reward?
Not what the metric was designed to measure. What behaviour, in practice, did the act of measuring and reporting it encourage? If you cannot answer that confidently, you are not yet in a position to know whether the metric is helping you or instructing your team in the wrong direction.
Then schedule thirty minutes with one engineer — not your CTO, not your VP of Engineering, but an individual contributor — and ask them what they worked on last month that they are proud of, and whether that work shows up anywhere in the team's numbers. Listen to the answer. Do not try to fix it in that meeting. Just listen.
What you hear in that conversation will tell you more about the health of your measurement system than any framework comparison will.
Go deeper with Aurelius
Apply this to your actual situation. Aurelius will meet you where you are.
Start a session