I recently published the following picture (by the amazing
) illustrating where in software development to observe:
This is a visualization of a chain I’ve talked about before: Effort→Output→Outcome→Impact.
Effort—the work we do.
Output—the changes the user/customer sees.
Outcome—the changes in the user/customer behavior.
Impact—the profit we share with the customer.
My point was that the earlier in this chain you make your observations, the easier it is to observe (it’s easy to count hours spent programming) but also the easier it is to game the observations.
Conversely, the later you measure, the more difficult it is attribute changes to any one cause but the less subject the measures are to distortion. I can generate as many lines of code as I want, if that’s what I’m being judged on, but it’s hard (not impossible, but harder) to manipulate profitability.
Sponsored by CodeRabbit
Teams using CodeRabbit report 50%+ reduction in code review time. It’s not just automated linting—it understands your codebase, learns your team’s patterns, and provides contextual feedback that actually matters.
SOC2 Type II certified. Zero data retention.
Cycles
I was taken to task on LinkedIn for not considering feedback loops in my analysis.
There’s a beautiful phrase in English—don’t teach your grandmother to suck eggs. I’ve been using systems thinking since the 80s (1980s 😉), but I don’t trot it out unless I really need it. I don’t need systems thinking & feedback loops to confidently predict that “Percentage of code generated by an LLM” is a terrible target, guaranteed to incentivize destructive behavior.
The Toolbag
Aside from not assuming that your interlocutor is ignorant, my suggestion for Francisco above is yes to have a big bag of tools but not to reach too deep too soon. If a superficial analysis reveals a flaw, then go with that.
Quick analysis takes less time & effort.
More importantly, linear analysis is easier to explain.
By the time I’ve explained influence diagrams & positive & negative influence & reinforcing & inhibiting feedback loops, I’ve lost most of my audience. If full systems thinking is the simplest way to get my point across, I’ll do it. I’ll invest the time. I’ll risk losing some listeners.
In the case of software development, I don’t need feedback loops to confidently predict the results of measuring & judging lines of code (or PRs or hours worked). The measurement is just too early in the chain of delivering value.
We could spend all day & all night expanding the system to include more aspects of delivering value with software, but we don’t have to.
Definitely harder to measure and attribute! I gave praise last week on two separate stories that took longer than expected. Why? Each produced an artifact that will reduce future effort via re-use and promote higher cohesion.
Kent Beck reminding us why Agile began as a human movement, not a metrics machine.
“Effort → Output → Outcome → Impact” reads like a manifesto in miniature — start simple, measure meaningfully, and don’t mistake motion for progress.