# You don’t manage what you don’t understand

Why engineering performance is harder to measure than other business functions.

![](https://framerusercontent.com/images/NkiThIEDcY7u0hU9E3jSSObfmhw.png?width=400&height=400)

Dave Garcia

Founder and Co-CEO

Apr 9, 2026

![](https://i.ytimg.com/vi_webp/HU_2MVuvF48/sddefault.webp)

## Engineering has always been different

One of the most consistent patterns I have seen across companies is that leadership understands most functions reasonably well, except one: Engineering.

My co-founder Bernardo Hernández, has extensively written about it. Even though being one of the most successful executives and enterpreneurs, he always struggled with engineering.

Sales has ARR, marketing has pipeline, campaigns, and attribution… Engineering, on the other hand, operates in a much more opaque way.

The work is complex, highly technical, and distributed across many different systems. The signals are fragmented and difficult to interpret. And as a result, most organizations end up managing engineering through abstraction.

Myself, as a several times Engineering leader had to spend hours reviewing the work from the team to truly understand what was going on.

## The comfort of proxies

To deal with that complexity, engineering teams introduced proxies.

Story points, tickets closed, velocity, cycle time. These became the language through which engineering performance was discussed. They created a sense of control and allowed teams to communicate progress in a standardized way.

And to be fair, they helped answer operational questions such as:

- Are we shipping more?
- Are we moving faster?
- Are we closing work?

But engineering is not an operational function. It’s a value creation function and those metrics gave the illusion of understanding without actually proving it.

Because when you ask the questions that matter at a leadership level, those metrics rarely provide clear answers:

- Did delivery actually improve over time?
- Did quality get better or worse?
- Are we creating more rework?
- Is the work aligned with what’s on roadmap?
- Is the team generating real impact or just more output?
- Are we executing well as a team?

These are the questions that determine whether a technology organization is healthy. And they are surprisingly difficult to answer.

## The illusion of understanding

The problem is that operational metrics create a version of reality that feels complete when it isn’t. You see tickets moving, pull requests merged, velocity trending up, and it looks like progress.

It feels like you understand what is happening inside the team, instead you are looking at disconnected signals and trying to infer a system from them. You don’t see how work actually connects, where execution slows down, or which changes are moving the product forward versus introducing more complexity that will have to be dealt with later.

This gap becomes much more visible with AI. Activity increases across the board. More code is written, more changes are pushed, more apparent progress is made. But the underlying question becomes harder, not easier. *You can not make a 360º review about Claude.*

And yet that is what most organizations are trying to do. They are trying to understand engineering performance by stitching together fragmented signals coming from different tools, each one showing a small part of the picture. The result is a more sophisticated form of guessing.

## From activity to impact

This is the shift that is happening: Moving from measuring activity to understanding impact. From counting outputs to evaluating what those outputs produce. From relying on proxies to seeing execution as it actually is.

This is what we built Pensero to solve. It connects to all the tools where work happens and reconstructs how execution unfolds, turning fragmented signals into a coherent view of delivery. It allows you to see what is being delivered, how complex that work is, where things break, and whether performance is improving over time.

Including AI, of course. Not as a usage metric, but as a performance question. Whether it is actually making teams better or simply increasing the volume of work. We all need to understand what value are we getting from our investments.

Because once code is no longer the constraint, the only thing that matters is whether you are turning that into real progress. And that is something you cannot manage without truly understanding it.