Plato accidentally predicted Jira dashboards.
Or at least, it feels that way sometimes.
In Plato’s Allegory of the Cave, prisoners sit facing a wall. Behind them, unseen objects pass in front of a fire, casting shadows. The prisoners cannot see the objects themselves, only the shadows.
So the shadows become reality.
Engineering metrics work a lot like that. You can see versions of this dynamic in almost every engineering organization.
The real work of engineering happens in places that are difficult to observe, such as:
- an insight about how a system should be structured
- a careful debugging session that prevents a future outage
- helping another developer unblock a deployment
- recognizing that a design will fail before it is written
None of that shows up directly in a dashboard.
What dashboards see instead are shadows:
- Jira tickets closed
- pull requests merged
- cycle time
- lines of code
- commit counts
Those things are not the work. They are artifacts the work leaves behind.
Organizations understandably want to measure something. If you are responsible for hundreds of engineers, you need signals about what is happening inside the system.
So tools appear. Velocity dashboards, commit analytics, engineering productivity reports. Each one promises to illuminate what engineers are doing.
But they are still watching shadows.
I once had a manager tell me I was not starting my sprint work at the beginning of the sprint.
This was surprising news to me, because I was fairly certain I was.
Unless we were handling an incident, which was rare, I usually started my sprint tickets as soon as the sprint began. That was simply how I worked. But the feedback kept coming back.
“You need to start your work earlier in the sprint.”
I kept asking what they meant.
“What do you mean? If I have a ticket, I start my work.”
Eventually I asked where this impression was coming from.
It turned out the answer was Jira. More specifically, a swim lane.
I had a habit of forgetting to move tickets into “In Progress” until a few days after I had already started working on them. So according to the dashboard, or whatever metric they were using for when tickets were started, I was not beginning work until the middle of the sprint.
In reality, the work had started days earlier.
Now there will be people reading this thinking that obviously the ticket should be moved to “In Progress.” And sure, if that is your team’s process, that makes sense.
But that was not the thing we were trying to optimize. What mattered was whether the work shipped and whether it shipped on time. For years, if the “In Progress” ticket state was set a few days into the sprint, nobody batted an eyelid. I’d never thought that hard about it.
I am not entirely sure what they thought I was doing during those first few days. Possibly sitting quietly at my desk contemplating the ticket like a monk contemplating a candle.
The funny thing is that once you understand the metric, the system becomes very easy to satisfy. If someone actually wanted to sit on their hands for a few days, the first step would be to move the ticket to “In Progress.” The dashboard would be perfectly happy. You were, after all, working on your tickets according to it.
Economists have a name for this: Goodhart’s Law. When a measure becomes a target, it stops being a good measure.
If lines of code become a signal of productivity, codebases mysteriously grow larger.
If ticket throughput becomes important, tickets get sliced thinner than deli ham.
If sprint completion becomes the goal, engineers quietly avoid risky work.
Nobody has to cheat. Systems naturally evolve toward whatever signals are rewarded.
Engineers are especially good at recognizing this dynamic. After all, we spend our careers designing systems and watching how people interact with them.
Give engineers a metric and they will quickly figure out how the metric behaves.
That is system literacy.
Organizations introduce measurement systems to understand engineering work. Engineers adapt to those measurement systems. Soon the organization is measuring behavior shaped by the metric rather than the work itself.
Before long, the cave wall fills with very impressive shadows.
Meanwhile the real work remains largely invisible. The thinking, the architecture, the mentoring, the quiet prevention of disasters.
I sometimes think of this as the difference between superheroes and bomb sniffers. Superheroes get credit for dramatic rescues after the explosion. Bomb sniffers get credit for nothing at all, because the explosion never happens.
In engineering, the bomb sniffers are often the most valuable people on the team.
They are the ones who notice the memory leak before production falls over.
They spot the endpoint that is accepting far too many calls.
They see the design flaw before it becomes a months-long migration.
Most of that work never appears in the usual metrics. It is not measured in commits or lines of code or tickets closed. It shows up as something much less visible: problems that never happened.
This does not mean metrics are useless. They can reveal patterns. Work getting stuck in review. Teams drowning in interruptions. Deployments slowing down.
Used carefully, dashboards are signals. But they are not the terrain. They are reflections of it.
Healthy engineering cultures remember this. They treat dashboards as hints, not verdicts. Because once you mistake the shadows for reality, you start optimizing the shadows. And that is how you end up with beautiful metrics while the actual system quietly drifts toward chaos.
Plato would probably recognize the problem immediately.
He might just be confused about why the shadows are called “velocity.”