The quiet engineer your metrics are missing.

“Hi Poornima,
I have one engineer who delivers on time, but their pace is slower than the rest of the team. As a result there is less overall output. They don’t cause any drama or friction and cross-functional teams haven’t complained about them, but I’m having a hard time figuring out where they fit and how to help them grow on our team that operates at a very fast pace.”
– Engineering manager, fast-paced team
I want to start by naming two assumptions embedded in this question because they’re exactly the assumptions that hero culture runs on.
Assumption 1: slower pace = less value to the team.
Better question: what is the actual cost of their pace and what’s the cost we’re not measuring?
Assumption 2: the goal is to help them move faster.
Better question: what does the team need that speed alone can’t provide?
Let’s look at what this engineer actually does: delivers on time. No drama. No friction. Zero cross-functional complaints.
On most teams, that combination is rare.
And let’s be precise about what “slower pace” actually means here. This is not an engineer striving for perfection or gating deliverables. They are operating within a timeline and delivering. That distinction matters.
It matters even more in markets where mistakes are costly. In highly regulated industries or embedded systems, where a single bug can block a manufacturing line, people who double-check their work and prioritize quality aren’t obstacles. They’re essential. The “ship fast and break things” approach doesn’t work when breaking things shows up as a higher rate of returns, cancellations, or customer churn. Even SaaS companies who live by the motto will have a hard time admitting it doesn’t cost them in terms of customer service staff who are busy holding customer’s hands and filing bugs. Rework is expensive. It’s just rarely attributed to the speed that caused it.
Pace is easy to see. The cost of speed: the rework, the strained relationships, the rushed specs is much harder to measure.
Speed is visible. Reliability is invisible. Hero culture optimizes for what it can see.
Now on growth.
“How do I help them grow on a fast-paced team” has a buried assumption: that the goal is for them to become faster. But that may not be the right goal at all.
The more useful questions are:
- What do they want to grow toward?
- What work does this team need that actually benefits from their pace and care?
- Where is speed genuinely required, and where has the team just normalized urgency as a default?
Three things to try before drawing conclusions:
1. Audit what their pace is actually costing. Specifically. Not “less output” in aggregate but what work isn’t getting done, and what’s the downstream effect?
2. Ask them what they want to own. Not where they fit: what they want to be responsible for. This kind of engineer may be great at driving initiatives related to quality, stability, reliability, and product integrity, both within your team and in integrations with others. Karen Catlin writes compellingly about this kind of culture-add recognition in her work on being a better ally in the workplace, and goes deeper on exactly this dynamic.
3. Look at your team’s definition of high performance. If it’s primarily speed and output volume, you’ve built a measuring stick that will consistently overlook reliability, communication quality, and cross-functional trust.
Hero culture doesn’t just reward the loudest engineer. It quietly sidelines the steady one: until they leave.
Before you figure out where they fit: make sure you understand what they’re actually worth. Those are two very different questions, and only one of them starts with them.
Often I post a reply to a reader’s question. If you’re in the thick of it, whether that’s feeling stuck, weighing a move, or trying to size up a company from the outside, come along. I write about the climb from engineer to technical leader every issue: getting heard, getting unstuck, and knowing when it’s time to move on. Subscribe to my newsletter here, then hit reply with your own situation. The most universal ones become the next post.