How do you measure the performance of your finance team?

• Time to close the books?
• Forecast accuracy?
• DSO?
• Working capital turns?

All reasonable.

Now imagine this KPI presented at your next board meeting:

“We evaluated Finance based on the number of journal entries posted this month.”

It sounds absurd.

In fact, you might argue the opposite — fewer journal entries likely indicate:

• Better automation
• Cleaner upstream processes
• Fewer manual corrections
• Stronger internal controls

A high number of journal entries could signal process breakdown, rework, and instability.

Volume does not equal value.

Now Let’s Move to IT Development

Consider a team of developers working inside a legacy environment:

• Decades-old systems
• Undocumented code
• Client-specific customizations
• Fragmented databases
• Manual interventions

Productivity is difficult to measure.

So someone suggests a simple metric:

“Let’s look at lines of code written per month.”

The result: shockingly low.

Conclusion: the developers must be underutilized. Time to start replacing them from the bottom up.

The Problem with Volume Metrics

Measuring developers by lines of code is the technical equivalent of grading accountants by journal entries.

More code is not inherently good.

In many environments, more code means:

• More technical debt
• More fragility
• More customization
• More future defects

In fact, some of the highest-value engineering work produces less code:

• Refactoring
• Removing duplication
• Stabilizing brittle modules
• Root cause elimination
• Documentation
• Standardization

If a developer spends three weeks understanding undocumented logic to prevent recurring failures, their “lines written” may be near zero — yet the risk reduction may be enormous.

Activity vs. Outcomes

The real question is not:

“How much did they produce?”

The question is:

“Did the system become more stable, more scalable, and less fragile?”

In Finance, we measure outcomes:

• Accuracy
• Timeliness
• Cash flow efficiency
• Control integrity

In Technology, the outcome equivalents are:

• Reduced incident frequency
• Lower regression rates
• Shorter onboarding time for new clients
• Fewer manual interventions
• Declining technical debt

Lines of code do not capture any of that.

The Deeper Issue

When organizations cannot easily measure complexity reduction or architectural improvement, they default to simple output metrics.

They measure what is easy — not what matters.

But replacing developers based solely on output volume risks removing the very people who understand the fragile system — without addressing the underlying architectural debt.

If the system itself is broken, swapping personnel does not fix the foundation.

The Financial Analogy Holds

A CFO would never evaluate a finance department based on how many entries they post.

They evaluate:

• Process integrity
• Control environment
• Accuracy
• Efficiency
• Risk mitigation

Technology deserves the same maturity of thinking.

Because in both Finance and IT, the true work is not volume creation.

It is structural stability.