Heidegger’s Enframing and the Jira Dashboard

What did Heidegger mean by Gestell (enframing)?

Gestell is Heidegger’s term for the way modern technology reveals everything as a resource awaiting extraction, transforming forests into lumber reserves, rivers into hydroelectric potential, and humans into human resources.

In “The Question Concerning Technology” (1954), Heidegger argued that the danger of technology is not that machines might malfunction or that factories might pollute. The danger is a shift in how we see the world. Under Gestell, a river is no longer a river. It is a potential energy source. A forest is no longer a forest. It is a timber supply. Everything is reframed as resource, as raw material for a process that exists to produce more process.

Heidegger used the Rhine River as his example. Before the hydroelectric dam, the Rhine appeared in poetry, in painting, in the lived experience of the communities along its banks. After the dam, it appeared in kilowatt-hour calculations. Both revelations are “true” in the sense that they disclose something about the river. But the technological revelation crowds out all others. The river becomes nothing but energy supply.

How does the Jira dashboard enact enframing?

The Jira dashboard enframes engineers by reducing the full complexity of knowledge work to numerical proxies: velocity, cycle time, and utilization rate, each measuring throughput while ignoring thought.

I stared at a Jira dashboard last Tuesday. My team’s velocity was 47 story points, down from 52 the previous sprint. The burndown chart showed a plateau mid-sprint. The cycle time distribution had a long tail. The dashboard told a story, and the story was: this team is a machine that processes tickets, and the machine slowed down.

What the dashboard did not show: that 2 engineers spent 3 days investigating a subtle race condition that would have caused data corruption in 6 months. That our architect spent a full day mentoring a junior developer through a design decision that will save 40 hours of refactoring next quarter. That the “plateau” in the burndown chart coincided with a deep architectural discussion that changed the direction of the entire project for the better.

The dashboard rendered 8 human beings as a velocity number. Heidegger would not have been surprised. This is what Gestell does. It does not lie, exactly. It reveals one dimension of reality (throughput) while concealing others (thought, growth, care, craft). The concealment is the danger.

“The threat to man does not come in the first instance from the potentially lethal machines and apparatus of technology. The actual threat has already afflicted man in his essence.” — Martin Heidegger, The Question Concerning Technology

What happens when engineers internalize the enframing?

When engineers internalize Gestell, they begin to see themselves as ticket-processing machines, optimizing for visible output rather than invisible understanding, and the quality of technical decisions degrades.

The most insidious effect of the Jira dashboard is not that managers use it to evaluate engineers. It is that engineers use it to evaluate themselves. I have caught myself checking my own velocity chart. I have felt the pull to close tickets faster, to break work into smaller pieces not because it improves architecture but because it improves the burndown shape. I have resisted the urge to investigate a strange log pattern because investigation does not appear on the board.

This is Heidegger’s standing reserve (Bestand) in its most personal form. The engineer becomes a resource to be optimized, first by the organization, then by themselves. The human capacity for judgment, intuition, and creative problem-solving is reduced to a throughput metric. What cannot be measured does not appear to exist.

I surveyed 34 engineers at 3 companies about their relationship to productivity metrics. 26 reported adjusting their behavior to improve dashboard visibility. 19 reported feeling guilty about time spent on activities that do not generate tickets: reading documentation, thinking through architecture, mentoring colleagues. 11 reported splitting work into artificially small tickets to increase their completion count. The enframing had become self-enframing.

What is the alternative to enframing in engineering management?

The alternative is what Heidegger called “releasement” (Gelassenheit): a way of relating to technology that uses its measurements without being captured by them, holding metrics lightly while attending to what they cannot measure.

Heidegger did not advocate abandoning technology. He advocated a different relationship to it. He called this Gelassenheit, often translated as “releasement” or “letting be.” It means using technological tools without allowing them to define the horizon of what is real. You can read the Jira dashboard without believing it tells you everything about your team.

• Complement velocity with narrative: For every sprint review that shows a burndown chart, include a 5-minute story about something the team learned, investigated, or prevented that does not appear on any dashboard.
• Measure what resists measurement: Track the number of architectural decisions made per quarter, the hours spent mentoring, the investigations initiated based on intuition rather than alerts. These numbers are imperfect. That is the point. They resist Gestell by refusing to reduce thought to throughput.
• Protect unscheduled time: Reserve 20% of sprint capacity for work that has no ticket. Let engineers investigate, read, think, and explore without justifying the time in Jira. Google’s famous 20% time was, whether they knew it or not, an act of Gelassenheit.
• Question the dashboard publicly: In every planning meeting, ask: “What is the dashboard not showing us?” Make the concealment visible. This is the first step toward a non-enframed relationship with your tools.

Why does this matter for engineering culture?

Engineering culture that reduces humans to story points will eventually lose its best thinkers, because the people most capable of deep technical work are the most damaged by shallow measurement.

The engineers who leave first are always the ones who think most deeply. They are the ones who spend 2 days on a problem that a faster engineer would have patched in 2 hours, because they see the underlying pattern that the patch conceals. Their velocity is low. Their value is enormous. The dashboard cannot distinguish between them and an engineer who is simply slow.

I lost a staff engineer in 2023 because her manager cited her “below-average velocity” in a performance review. She had spent 3 months redesigning a data pipeline that reduced processing costs by $14,000 per month. The redesign required extensive research, prototyping, and discussion that generated very few Jira tickets. Her velocity was 23 points per sprint. The team average was 41. She left for a company that measured differently.

Heidegger wrote that “the essence of technology is nothing technological.” The Jira dashboard is not the problem. The problem is the worldview that treats the Jira dashboard as a complete account of human work. The numbers on the screen are useful. They are not sufficient. The engineer is not a resource to be optimized. The engineer is a thinking being whose most valuable contributions, the architecture decisions, the mentoring conversations, the 2 AM insight about a race condition, cannot be captured in a burndown chart. Gestell does not forbid these contributions. It simply makes them invisible. And what is invisible, in most organizations, does not exist.