When Software Gets Cheaper, Focus Matters More

AI is changing the economics of software delivery.

Teams can generate more code, open more pull requests, and ship small changes faster than they could a few years ago. Work that once required a roadmap discussion and several weeks of engineering time (fixing a non-critical bug, addressing a small piece of technical debt, automating a repetitive internal task) can increasingly be completed in hours.

Previously, measuring output felt like a reasonable proxy for progress. More features shipped, more tickets closed, and more pull requests merged clearly indicated that a team was moving.

But when output becomes cheaper, those signals become less conclusive.

The important question is no longer only, “How much did engineering deliver?” It is, “What did engineering help the business move forward?”

More output does not automatically mean more value

Many organizations are evaluating AI adoption through output metrics. A team may report that it now produces twice as many pull requests, resolves more tickets, or delivers features at a faster pace.

Those changes may be meaningful. But they are not the same thing as business impact.

A higher volume of pull requests does not tell a leadership team:

- Whether work was directed toward the company’s most important priorities.

- Whether new features solved a real customer or commercial problem.

- Whether reactive work displaced a strategic initiative.

- Whether more software also created more maintenance burden.

- Whether the business noticed a difference at all.

There is a risk in treating activity as the final answer: organizations can become very efficient at producing work that does not materially change the outcome they care about.

The new challenge is focus

AI does not only make it easier to build more. It makes the cost of deciding what not to build more visible.

If a team can address more small requests, refine more edge cases, and ship more features, then prioritization becomes even more important. More capacity can be used to improve customer experience, reduce technical risk, and remove friction from the business.

It can also be absorbed by work that is interesting, urgent-looking, or easy to generate but not strategically important.

That is why the leadership conversation needs to move from output volume toward focus and trade-offs:

- Where is engineering effort going?

- Which strategic priorities are receiving meaningful attention?

- What work was planned, and what work arrived reactively?

- What initiatives actually moved this period?

- What is at risk before a deadline is missed?

These are business questions. Raw engineering data alone rarely answers them.

From engineering activity to strategic execution

Engineering systems are designed to record work.

They contain tickets, pull requests, epics, projects, deployments, reviews, and status changes. That data is essential, but it is fragmented and expressed in the language of execution.

Business leaders think in a different language: investment, priorities, risk, progress, and outcomes.

The missing layer is the connection between the two.

At Kindor, we think about that connection in four layers:

1. Activity: the tickets, pull requests, commits, and deployments that show work is happening.

2. Execution: the progress, delivery movement, planned versus reactive work, and early risk signals behind that activity.

3. Strategic context: the business priorities that projects and epics are intended to serve.

4. Business outcomes: the customer, commercial, financial, or operational result the organization ultimately wants to create.

Most engineering analytics stops at the second layer.

In our recent post, we introduced Portfolio Goals: a configurable strategic layer that sits above day-to-day engineering workflows.

An epic can mean very different things in different organizations. It may be a customer-facing initiative, a technical foundation, a project container, or a collection of related tasks. Trying to force every team to use epics as business objectives would create unnecessary process change and would not reflect how engineering actually works.

Goals solve a different problem.

They let an organization define the priorities that leadership recognizes and connect projects or epics to those priorities inside Kindor. Teams can continue using their project management tools in the way that helps them execute.

Kindor provides the layer that helps leadership understand how that execution relates to strategy.

A more useful view of strategic work

Once Goals and execution are connected, leaders can begin to see a more complete operating picture:

• Strategic coverage: How much effort is associated with an active business priority?

• Progress: Which initiatives moved, and which epics were delivered?

• Trade-offs: How much work was planned, reactive, or still undetermined?

• Risk: Which priorities are affected by stalled, blocked, aging, overdue, or expanding initiatives?

• Unmapped work: What work remains outside a current Goal, and is that intentional?

This is not about forcing every ticket into a strategic category.

This enables a better conversation about where the organization is investing, what it is choosing, and what trade-offs it is making.

Before an organization can understand the outcome of an investment, it needs a credible view of what was invested, what progressed, what changed, and what was at risk.

That is the idea behind the new Executive Dashboards, a Kindor experience built for the questions leadership actually asks.

Rather than presenting another collection of engineering metrics, the Executive Dashboards bring together execution movement, effort allocation, strategic context, planned versus reactive work, and emerging risk in one leadership-ready view.

It is designed to help engineering leaders move from reporting activity to explaining what is happening, what is changing, and where the business may need to make a decision.

---

As AI makes it easier to generate software, the organizations that benefit most will not simply be the ones that ship more.

They will be the ones that can understand where their engineering capacity is creating the most meaningful progress, and make better decisions about what happens next.