Every quarter, the same ritual plays out. Product asks for a rough estimate on a feature. Engineering leads pull numbers out of thin air. Finance looks at headcount costs and has zero clue how those dollars map to actual output. Everyone nods along, and nothing improves.
I've been in this room at four different companies now. The problem isn't that people are bad at estimation — it's that most engineering organizations have literally no framework for understanding the economic reality of their own work.
The Root Cause: We Measure Activity, Not Economics
Here's where it goes wrong. Most teams track things like velocity (story points per sprint), cycle time, maybe some DORA metrics if they're feeling fancy. These are fine operational signals, but they tell you nothing about cost.
Think about it. You know your team completed 47 story points last sprint. Cool. What did those points cost? Which features consumed the most engineering hours relative to the value they delivered? Where are you hemorrhaging money on maintenance versus investing in growth?
Nobody knows. And the reason is structural.
Engineering work gets bucketed into big, vague categories: "platform," "feature work," "tech debt." Finance sees a department-level burn rate. Product sees a roadmap with dates. But the connection between dollars spent and value delivered? That's a black hole.
Step 1: Start Tracking Time Allocation (Without Making Everyone Miserable)
I know, I know. "Time tracking" makes engineers break out in hives. But I'm not talking about billing-style timesheets. I'm talking about lightweight categorization of where effort actually goes.
The simplest approach I've found that actually works: tag your issues and PRs with allocation categories.
# .github/ISSUE_TEMPLATE/feature.yml
name: Feature Request
description: Propose a new feature
body:
- type: dropdown
id: work-category
attributes:
label: Work Category
options:
- new-feature # net-new product capability
- enhancement # improving existing functionality
- tech-debt # paying down accumulated shortcuts
- incident-response # unplanned fire-fighting
- tooling # internal developer productivity
- compliance # regulatory or security requirements
validations:
required: true
Six categories. That's it. You're not asking anyone to log hours — you're asking them to check a box when they create a ticket. The friction is minimal, and the data you get back is transformative.
After three months of this at my last gig, we discovered that 38% of our engineering effort was going to incident response and tech debt. Leadership thought it was maybe 15%. That single data point changed our entire Q3 roadmap.
Step 2: Build a Cost Model That Connects Effort to Dollars
Once you have allocation data, you can build a basic cost model. Nothing fancy — a script that pulls from your issue tracker and does some math.
import requests
from collections import defaultdict
def calculate_team_economics(team_members, avg_fully_loaded_cost, issues):
"""
Map engineering effort to actual dollar costs by category.
avg_fully_loaded_cost = salary + benefits + equipment + overhead per person/month
"""
category_hours = defaultdict(float)
total_hours = 0
for issue in issues:
category = issue.get("work_category", "uncategorized")
# Use cycle time as a proxy for effort
hours_spent = issue["cycle_time_hours"]
category_hours[category] += hours_spent
total_hours += hours_spent
monthly_budget = team_members * avg_fully_loaded_cost
results = {}
for category, hours in category_hours.items():
proportion = hours / total_hours if total_hours > 0 else 0
results[category] = {
"hours": round(hours, 1),
"percentage": round(proportion * 100, 1),
"estimated_cost": round(monthly_budget * proportion, 2),
}
return results
Is this precise? No. Cycle time isn't the same as focused engineering hours. But it's directionally correct, and directionally correct beats completely blind every single time.
The fully loaded cost is the key number most teams ignore. Your senior engineer doesn't cost $180k — they cost closer to $250-300k when you factor in benefits, equipment, office space, tooling licenses, and management overhead. Use the real number. It's uncomfortable, but that's the point.
Step 3: Make the Invisible Visible With a Team Dashboard
Data in a spreadsheet dies. Data on a dashboard gets talked about. I've had good results with a dead-simple setup: pull your tagged issue data into a lightweight dashboard that the whole team can see.
-- Monthly cost allocation by category
-- Run this against your issue tracker's database or exported data
SELECT
DATE_TRUNC('month', closed_at) AS month,
work_category,
COUNT(*) AS issues_closed,
ROUND(SUM(cycle_time_hours), 1) AS total_hours,
ROUND(
SUM(cycle_time_hours) /
SUM(SUM(cycle_time_hours)) OVER (PARTITION BY DATE_TRUNC('month', closed_at))
* 100, 1
) AS pct_of_effort
FROM issues
WHERE closed_at >= DATE_TRUNC('quarter', CURRENT_DATE)
GROUP BY month, work_category
ORDER BY month DESC, total_hours DESC;
Plug this into Grafana, Metabase, or even a Google Sheet that auto-refreshes. The tool doesn't matter. What matters is that everyone — engineers, product managers, leadership — can see the same reality.
When I set this up for a team of twelve, the first reaction from our VP of Engineering was "wait, we're spending that much on compliance work?" Yes. Yes we were. And now we could have an informed conversation about whether to invest in automation to bring that number down.
Step 4: Use the Data to Have Better Conversations
This is where most teams stop too early. The dashboard isn't the goal — better decision-making is.
Here's what good looks like once you have this data:
- Roadmap planning gets grounded. Instead of "we'll do 6 features next quarter," it becomes "given that 30% of capacity goes to maintenance, we can realistically deliver 4 features."
- Tech debt conversations have teeth. "We're spending $85k/month on incident response" hits different than "we have some tech debt we should address."
- Hiring justifications become concrete. "We need two more engineers" is weak. "Our unplanned work ratio is 40%, which means we're effectively a 6-person feature team despite having 10 engineers" is a business case.
- Tradeoff discussions get honest. When product wants to skip writing tests, you can show them the correlation between the "shortcuts" quarter and the spike in incident-response costs three months later.
The Traps to Avoid
I've also seen this go wrong. A few things to watch out for:
Don't turn it into surveillance. The moment individual engineers feel like their "productivity" is being measured by these numbers, trust evaporates and the data gets gamed. This is team-level and category-level analysis. Period.
Don't over-categorize. I've seen teams with 20+ work categories. Nobody uses them correctly. Six to eight categories max. If you can't explain the taxonomy to a new hire in under two minutes, it's too complex.
Don't treat the model as truth. It's a rough map, not GPS coordinates. When someone says "this says we spent $42,371.28 on tech debt," gently remind them that the precision is illusory. The insight is "roughly 20% of our budget goes to tech debt," not the specific dollar figure.
Don't forget the lag. Engineering investment often pays off months later. A quarter spent on platform work might look "unproductive" in isolation but dramatically accelerates the next quarter. Track over longer windows.
Getting Started This Week
You don't need buy-in from your entire organization to start. Here's what one team can do right now:
- Add work-category labels to your issue tracker (30 minutes)
- Ask the team to start tagging new issues (zero extra meetings)
- After one month, run the numbers in a spreadsheet
- Share the results in your next retro
That first retro conversation, where everyone sees where the time actually goes versus where they assumed it went, is worth more than any productivity tool you could buy. The gap between perception and reality is almost always shocking.
Most engineering organizations aren't inefficient because their engineers are slow. They're inefficient because they're making resource allocation decisions with zero data. Fix the visibility problem first. The efficiency improvements follow naturally once everyone can see the same reality.
