Year-end reviews are in full swing. Revenue performance. Attrition rates. Margin compression. Utilization metrics. The same dashboards that get presented every December.
But here’s what those numbers don’t tell you: whether your organization can actually execute next year’s strategy.
You can hit every target and still be building on a crumbling foundation. The question isn’t just what you delivered. It’s how fragile the system is that delivered it.
Delivery Consistency Matters More Than Delivery Heroics
If your team hit their goals, congratulations. Now ask yourself: what did it cost?
Did you hit dates because your delivery model is repeatable and predictable? Or because a handful of people worked weekends for three months straight while everyone else pretended not to notice?
Heroics are, put simply, a leading indicator of process failure.
Here’s what to actually examine:
How much unplanned work entered the system mid-sprint? If your teams are constantly context-switching to handle “urgent” requests that somehow weren’t visible 2 weeks ago, your planning process is broken. Next year will be worse.
How often did scope change after development started? Not because requirements evolved, but because nobody bothered to clarify them upfront. Every re-scoping event represents wasted engineering capacity and eroded trust.
What’s your ratio of delivery to discovery work? If your teams spent 80% of their time building and 20% understanding what to build, you’re optimizing for output while sacrificing outcomes. That math doesn’t improve by accident.
If you celebrated hitting timelines but can’t explain how you’d replicate the process with different people or different priorities, you got lucky. Luck doesn’t scale.
Architecture Debt Is Strategic Debt
Every CTO talks about technical debt. Almost none of them quantify what it’s actually costing the business.
So let’s get specific:
What revenue opportunities did you pass on because your systems couldn’t support them? Not “we chose not to pursue.” What did you want to do but literally couldn’t because your architecture said no? At that point, your debt has become a revenue problem with a technical root cause.
How many workarounds became permanent fixtures this year? The hacks can be wide-ranging: Manual data exports that were supposed to be temporary, shadow systems built by business units who gave up waiting for IT, or integration scripts maintained by 1 person who’s terrified to go on vacation. Each of these represents a future point of failure and a consistent drag on velocity.
What’s the blast radius when something breaks? If a minor failure in 1 system cascades into downtime across 3 business units, your architecture is too brittle for the pace you’re trying to operate at. Next year’s initiatives will fail for the same reason.
The question isn’t whether you have technical debt. Everyone does! The question is: are you accumulating it faster than you’re paying it down? Because if you are, next year’s roadmap is already compromised.
Talent Distribution Reveals Your Real Bench Strength
Headcount is a vanity metric. What matters is how capability is distributed across your organization.
How many people can actually lead complex initiatives from concept to production? Not “contribute to.” Not “help with.” Lead. Own. Make the hard calls. If that number is under 20% of your engineering org, you have a leverage problem.
Who’s doing the work nobody sees? Every organization has engineers who quietly prevent disasters. They review critical pull requests (and provide real feedback before clicking “merge”). They mentor junior devs in a sustainable way instead of just taking on their work. They spot the architectural landmines before anyone steps on them in refinement and design. If you don’t know who these people are, you’re 1 resignation away from finding out the hard way how important they are.
Are your senior people doing senior work? If your principal engineers are spending more time writing JIRA tickets than setting technical direction, something is broken. While it may seem like humility, in reality it’s misallocated talent that will leave for a role that actually uses their skills. Make sure your business analysts can do this on their own, and that your midlevels and juniors are helping produce great requirements in smaller parts of the stack.
What’s your bus factor for critical systems? If losing 1 person would cripple a core capability, it’s a classic case of organizational fragility. It should be treated like the impending emergency it is.
The companies that scale sustainably don’t just hire more people. They systematically develop capability across the org so they’re not dependent on heroics from the same 5 names.
As an aside, I’m still very much a fan of “bus factor”. But if you want something a bit more PC, another way to ask the question is: “If this person won the lottery, would we still be able to operate?”
Data Quality Is a Proxy for Organizational Discipline
If your business units are still arguing about which report is correct, you have a trust problem masquerading as a data problem.
How many decisions got delayed this year because people couldn’t agree on the numbers? Every one of those delays represents both a direct cost and a cultural erosion. When data isn’t trusted, decision-making reverts to politics and seniority instead of evidence.
What’s your actual data lineage? Not the documentation that exists in theory or in an architect’s mind. Can someone trace a number from the executive dashboard back to the source system and understand every transformation it went through? If the answer is no, you’re making decisions based on numbers you may not actually understand.
How quickly can you detect and resolve data quality issues? If problems surface days or weeks after they occur, your observability is insufficient for the pace at which you’re operating. By the time you notice, the bad data has already influenced decisions.
Clean data isn’t an IT initiative, even if it’s harder to tie to clean ROI than the other stuff you do. Fundamentally, it’s the foundation of organizational agility. Companies that can trust their data move faster, experiment more, and course-correct earlier. Everyone else is flying partially blind and hoping for the best.
The Real Question: Are You More Capable Than You Were Last Year?
Revenue grows. Markets shift. Headcount changes. Those are outcomes and circumstances.
True capability is about executing more reliably, adapting more quickly, and scaling more sustainably than you could 12 months ago.
Can you ship a new feature without 3 teams having emergency meetings about integrations?
Can you onboard a new client without custom engineering work?
Can you respond to market opportunities in weeks rather than quarters?
Can you trust your midlevel engineers to make more decisions independently than they could last year?
If the answer to these questions hasn’t improved, you didn’t get better. Other, non-technical teams executed while you just got busier. Next year’s goals are being set on the assumption that you actually moved the organization forward.
What Gets Measured Gets Fixed
Technology is, frustratingly, almost always viewed as a cost center when it isn’t. It’s not even a strategic asset, in my opinion, since building something new has never been easier. It’s the engine that determines how fast you can move and how much friction you encounter
The companies that will win in 2026 won’t be the ones with the lowest cloud bill or the highest utilization rates. They’ll be the ones who built systems that support speed, teams that execute consistently, and established foundations that don’t crack under pressure.
So before you close out this year, ask yourself: are we reviewing our capability, or just our calendar?
Because one of those determines what happens next year. And it’s not the one most exec teams are measuring.
