Thanh Pham is the CEO of Saigon Technology, a global software development company.
You just approved another massive engineering budget. Over the last eighteen months, your technical headcount has doubled. The recruitment team hit all their targets, the onboarding sessions were packed, and the payroll reflects a serious investment in top-tier technical talent. Yet, features aren’t shipping any faster to your customers, and the executive team is left wondering what they are actually getting for all that capital.
For years, tech companies treated headcount as the ultimate measure of engineering capacity. Need more output? Hire more people. But software engineering is not an industrial assembly line where adding ten workers yields exactly ten more widgets a day. Adding developers to a sluggish, complicated system doesn’t increase output. It just multiplies the friction.
It is time to stop measuring engineering by the size of the department and start measuring it by how effectively work flows from a rough idea into the customer’s hands.
The Trap Of Managing Inputs
Simply throwing more developers at a delayed project rarely speeds it up. In my experience, it usually slows everything down due to the communication overhead and ramp-up time required, a reality famously known as Brooks’s Law. A team of fifty engineers bogged down by years of technical debt, outdated tooling and bureaucratic approval processes will routinely be outperformed by a nimble team of ten who actually have a clear path to production.
This friction is highly measurable. According to research from Jellyfish, developers routinely waste over 30% of their time on manual, repetitive tasks, administrative overhead and fixing bad code instead of actually building new things.
Therefore, the goal for modern tech leaders should be to clear the path so the talent you already have can actually do their jobs.
Tracking Flow And Velocity
Instead of tracking hours worked, track flow. Flow metrics act as the vital signs of your technical organization, showing exactly where work is getting stuck and where your internal processes are broken.
Cycle Time
The clock starts when a developer commits code and stops when it successfully runs in production. This is your best indicator of operational health.
A bloated cycle time points to hidden friction: code sitting around waiting for a peer review, manual QA bottlenecks or overly complex deployment approvals. Fix the cycle time, and you naturally speed up the team.
Deployment Frequency
Elite teams don’t wait for massive, risky monthly releases. They deploy on demand, multiple times a day. High deployment frequency forces a team to break work into small, manageable chunks and automate their testing. Smaller releases mean easier debugging and a steady stream of value to the user.
Change Lead Time
Change lead time measures the full lifespan of an idea, from the exact moment a product manager or customer requests it to the moment it goes live. It captures the alignment or the dysfunction between your product, design and engineering departments.
Balancing Speed With Stability
You can easily slash cycle times by skipping tests, ignoring security reviews and pushing your engineers to the brink, but you’ll just end up shipping bugs at record speed. Speed means nothing without stability.
The DORA (DevOps Research and Assessment) framework effectively balances this velocity with two critical guardrails to keep the system healthy:
• Change Failure Rate: When you deploy, how often does it break production and require a rollback or a hotfix? If a team is moving fast but constantly crashing the system, they are just generating future rework. According to data published by Al-Kindi, elite engineering teams keep their change failure rate below 7.5%, while average industry performers frequently see failure rates exceed 22%. Speed built on a fragile foundation is an illusion.
• Mean Time to Recovery (MTTR): Complex systems will inevitably fail. MTTR measures exactly how fast the team can restore service when things go wrong. A low MTTR proves the team has strong system observability and automated rollbacks, and understands their own architecture deeply enough to fix it under pressure.
Measuring True Business Impact
An engineering team could have a pristine cycle time and flawless system stability, but if they are building features nobody actually wants, the investment is entirely wasted. Technical output must translate into tangible business outcomes.
This requires a fundamental cultural shift from a “software engineering” mindset to a “product engineering” mindset, where developers deeply understand the business reasons behind the code they write. The downstream effects of making this shift are significant. Research from McKinsey & Company found that implementing effective developer productivity measurements leads to a 20% to 30% reduction in customer-reported product defects and correlates directly with a 20% bump in employee experience scores. When engineers know their work matters, the quality of the work naturally improves.
Feature Adoption And Usage
Code is a liability until a customer uses it. Engineering and product need to share accountability for adoption rates. An elegantly coded, perfectly deployed feature with zero user adoption is a failed project.
Revenue And Retention Alignment
Connect architectural wins directly to the bottom line. Shaving half a second off page-load times demonstrably boosts e-commerce conversion rates. Minimizing downtime directly prevents customer churning. When engineers see this connection, they make sharper technical decisions daily.
Cost To Serve
As your cloud infrastructure scales, efficient code becomes a direct contributor to your gross margins. Teams should be rewarded for optimizing cloud spend, reducing unnecessary compute cycles, and keeping AWS or Azure bills in check. A developer saving the company $50,000 a month through smart architecture is delivering just as much value as a developer shipping a new peripheral feature.
The Bottom Line
Transitioning from a headcount of obsession to an outcome-driven mindset takes work. It requires investing in better tooling to track cycle times, forcing tighter alignment between product managers and engineering leads, and being willing to confront uncomfortable truths about your internal bottlenecks.
But the payoff is immense. An unblocked, highly aligned team of fifty engineers focused on the right metrics will consistently run circles around a disconnected organization of 500.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?