The data agreed with them. At first.

What we were told

We were told that one engineer was underperforming.

The concerns came from product and engineering leadership.

The engineer was described as taking too long to deliver, challenging decisions too often, and disrupting the harmony of the team.

The organization was considering removing the engineer from the team.

The evidence seemed straightforward.

From the time work was assigned in GitHub to the time a pull request was opened, this engineer often took longer than we would have expected for the implementation itself.

On that measure, the engineer really was slower.

What we observed

GitHub showed elapsed time.

It did not show what the engineer was doing during that time.

So we followed the work into Slack.

After receiving a request, the engineer would frequently ask why a particular specification existed, what problem it was intended to solve, or whether a different implementation would better achieve the same goal.

These were not random objections.

They were attempts to understand the background of the requirement or to propose an alternative before implementation began.

The product owner generally treated those questions and proposals as unnecessary.

When a proposal was rejected, the engineer began implementation immediately.

When a question or proposal received no response, the engineer did not wait indefinitely.

After three business days, the engineer would state that no response had been received and that implementation would proceed based on the original request.

Only then would the coding work begin.

The pattern

The organization was measuring the entire time between assignment and delivery as engineering execution time.

But a meaningful portion of that time was being spent before implementation.

The engineer was trying to clarify intent, challenge assumptions, or propose an alternative.

Those activities were not being counted as useful work.

They were being interpreted as delay.

That interpretation also shaped the engineer's reputation.

Asking questions looked like resistance.

Proposing alternatives looked like refusing to follow instructions.

Waiting for an unanswered product decision looked like slow implementation.

The same behavior was therefore being used as evidence for multiple negative judgments about the individual.

Then we found another signal

Some of the engineer's rejected or ignored proposals did not disappear.

After the original implementation was released, the product owner would sometimes request the same idea in a later sprint.

The proposal that had previously been treated as unnecessary could later return as an official requirement.

That mattered.

It showed that the engineer's questions and alternative proposals were not merely obstruction.

At least some of them were identifying improvements that the product organization would eventually want anyway.

Our hypothesis

The engineer was not primarily suffering from a capability problem.

The organization had created an environment in which one kind of engineering behavior was rewarded above all others:

Execute the instruction as given.

Questioning the specification created delay.

Suggesting an alternative created friction.

Waiting for clarification increased measured lead time.

From that perspective, an engineer who tried to improve the work before implementing it could appear less productive than an engineer who simply started coding immediately.

The system was not merely measuring delivery speed.

It was indirectly rewarding compliance with instructions.

Why the original diagnosis looked convincing

The original judgment was not based on imaginary data.

The elapsed time really was longer.

That is what made the case interesting.

A single source of evidence supported the organization's conclusion.

If we had stopped at GitHub, we could have reached the same conclusion.

But the metric answered only one question:

How much time passed between assignment and delivery?

It did not answer:

• When did implementation actually begin?
• What happened before implementation?
• Who was waiting for whom?
• What decisions were unresolved?
• What value was being created outside the code itself?

What the evidence showed

The engineer was slower if we measured only elapsed delivery time.

But that number combined several different kinds of activity into one metric.

Once we separated implementation from clarification, proposal, decision, and waiting time, the meaning of the number changed.

The organization had interpreted a system-level interaction pattern as an individual performance problem.

Removing the engineer would not have fixed that pattern.

It would only have removed the person whose behavior made the pattern visible.

The data was not wrong. The interpretation was incomplete.

The Pulsar view

We do not begin by deciding whether an individual is good or bad at their job.

We follow the work.

In this case, GitHub showed that delivery took longer.

Slack showed why.

Later product decisions showed that some of the supposedly unnecessary behavior had been identifying real value.

None of those observations alone told the whole story.

Together, they changed the diagnosis.

We don't evaluate people from a single signal. We investigate the system that produced the signal.