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.

Subscribe now

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.

1. 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.

1. 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.

2. 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:

1. 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.

   1. 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.

   2. Note: I will dive deeper into the different models for operator owned capability shapes in a future issue.

2. 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.

   1. 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.

   2. As with any service, I would recommend explicit language around pricing, governance, and exit path(s) to ensure quality service management.

3. 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:

1. Should this process or feature exist at all?

2. Who owns the outcome?

3. Who will operate it?

4. Has the intended operator been notified?

5. Who’s on the hook for bugs? Who’s on the hook for enhancements?

6. Which operating work should become a reusable part of the shared system?

7. 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

Forward deployed engineering is implementation consulting rebuilt for new probabilistic based software systems. AI agents will make building these software solutions cheaper, but durability sits in the translation between a Profit and Loss statement and software behavior (including the software controls, change management, and owned capabilities). AI is quickly changing the tools to implement and increasing the pace of change, but it does not remove the need for the implementation discipline, nor the work needed to bridge the talent supply shortage we are currently facing.

Time Machine to 2014

In 2014, implementing a Laboratory Information Management System (LIMS) meant wiping my clipboard with isopropyl alcohol, gowning up in my blue bunny suit, and walking into ISO 8 and ISO 7 manufacturing areas.

The site made injectable IV bags across multiple manufacturing lines: saline, Lactated Ringer’s, and other terminally sterilized products (i.e., non-aseptic filled products). I was helping implement some of the LIMS workflows for biological and chemistry quality (BQ and CQ) on what was then Lonza’s MODA platform.

That meant locating the environmental monitoring points across the actual manufacturing plant. For example, that could be identifying physical tank-sampling valves or viable and total-particulate monitoring locations. Then, determining how frequently each one needed to be sampled. The BQ and CQ teams needed to know what sample to collect, where to collect it, and the sample scheduling to make sure they were compliant.

Also, those aligned answers had to be consistent across the process, the standard operating procedure, and the LIMS system configuration. If one of those aspects was incorrect, the software was wrong, and we could be at risk of a potential investigation (if you haven’t written a CAPA before, you’re in for a treat). The implementation also had to go through pharmaceutical software validation and hold up during an eventual FDA audit.

This overall exercise taught me one of the most valuable lessons of my career:

None of the implementation exercise started with the code. The process started with walking the floor, physically speaking with the operators doing the work, and translating that work into the software.

Implementation as a Discipline

Today, many folks would describe much of that implementation process as forward deployed engineering. At the time, my badge said engineer, but we didn’t call that work “Forward Deployed Engineering,” we just called it software implementation.

I am not making the old-man-on-the-internet claim that we secretly invented FDE first (I hope I’m not there yet, but my kids may say otherwise). Admittedly, the FDE title is also still useful, and the current AI assisted tooling genuinely changes what one person can build. My point is that the discipline underneath this new motion already had a name, a methodology, and history several decades before the current label arrived.

That methodology really narrowed down to business // technology translation; how can one translate a problem into a system that changes (and hopefully improves) the operation in a meaningful way.

See the below metaphorical translation “chain” that starts with the Profit & Loss (P&L) of the business and walks forward all the way to “reality” where things are executing and working within that business.

In the above translation chain, the software box is only one small part of driving improvements that translate back to the P&L of a business. If you enter the improvement process at the “software behavior” box, you are gearing up to learn an expensive lesson. By starting downstream, you inherently agree to every upstream assumption, and treat them as settled.

Starting this late, it’s much harder to challenge the process.

Outside of technical implementation chops, an FDE should be able to work through tough implementation questions about the process and push back where the best solution is NOT AI.

Likewise, as a buyer, I would hope and expect that an FDE would ask questions like:

• Process Hops: Is this process handoff necessary?

• Regulatory Requirements: Is it required by a regulation / law?

• Change Management: Does this process exist because it is just “the way we have always done it?”

• Exception Management: Is the exception actually exceptional or should it be a warning?

• Outcome Measurement / KPI / OKR: Does the measurement metric measure the desired outcome of the process?

• Optimization: Do we even need this process at all? (the most efficient process is an eliminated one)

Often, one of those assumptions / questions actually highlights the breakdown in the value chain.

ERP vendors built an enormous talent market around folks who could cross the gap between SAP transaction codes and a business process. Over time seasoned consultants would also build a heuristic understanding of where these flows would typically fall apart within an organization AND how to help redesign process around their system (partly for the betterment of the organization, but also partly because it made the ERP more sticky).

Over time, the implementation process became repeatable, and a competitive advantage for consultants. There was much time spent honing implementation methods, building talent development pipelines (through materials and a lot of on-the-job training), and even rate differentials for on/nearshore delivery. As the market saturated, the generic delivery DID get cheaper, but the domain expertise, business judgment, and apprenticeship / capability building genuinely remained scarce.

Back to the Present

With new capabilities (i.e., AI), the time it will take us to build repeatable implementation processes, build new implementation methods, talent development pipelines, etc. will almost assuredly decrease. Agent / software factories, lowcode agent builders, managed code environments (i.e., runtimes) and model provider tooling are already compressing the build and execution. At the same time, the frontier labs like Anthropic & OpenAI are investing billions in “last mile” implementation and delivery because access to foundation models does not guarantee a change in client operations.

I argued in my first article that the model was the small piece in a much larger ecosystem required to create value. When it comes to the FDE / talent play, the model IS a real difference in this wave because it enlarges the whole diagram rather than just one box. When you have these probabilistic models, you must embrace and defensively design systems that handle receiving different answers to the same question (the model is a software slot machine after all).

To resolve this, there are several best practices we have to consider in designing and building these systems (i.e., building continuous evaluation, ensuring your failures are loud and not shaped like successes, facilitating meaningful organizational change management, and being ready to manage the complexity of ongoing maintenance).

Consequently, these factors make the implementation discipline MORE important. With this in mind, it makes sense that the current demand for these folks is outstripping supply, but that leaves us with a new question…

Ok, how do we mint more of these people?

My current working prediction is that many excellent FDEs will come from business analysis, operations, domain roles, and automation engineering, not only conventional software engineering. Code is getting cheaper to teach and produce, and access to world class training materials is being created for free on YouTube and made available by the foundation model providers. However, twenty years of expertise and judgment from a niche domain continues to be scarce.

Therefore, while we shouldn’t lower the talent standard, we must consider broadening the talent pool to meet the demand.

Please check out the full essay including proposed hiring models here.

I’m curious where you draw the line between implementation and forward deployed engineering!

Have a wonderful week and upcoming weekend,

-T

Just like in 2015, the same is true today with AI. From an engineering perspective, we have several to dozens of boxes across data, infra, observability, inference, and more. Similarly, we also have to consider process integration, change management, training and talent management, support, financial validation to fully capture value from the system.

The diagram is just as relevant today as it was then. Teams and leaders often focus on the model (i.e., hallucination / cost / vendor lock in, etc.). While this is incredibly important, results depend on the full supporting system.

The FULL system, the one going much beyond the model, is also why I’m writing this newsletter. The Rest of the System covers the work, judgment, ownership, controls, and long term maintenance around the model. These aspects drive whether AI creates long term value for people and organizations, or the pilot gets canned or relegated to the backlog.

I spent the last ~15 years implementing systems inside larger orgs, most of which are regulated. I walked manufacturing floors in pharma / consumer products, implemented automations and software, worked with LOB finance teams to qualify opportunities, and HR to carefully plan change management and long term talent management.

I work with leaders most days to plan, design, build, deploy, and retire solutions today, so I will share what I am building, seeing, and reading from that lens, and I promise to share real examples when I have them.

Three recurring lenses will organize the publication (likely more to follow):

• Field Notes: translation from the physical or business process into software.

• Shaped Like Success: systems that look green while quietly failing (particularly insidious with AI / nondeterministic systems).

• After the Demo: adoption, ownership, maintenance, and the operating life of a build.

Expect one issue every week or two.

The full detailed essays, models, and figures live at tomsullivan.dev, but each email version will stand on its own.

The complete flagship essay behind the first issue is currently live here:

• Forward-Deployed Engineering Is New. The Work Underneath It Is Not.

Request: Please drop me a line and tell me what part of the AI implementation / management process your organization is still figuring out how to build and / or own. I read every reply, and the answers steer what I investigate next.

Have a wonderful week,

Tom