Your Best Engineers Aren’t Always Coding (And That’s a Good Thing)
I see it every week: An engineer apologizes for “not getting enough done” because their commits are down. Instead, they spent time mapping user journeys, updating docs, or joining a feedback call. They feel like they wasted time.
This mindset hurts teams. It trains engineers to measure value in lines of code, not in outcomes. Shipping fast feels good—until you ship the wrong thing, or no one can use what you built, or the next team spends a day untangling your code.
Here’s the reality: Building great products means spending time away from the IDE. Product discovery, planning, debugging real user pain—these are where impact happens. Every useful doc, every clear ticket, every hour understanding the user is a multiplier on future work.
In my teams, I treat these activities as first-class work. You join a user interview or clarify a messy spec? That’s progress. You write documentation that unblocks someone next quarter? That’s real output. Some of the best product breakthroughs started with devs asking basic product questions outside a sprint meeting.
You won’t build a high-performing team by pushing everyone to code all day. You get there by helping engineers own the product, not just the codebase. You support them when they solve the right problems—not just code faster.
If you want impact, stop counting commits. Start counting solved problems. Your best engineers already do. Support them in that, and you’ll see the real work get done.