Leadership
Movement vs. Momentum: Misreading Performance
Jan 15, 2026
Most performance problems aren’t caused by a lack of effort. They’re caused by miscalibration.
People measure themselves honestly against the wrong reference frame.
The result looks productive—activity, visibility, engagement—but beneath the surface, progress stalls. Friction rises. Delivery slows.
This isn’t a motivation problem. It’s a systems problem.
I was reminded of this during an end-of-year review with an engineer we’ll call “Alex.”
Alex had joined the company about a year earlier as an intermediate-level engineer, having come from a smaller regional shop where he’d been operating at a senior level. He’d only been on my team for a few months. On paper, the transition looked reasonable. In practice, it was rocky.
Rework rates were high. Pull requests stalled delivery. Code reviews expanded into philosophical debates that generated friction without forward progress.
When we opened his first full-cycle review, we used Engineering Ladders—a rubric that breaks growth into dimensions like Technology, Systems, and Influence. I asked Alex to self-assess against the next level up.
He scanned the criteria for about 90 seconds.
“Proactively supports team members.” “Designs scalable features.” “Challenges process.”
He looked up, confident.
“I’m there,” he said. “All green.”
We were looking at the same words—and seeing two completely different realities.
Alex saw high ticket counts and constant Slack activity as evidence of senior-level impact. I saw friction, delays, and measurable drag on team velocity.
This wasn’t arrogance or bad intent. It was a classic calibration failure—accurate self-assessment applied to the wrong game.
As Richard Feynman put it, “The first principle is that you must not fool yourself—and you are the easiest person to fool.” Alex wasn’t fooling anyone on purpose. He genuinely believed he was playing well.
Clay Courts vs. Grass Courts
To explain the gap, I reached for a sports metaphor.
Alex had learned to play tennis on clay.
In his previous role, the game was slower. Rallies were long. You had time to set up shots, debate angles, and grind opponents down. He’d mastered that surface. He was a Senior there.
But our environment runs on grass.
The ball stays low. Points end quickly. Precision and timing matter more than endurance. The same long, looping swings that worked on clay—extended architectural debates, prolonged back-and-forth in reviews—became liabilities.
Alex was working hard. Very hard. But he wasn’t winning points. He was exhausting himself—and the team around him.
Same effort. Different surface. Different results.
This wasn’t about speed versus care. It was about what the system rewarded.
Visibility Isn’t Influence
There’s a behavior pattern I’ve seen across industries. We had a term for it in the military, but it shows up everywhere: spotlighting.
It describes the person who performs loudly when someone important is watching—motivated, vocal, visibly busy—but fades when the real, unglamorous work needs to happen quietly.
In distributed engineering teams, spotlighting shows up as:
The Slack Philosopher: Forty-five minutes of live debate about schema purity while the build is red.
The Ticket Farmer: Closing ten trivial tickets to juice metrics while avoiding the one complex problem that actually matters.
The PR Nitpicker: Dozens of style comments while missing the race condition that ships to production.
This isn’t about extroversion versus introversion. It’s not about quiet engineers being better engineers. It’s about signal-to-noise under delivery pressure.
Alex equated visibility with influence. To him, being loud felt like leadership. To the senior engineers on the team, it felt like friction.
The question was: how do you help someone see that gap without crushing their confidence?
Movement vs. Momentum
That distinction became the heart of our coaching conversation.
Movement is energy expenditure. Typing, talking, meeting. It feels productive.
Momentum is progress with mass behind it. It moves the work forward with less friction.
Alex had high movement and low momentum. He added energy, not progress.
A concrete example: Alex would leave fifteen comments on a pull request about naming conventions and formatting—then, days later, realize the feature mishandled edge cases. The comments were movement: visible, fast, low-risk. Catching the logic flaw before the merge would have been momentum.
Telling him to “focus on impact” wasn’t enough. We needed to change the system so impact became the default filter.
The Impact Filter
Instead of policing behavior, we clarified the rules of the game.
We published a simple framework to the team wiki and started using it explicitly in reviews and discussions:
Does this proposal:
Prevent a bug that would otherwise ship?
Unblock or accelerate delivery?
Reduce deployment or operational risk?
Materially simplify the code for future maintainers?
If yes, raise it immediately with the delivery owner.
If no, document it for intentional future consideration—during sprint planning, tech-debt cycles, or design reviews. Not in the middle of active delivery, where it will derail work in progress.
This wasn’t about devaluing quality. It was about deciding when quality conversations compound momentum—and when they quietly tax it.
The effect was noticeable within weeks. Lengthy Slack debates about preference were interrupted with a shared question: “Does this hit one of the four?”
When the answer was no, the discussion moved to a doc. The team got back to work. Momentum returned.
Calibration Is a Leadership Responsibility
Alex didn’t get promoted that cycle. But something more important happened: he understood why.
He stopped trying to win arguments and started trying to win time for the team. He began writing proposals instead of relitigating them live. His pull requests got smaller. Review cycles shortened. Delivery smoothed out.
He didn’t stop caring. He recalibrated.
Calibration isn’t a one-time correction; it’s a continuous leadership obligation as surfaces and constraints change.
Self-assessment without external calibration is dangerous—especially for capable, motivated people. Left unchecked, it rewards visibility over impact and movement over momentum.
Great engineering leaders don’t just evaluate code or people. They evaluate team physics. Where is drag coming from? What behaviors convert effort into progress? Who is multiplying momentum—and who is just loud?
Key Takeaway
If you have an engineer who thinks they’re performing at a 10 while delivering at a 6, don’t argue about the rating.
Argue about the game they’re playing.
Make the surface visible. Define what momentum looks like. Calibrate activity against impact.
Because progress isn’t about how much energy you expend—it’s about how much work actually moves forward.
