Bottom Line Up Front (BLUF)
A small team of engineers can now build more software than it has the capacity to reliably maintain. The time it takes to hit the maintenance ceiling has dropped dramatically with how fast code can be generated. The cheapest response is to build less and / or eliminate bloat, but will ultimately require us to implement at least one intentional maintenance model to operate the system.
The Maintenance Ceiling
Every software release adds a small, permanent maintenance requirement to the system (e.g., models, prompts, integrations, permissions), but builder capacity doesn’t grow at the same pace. None of these maintenance obligations are inherently capacity sinks. Eventually though, maintaining previously built apps can consume most of the team’s current capacity, and I refer to this limit as the maintenance ceiling.
The following roles are pretty self explanatory, but best to make sure we are on the same page up front.
The builder - the team or engineer mainly accountable for creating / building the thing
The operator - the team or engineer mainly accountable for ongoing maintenance work, enhancements, etc.
To avoid hitting the maintenance ceiling, builders and operators can’t add additional handoffs. Domain and / or product teams still need to own the outcomes their systems produce.
What happens after deployment?
In the previous issue, I proposed that FDE is a new title for an implementation consultant / specialist, etc. Implementation starts with a P&L and business process. Then, the process follows the general flow of the below diagram to move something from idea into production. But, the process below doesn’t answer who keeps the system both running and current after go-live. Go-live does not transfer a capability by itself, someone must still explain, test, change, recover, and eventually retire the system, and it’s best to know that person / team up front.
More importantly, what happens when the implementation team / partner / developer leaves?
History Repeats: The Previous Automation Ceiling
Back in 2017/2018 I watched an automation program reach the maintenance ceiling inside a regulated environment. The automation teams were genuinely strong, staffed correctly, and the work was genuinely well done. Even more rare, our governance program was largely a value exporter. The COE team provided infra, office hours, peer collaboration, and some shared operational support.
Note: While the rest of this article is mainly focused on automation, the following stories and logic can also apply to feature delivery and capability augmentation as well.
As time went on and the volume of automations grew, each additional solution created some additional operational need. None were individually huge, but collectively, it started to add up. Source applications changed, new exceptions surfaced, new edge cases were identified, and business processes were reworked as the industry changed. Each time something changed, the solutions needed rework.
For some automations like those that didn’t have API capabilities (I know it sounds crazy today, but it’s absolutely still relevant in banking), the technology was brittle. Changes to vendor or internal application user interfaces required routine maintenance, which was often unscheduled. Being at the mercy of upstream applications changing required agile pivots to ensure business continuity of the automations.
Eventually, we floated the idea of staffing and hiring a specific / dedicated operations role. We needed capacity for new work, and it had to come from somewhere. The idea was to hire or find a more junior engineer / resource who would be reskilled on the capabilities while learning the tools to execute full projects. Admittedly, that talent funnel and the training path were never easy to build.
At the same time, that role is also somewhat antithetical to DevOps in principle. I firmly believe you should own the solutions you build, because ownership is what incentivizes you to build them correctly. But the capacity had to come from somewhere, and a lot of the tooling for that automation wave was less mature than traditional software engineering, especially of today.
Therein lies the dilemma; builders should keep and own the capability, but eventually they run out of capacity and can’t.
At our org, we landed on a hub-and-spoke model. We worked really hard to enable folks with domain expertise to self organize, judge what work should be done, and execute it as they saw fit (obviously within certain guardrails).
Now, you may be wondering, “how do we solve the same issue when we have more citizen development”? Which, at present is especially urgent in middle-market organizations and orgs without large / dedicated IT departments.
Back to the Present: AI Accelerates the Problem
As mentioned above, code generation is becoming more expedient. At the cost of a few thousand dollars in tokens, someone can ship a working prototype of an application out the door to users for feedback in days to weeks. Even non-software engineers are building and managing AI applications (whether these be vibe-coded or built with purpose / agentic engineering).
In the past builders were trained alongside a support network or a team, typically with some apprenticeship and systems in place for getting safe reps. COEs and Engineering Guilds also provided office hours, peer collaboration, and shared operational support. Because code is quicker and easier to generate, a lot of code is written by non-engineers without those support systems in place.
Consequently, I have spoken to many leadership teams who experimented and built software internally in the past 2 years. Early on, custom built AI software was cheaper and more purpose built than off the shelf SaaS (particularly at the application layer). Now leaders are struggling with non engineers maintaining the applications they built:
Sales folks adding features to a custom CRM they built instead of selling
Marketing resolving bugs overnight for a campaign in the morning
Finance manually reconciling data between manual processes and the newly built applications before month-end
None of that work is on any of these folks’ original job description; they built tools out of excitement (or pressure from leadership), but the long tail of maintenance comes after. Every hour these teams spend on maintenance typically can be better spent performing their core job function. When they hit that limit, they hit the maintenance ceiling. Now, business folks are experiencing something previously felt most acutely by engineering teams.
This is especially critical for organizations without large tech / IT departments. These orgs may have strong operating owners and lean technical teams. At their current scale and operational complexity, they do not need (nor can they afford) permanent specialists for every dependency. BUT, they still need a maintenance model, including the right discipline (people / process) and technology to support it. But, how do we decide which model and who ultimately should make that decision?
What Does the Research Say?
Caveat Up Front: I have not yet found a study that measures the maintenance ceiling in a meaningful way (though if you have one to share, I would be grateful). The diagram below shows how I mentally think about it, and should be read directionally. However, I would argue that the following studies support the concept.
Google SRE writes that toil is “the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows” (Google SRE). From their documentation, they prescribe keeping the operational work below 50% of each SRE’s time. Furthermore, if left unchecked, they state that toil can quickly fill 100% of everyone’s time. As we will discuss in the Productize Shared Operations section below, being intentional about working ON the platform can help mitigate the risk that any team will become solely focused on Ops.
A 2019 study worked with 43 developers and estimated that tech debt consumed ~23% of the engineers’ working hours (Besker, Martini, and Bosch). My SWE friends will be quick to point out that technical debt is NOT the same as total application / platform maintenance. Maintaining existing systems can steal meaningful development capacity for feature delivery or platform improvement.
The current AI evidence makes the who / what / how of the supporting system urgent. DORA’s 2025 research compiled survey responses from nearly 5,000 tech professionals, and 90% reported using AI at work. I suspect this is higher for SWEs today. In that study, DORA observed a positive relationship between AI adoption and delivery throughput but negative relationship between AI adoption and delivery stability (DORA, 2025). They label this broader pattern “downstream disorder” (i.e., the work downstream of the code). Velocity gains from writing code agentically can be quickly absorbed by additional required testing, security, and/or deployment bottlenecks. DORA guidance treats the platform as a required internal product, NOT an infra queue (more on that topic in the Productize Shared Operations section below).
Shipping code faster does not create the downstream capacity required to maintain the app(s).
Be Selective on What to Ship
A cheaper lever worth considering before choosing any maintenance and support model is elimination. As process improvement specialists will recognize immediately before building automation, the target process should be known, understood, optimized / eliminated, and only then automated (this has deep roots in Lean Process Improvement).
Known - the process is identified and documented / articulated as it actually works. This is actually more often NOT exactly as the spec / procedure describes it. Documentation has a nasty habit of going stale the moment it’s written.
Understood - we can articulate and describe the outcome, benefit, or requirement for the process to exist.
Optimization - improve the process. This is fairly broad, but could be as easy as facilitating a conversation between two employees, rearchitecting the process around new capabilities, or making existing capabilities run more smoothly. In some cases, the best process optimization would be to eliminate the process entirely. Note: typically, this isn’t a FULL enterprise workflow, but some subprocess in a decomposed workflow can be axed.
Elimination » automation. Elimination can be the most efficient and cheapest way to improve a process.
In process improvement (PI), skipping one or more steps in the PI sequence used to be painful down the road. Automating an unmapped or undocumented process took months of upfront process conversations, business interviews, and multiple build and test cycles. Then, requirements were firmed along the way but one or two inevitably always landed during testing. Now, AI makes navigating through the PI sequence faster, which is a double edged sword.
Pro: On one hand, process discovery can now move much faster. Source systems can be reviewed quickly (e.g., mining traces, logs, etc.), which can help alleviate the pain of manually mapping each system connection. But this still doesn’t completely eliminate discovery and trust-building in interviews.
Con: On the other hand, because building and testing is now much faster, delivery teams are incentivized to accelerate the discovery and jump quickly to build and test cycles. Unfortunately, the skipped steps still exist, but they now pop up as missed edge cases, a change requiring maintenance, or less trust for the business team or customer benefiting from the work.
I’m not saying we have to be fully dogmatic every time with the PI process, especially in the case of experimentation and prototyping. Prototyping and A/B testing is one important way to achieve shared consensus on what should be built and what the lift would look like. However, we do need to ensure that the experiment is cost controlled and time bound. We also should ensure that the experiment lifecycle is roughly determined before we hit go.
One risk that’s even more relevant today is that the experiment unintentionally becomes a permanent feature. This experiment —> feature risk has always been a challenge of software development, but the speed at which we can create MVPs makes the risk more likely.
Relevance to Feature Delivery
We have been more focused on discussing software automation, but this also applies for product features delivery too. For feature development, core product management is almost more critical now than ever. Deciding what’s above the line in the build queue / backlog avoids customer feature fatigue, and potentially maintaining features that long term detract from your ability to ship more impactful ones. I’m not an expert product manager, but I would argue that the following questions are still extremely relevant:
Juice Worth the Squeeze: Does your market research suggest that your customers would actually pay for this feature?
Buy vs. Build: Are you building something that you could buy for cheaper? Does the feature you are planning to ship align with your intentional product vision / competitive advantage, or are you building away from the core product?
Potential Maintenance Choices
Eliminating process steps or killing non-essential features helps reduce the speed at which teams reach the maintenance ceiling, but the ceiling doesn’t go away. After removing these features / process steps, we likely have a better window to actively prepare for and manage the maintenance overhead.
Below are a few potential models for managing the maintenance / operations of these apps / services. Selecting one or several will depend heavily on an organization’s implementation model (e.g., internally developed or built by third party), business complexity, shape, maturity, etc. These aren’t mutually exclusive, especially for larger organizations, but there are advantages to adopting a consistent model.
Maintenance Models:
Delegated Build, Operations Ownership: After a building team completes the work, the operating team will manage and can independently change / update the application without depending on the initial delivery (builder) team. In this case, the builders could be internal engineering teams or FDEs.
Ideally, this handoff should include much more than just a code repo and documentation. The building team must also have a transition plan for humans or agents: how to access the code, evaluate the model results, release changes to prod, manage incidents, etc.
Note: I will dive deeper into the different models for operator owned capability shapes in a future issue.
Partner Manages the Maintenance: An external partner assumes the operator role on behalf of the organization with specific, documented Service Level Agreements (SLAs), escalation paths, etc.
Mentally, similar to how MSPs operate for IT applications. For middle-market orgs, especially those with lean IT teams, this can be a practical answer, though selection of firms is limited.
As with any service, I would recommend explicit language around pricing, governance, and exit path(s) to ensure quality service management.
Build and Operation Shared: Both builders and the operating teams build and run the app together, with overlapping but not fully equivalent responsibility. This is most closely aligned to DevOps collaboration principles. While this model can be extremely effective, it can be tricky for less mature / lean engineering teams.
We still need to identify an owner up front. None of these maintenance models remove the requirement that someone or some team needs to own the application or service throughout the build, handoff, maintenance, and retirement phases.
Productize Shared Operations
It’s rare (though not impossible) for teams to build and market internal tools that scale well beyond their team. This would be wonderful in theory, but is unlikely to be unanimously successful without strong internal community and leadership buyin. Internal products still need product management and product vision, or these products can even consume capacity from the team’s normal duties.
For example, I have seen a team build a feature flag service that was useful for their own delivery and safe feature rollouts before the equivalent SaaS was available internally. After other teams started using the service, up to ~40% of the team’s capacity was consumed to enhance and manage the feature flag application. But their code mandate hadn’t changed, so their velocity took a hit before an owner was named for the flagging service (which was eventually retired).
Central group manages software that was chucked over the wall: We have been working hard for years to further integrate engineering, product, and business teams; this undoes a lot of that transformation. This group will have to try their best to manage more than they can reasonably deliver. Hopefully others agree, but the gap between pilot / MVP and production is large. Productionizing and operationalizing code is still hard work (especially with non-SWE citizen development). The handoffs will lead to long lead times, and games of telephone (e.g., builder agent to builder to operator to operator agent).
Centralized AI / Engineering support: A central group that only answers questions about what to do and how to do it. The engineers will likely disengage, and outcomes could suffer.
Google SRE treats this problem as a true risk, which they work to actively manage. In their documentation, they promise new hires that SRE is not the typical Ops organization, intending to “keep that promise by not allowing the SRE organization or any subteam within it to devolve into an Ops team.”
What to do instead:
Productize Shared Operations: That product can / should include infrastructure, observability / traceability, AI evaluation harnesses, release management, incident management, and plans for software retirement.
The product creates the paths to help reduce the operating work for each new application (e.g., something that lowers the cost of safe operation for every subsequent build).
Ask the question: “does this reduce the work for the next app, or only this one?” Anything that only helps the current build is a service.
Ensure that the governance function is a value exporter: Governance often gets a bad rap because it’s often a red tape machine that slows builds and re-litigates the same problems. The governance teams then retool their processes, frustrating everyone that has to relearn a new process again.
Build the systems focusing on Developer Experience (DevEx) that make the fast path the easiest path (e.g., pre-approved architecture patterns, automated risk based approvals, consistent CI/CD reference patterns, etc.).
While the measurement is different (i.e., application count vs. service count in the DORA / SRE literature), I am trying to advocate addressing the same root problem. Without intentional work at both the team and organizational level, we approach a similar ceiling. Domain teams should still own both judgement on what to do and the outcome of the work. The shared function makes operating the system easier over time (without having to recreate learnings after each improvement).
Productizing Shared Operations helps address the global capacity ceiling, not the team level ceiling, but both need to be addressed. A single team with saturated overhead can be supported with one or more of the strategies mentioned above in the Potential Maintenance Choices section. But, an overall operating saturation cannot be addressed by the same strategies (each team solves similar problems independently, which prevents knowledge and solutions from compounding).
Go-live doesn’t mean “done”; the building team has to collaborate with the operating team to enable the full application lifecycle (operating a live system, making changes, and eventually retiring the app).
Key Takeaway: Choose the Operator Before Launch
I focused the previous issue on broadening the definition of who can translate operating work into software. In this piece, I walked through the concept of the maintenance ceiling, and how to operate the system when the builder leaves to avoid hitting the ceiling.
In that spirit, before your next AI application ships, I would ask several questions to make sure that you can set the operators up for success:
Should this process or feature exist at all?
Who owns the outcome?
Who will operate it?
Has the intended operator been notified?
Who’s on the hook for bugs? Who’s on the hook for enhancements?
Which operating work should become a reusable part of the shared system?
Who decides when the automation / feature gets retired? And who performs that retirement?
If an operator can’t be named before launch, it may default to who finds the bug overnight, whether or not they have the capability to fix it is a separate problem.
Have others seen any similar problems?
Have a wonderful week!
-T