DORA vs. SPACE Metrics: Measuring Engineering Performance Humanely

Lessons from early-stage startups, DevOps research, and the reality that software is built by people, not dashboards

A lot of discussions about engineering metrics start in the wrong place, dashboards, KPIs, and arbitrary goals. Developers cannot be measured, they can barely be understood

We normally start somewhere else:

Can we trust the people we hired?

If the answer is no, there's no metric that's going to help. When the answer is yes, is easier to establish our metrics as a team, so that there's no feeling of surveillance. We never take action based on the signals from metrics alone, they're just clues. Solving the mystery correctly helps leaders identify friction, unblock teams, and improve systems

A fundamentally different mindset

Before DORA. Before SPACE

In an early-stage startup, engineering performance starts long before anyone collects a metric

It starts with:

• Hiring thoughtful people
• Clear expectations
• Good documentation
• Reasonable tooling
• Shared standards
• Psychological safety
• Healthy communication

You can pay for the most expensive desktop eye tracking software, but if onboarding takes three weeks because nobody documented anything, you're wasting money capturing frustrated grunts

If every time the database becomes unavailable requires tribal knowledge from one senior engineer, your problem isn't metrics

If engineers are afraid to admit they're stuck, your problem definitely isn't metrics

The reality is that most engineering bottlenecks are organizational before they are technical

The Trap of Measuring Activity

Many companies still evaluate engineers using activity metrics:

• Number of commits
• Lines of code
• Tickets completed
• Hours online
• Pull requests submitted

These metrics are attractive because they're easy to collect but they don't tell you anything

A senior engineer may spend two weeks understanding a complex system and then solve the problem in 5 minutes. Another engineer may write thousands of lines of code that should never have existed. A production bug might take three days to reproduce and five minutes to fix

The visible activity tells only a small part of the story, software development is creative knowledge work. Anyone who has spent enough time building products knows this intuitively, the breakthrough architecture discussion, the insight that eliminates an entire feature, the careful investigation that prevents a future outage

None of these show up in a commit count

Trauma-Aware Leadership

One topic that rarely appears in engineering or managerial discussions is how stress affects performance. Yet every experienced manager has seen it, and every employee talks about it. When people feel constantly monitored, measured, or judged, their behavior changes towards being defensive

People in survival mode struggle to be creative, experiment and be actually meticulous about the result; instead of thinking of potential side effects from a feature they're distracted with line counts

You don't get better engineering by alienating your team, they just get better at pretend metrics. A trauma-aware leadership approach recognizes that sustainable performance comes from creating environments where people can think clearly, collaborate openly, and ask for help without fear

DORA Metrics: Measuring the Delivery System

The DORA framework remains one of the most useful sets of operational metrics available.

It focuses on four key indicators:

• Deployment Frequency
• Lead Time for Changes
• Change Failure Rate
• Mean Time to Restore (MTTR)

Notice something important.

These metrics measure the system, not individual engineers.

That's one reason DORA has remained valuable.

It asks:

"How effectively does software move from idea to production?"

Instead of:

"Who worked the hardest?"

That's a much healthier question.

SPACE Metrics: Measuring the Human System

The SPACE framework expands the conversation.

It recognizes that engineering performance isn't only about delivery speed.

It includes:

• Satisfaction and Well-Being
• Performance
• Activity
• Communication and Collaboration
• Efficiency and Flow

What makes SPACE powerful is that it acknowledges reality:

Software organizations are social systems.

Communication quality matters.

Focus time matters.

Interruptions matter.

Burnout matters.

The best deployment pipeline in the world cannot compensate for a team that is exhausted, disconnected, or constantly context-switching.

The Metrics I Personally Care About

In early-stage startups, I often care less about individual activity and more about indicators of friction.

Questions like:

How long does a build take?

If engineers spend ten minutes waiting for builds multiple times a day, that's not a minor inconvenience.

That's organizational waste.

How easy is it to deploy?

Can a new engineer deploy confidently?

Or does every release require a ritual and a prayer?

How easy is it to create a staging environment?

Can people test ideas safely?

Can QA reproduce issues?

Can product stakeholders review changes before release?

How quickly can someone become productive?

A great onboarding process often predicts a healthy engineering organization.

How often are people blocked?

This is one of the most underrated metrics in management.

A team can appear busy while spending half its time waiting on approvals, environments, access requests, or unclear requirements.

The question isn't:

"Why aren't people moving faster?"

The question is:

"What's slowing them down?"

The Manager's Job Isn't Measurement

One lesson taught in modern management programs, including leadership approaches, is that managers create leverage primarily through relationships and systems, not through monitoring

A good engineering manager doesn't spend all day staring at dashboards. They spend time understanding context, with conversations, research, updating documentation, identifying patterns

Sometimes that means:

• Writing code
• Pair programming
• Improving documentation
• Purchasing better tools
• Bringing in DevOps support
• Assigning QA resources
• Clarifying priorities
• Reducing meetings
• Protecting focus time

Flow Is the Metric Behind the Metrics

When I look at engineering organizations, I often ask a simple question:

Is the team in flow, or is the team fighting the system?

Teams in flow tend to exhibit similar characteristics:

• Fast feedback loops
• Reliable deployments
• Clear ownership
• Minimal bureaucracy
• Strong documentation
• Healthy collaboration
• Psychological safety
• Reasonable workloads

Interestingly, DORA metrics often improve naturally when these conditions exist. The organization becomes faster because it becomes healthier

Why Startup Context Matters

Lots of engineering advice is written for large enterprises, as they're seen as the consumers of that kind of content and tooling. Many startups accidentally copy those practices, adding unnecessary red tape and overhead to teams that should be delivering new features indiscriminately

You may prioritize:

• Shipping speed
• Learning speed
• Customer feedback
• Product-market fit

Over governance. As companies mature, additional controls become necessary, specially in regulated industries where compliance and cybersecurity are essential

As multiple teams emerge and legacy systems accumulate is important to keep good track of average metrics, available resources and avoid duplicated efforts. The metrics and processes should evolve accordingly

Before any venture funding in particular, in early stages, the codebase might be evolving quickly as business priorities are understood and the infrastructure is put to test; increasing the overheard here will prevent the team from being able to correct adequately

Better Engineering Metrics

Instead of wondering :

"How do we measure our developers?"

Try asking:

"How do we understand the health of our engineering system?"

That's a much more productive conversation, DORA helps us understand software delivery and SPACE helps us understand human performance. Both can be used as diagnostic tools, but are unreliable for specific decisions.

Final Thoughts

The best engineering teams I've seen weren't obsessed with dashboards, they were obsessed with removing friction. Hiring good people, trusting them and investing in their teams

When leaders focus on creating conditions for flow rather than maximizing arbitrary numbers, performance tends to follow naturally