Your Metrics Only Tell Half the Story
A while back, I worked with an engineer who was one of the sharpest people on the team.
He had a real instinct for performance. He would spend days hunting down latency problems, squeezing milliseconds out of API calls, and optimizing endpoints that were already fast. That kind of focus is genuinely valuable.
The problem was that nobody else in the building could connect it to anything they cared about.
He would walk into a planning meeting and share something like "I got that endpoint down another 80ms," and the room would nod and move on. Not because the work was bad. Because nobody could trace it to a metric they were tracking.
The work was real. The impact just wasn't visible in the language other people were using.
Three Layers, Three Different Questions
Most technical work generates data at one layer. But there are three that matter in a cross-functional environment.
Technical metrics measure system behavior. Latency, error rates, uptime, and deployment frequency. These tell you whether the software is working as designed.
Product metrics measure user behavior. Activation, retention, feature adoption, and task completion. These tell you whether the software is doing something useful for the people using it.
Business metrics measure outcomes. Data such as revenue, churn, infrastructure costs, and customer acquisition. These tell you whether the work is producing results that the organization can sustain.
Each layer is legitimate. None of them is more important in the abstract. But they answer different questions, and they are usually owned by different people. When you only show up with one, the people tracking the other two don't have much to work with.
This is part of the same pattern I wrote about in Understanding ALL the Systems You Work With. The technical system is only one of the systems you operate inside.
Where Metric Gaps Cause Friction
Teams can each be doing reasonable work and still have outcomes that don't add up.
Engineering hits uptime targets. Product tracks engagement. Finance watches the margin. Nobody is lying about their numbers. But nobody owns the space between them either.
That is where the friction actually lives. Not in disagreements about priorities. In disconnected scorecards.
My former coworker wasn't doing anything wrong. He was doing exactly what he was trained to do: find inefficiencies, fix them, measure the improvement. The gap was that his metrics didn't connect to anything anyone else could act on.
If he'd put a bit of time into connecting the dots and presented it differently, the conversation would have changed entirely. Something like: "We optimized the most widely used API on the platform by 47%, which translates to roughly $1,500 a month in infrastructure savings."
Same technical work. Same level of rigor. Very different outcome in the room.
The product team can hear that. Finance can hear it. It earns attention because it connects to something people are already tracking.
|
|
Where can AI save you time?
My friends at Big Creek Growth put together a quick survey to spot the repetitive work you can hand off to automation.
|
|
How to Make the Connection to What Matters
You don't need to become a business analyst. You need one habit: before you bring a technical metric into a cross-functional room, think about what it connects to one layer up.
You don't need a definitive answer. You need enough to give someone a foothold.
A few ways to start building that habit:
- Identify your most-used surfaces. The highest-traffic endpoints, the most-clicked flows, and the features with the most active users. Optimizations in critical systems have a much clearer path to product and business impact than work on rarely used functionality.
- Frame improvements in terms of what changes downstream. Faster response times might mean lower abandonment. Fewer errors might mean fewer support tickets. Reduced computing might mean lower cost. You don't always have to prove the link. You do have to name it.
- Come with a hypothesis, not just a number. "We reduced error rate on the checkout flow by 30%. We think that's contributing to the drop in abandonment we've seen over the same period. We're watching it." That's enough. It shows you understand your metric doesn't stand alone.
The engineers and new leaders who earn credibility in cross-functional settings aren't usually the ones with the most data. They're the ones who can narrate across layers.
Write it Once covers a related skill: turning decisions and updates into something others can actually use. The same principle applies here. Metrics that aren't legible to the people around you don't travel far.
When you can connect your layer to the one above it, a few things shift.
People start leaning in instead of nodding politely. Conversations about tradeoffs get more specific. You stop feeling like you're reporting to a room full of people who don't understand what you do, because you've met them halfway.
My former coworker was doing technically excellent work. But the room couldn't see why it mattered. That's not a communication problem in the soft-skills sense. It's a translation problem. He was speaking one layer, and the room was listening for another.
Metrics aren't just a scoreboard for your own work. They're a shared language. Learning to speak across layers is part of becoming more useful, not just more productive.