A Framework For Evaluating Application Ownership

The Hidden Costs Of Mature Application Maintenance

Mature applications need to be maintained. They still require security patches, bug fixes, library updates and incident response.​

On a core engineering team, senior employees might spend part of their time on maintenance. Individually, that time might seem small. But add it together, and it’s a different story. For example, say there are five senior engineers who each spend 20% of their work hours on maintaining mature applications. Across the five, that time equals one full-time senior engineer—lost to upkeep. ​

The implications extend beyond monetary cost. The highest cost of misallocated engineering effort is opportunity cost. Senior engineers on core teams usually carry the deepest institutional knowledge (technical, business and organizational). Keeping them focused on maintaining mature applications can hinder a company’s progress. Strategic roadmap items can be delayed because engineers spend time on mature application maintenance. Efforts to modernize can be postponed because engineers spend capacity treating symptoms rather than addressing structural problems. Because senior engineers’ attention becomes fragmented, they have less time to think about architecture and difficult technical problems. Their focus shifts to avoiding issues rather than creating value, which can disengage them and eventually drive them to leave the organization.​

The core engineering team’s accumulated institutional knowledge goes underused, and the company fails to live up to its full potential.

The Three-Part Framework Leaders Can Use To Strategically Allocate Engineering Effort

Engineering and C-suite leaders can use a three-part framework to allocate engineering effort strategically. I developed this framework based on what I’ve seen is necessary for making engineering decisions.

Step 1: Plot Each Application In A 2×2 Quadrant ​

To start, leaders should create a 2×2 quadrant. The X-axis represents the need for core engineering team involvement (low to high). The Y-axis represents the application’s operational friction (low to high). The factors that impact the application’s operational friction are incidents, support burden, technical debt, reliability and security issues, as well as how difficult the application is to test, deploy and change. ​

From there, leaders should plot each application in the appropriate quadrant. There are four quadrant outcomes and corresponding recommendations.

Transition: Low Core Need, Low Friction

The first outcome is low core need, low friction. This indicates that ownership of maintaining that application should transition away from the core engineering team to another internal team or an external provider, while preserving access to the incumbent team for major escalations, architecture and domain questions as needed.

Keep: High Core Need, Low Friction

The second outcome is high core need, low friction. This indicates that the core engineering team should retain ownership of maintaining that application.

Resolve: Low Core Need, High Friction

The third outcome is low core need and high friction. This indicates leaders should decide whether they still need the application. If they do, they should determine whether to modernize it, migrate it or merge it into another application.

Modernize: High Core Need, High Friction

The fourth outcome is high core engineering need and high application friction. This indicates that continued core engineering involvement still creates significant value, but the application needs modernization to reduce the technical and operational friction that is limiting the team’s effectiveness.

Step 2: Evaluate Business Criticality

The next step is to evaluate each application’s business criticality. In other words, what would happen to customers, operations, revenue or other business processes if the application became unavailable or degraded? That assessment determines how cautiously any recommended change should be executed and what commitments and service-level agreements (SLAs) would need to be in place if ownership were transferred. Leaders should also determine whether another internal team or an external partner would be best suited to take over.

Step 3: Assess Transition Economics

Finally, leaders should evaluate whether the value of changing the ownership model of an application justifies the cost, time, risk and organizational effort required to get there. There are some specific questions they should consider: ​

• How much core engineering capacity does the application consume today?

• What will the target ownership model look like?​

• How much effort will it take to transfer knowledge?

• What will the ongoing costs be after the transition?

• How will leaders redeploy the engineering capacity they reclaim? ​

The Role AI Can Play In Allocating Engineering Effort

Leaders can leverage AI to improve the economics of the transition when changing application ownership. ​

AI can enable people to absorb codebases faster, accelerating the transfer of technical knowledge between teams. By documenting architecture, UI/UX standards and code dependencies, it can help the new teams come up to speed faster, work more consistently and reduce the risk of knowledge being concentrated primarily in long-tenured engineers. That doesn’t mean that AI is going to understand everything about the business or the application, so it’s important for the original team to remain accessible to answer questions about business context, architecture and historical knowledge.

Application Ownership Isn’t Fixed

Application ownership does not need to be permanent. Leaders should regularly evaluate each application based on how much core engineering team involvement it needs and the operational friction it creates. Then, they should assess each application’s business criticality to determine how to execute the recommendation (Keep, Modernize, Transition or Resolve), and transition economics to determine whether and when the change makes sense.

Ultimately, by taking these steps and recognizing that application ownership isn’t fixed, leaders can reclaim engineering capacity and redirect it to deliberate, high-value work. ​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?