An NBA team cannot build a winning roster by signing five great scorers.
Someone has to control the pace of the game. Someone has to defend the paint. Someone has to create shots for other players, cover difficult matchups and come off the bench when the starting lineup needs rest.
A roster can contain enormous individual talent and still fail because the pieces do not cover what the game demands.
Application maintenance teams have the same problem.
A company may have excellent developers but nobody clearly responsible for production reliability. It may have strong infrastructure engineers but no one translating recurring support problems into product work. Security expertise may exist somewhere in the organization, yet nobody knows when that team should be brought into a maintenance change.
When something breaks, capable people eventually solve it.
That is not the same as having an effective maintenance team.
An effective app maintenance team is structured so that the responsibilities required to keep a live application healthy are clearly covered, people have the skills and authority to perform those responsibilities, and work can move from detection to diagnosis to resolution without depending on one individual knowing everything.
Microsoft's current Azure Well-Architected guidance makes a similar point. It recommends building workload teams with a range of technical and business disciplines—including software engineering, QA, SRE, infrastructure, security, product and support—and assigning clear responsibilities for designing, deploying and operating the workload.
Microsoft Azure Well-Architected Framework: Workload teams
For Levelworks, this is where App Health becomes useful as a team-design lens. A maintenance organization does not need one person assigned to each App Health aspect, but responsibilities such as Observable, Secure, Resilient, Performant, Supported, Tested and Current & Updated should not exist in an organizational blind spot.
The objective is coverage, not titles.
A common mistake is to begin maintenance-team design by asking:
How many developers do we need?
Developers are important, but the better first question is what the application needs people to be responsible for.
A live application typically requires recurring responsibility for:
Depending on the application, several of these responsibilities may belong to the same person.
A small SaaS product does not necessarily need a full-time SRE, security engineer, DBA, QA engineer and product manager dedicated exclusively to maintenance.
It does need somebody accountable for reliability, security, data, testing and prioritization.
That distinction matters:
roles describe responsibilities; people fill roles.
One engineer may cover several roles in a small application. In a larger business-critical platform, a single responsibility may require several specialists.
NIST's Secure Software Development Framework follows the same principle. It recommends explicitly defining and periodically reviewing SDLC roles and responsibilities, including developers, testers, security specialists, product owners, operations and platform engineers.
NIST Secure Software Development Framework (SSDF)
An app maintenance team benefits from one person who can see the work as a whole.
This role might be called:
The title matters less than the responsibility.
This person should be able to answer:
The maintenance lead does not personally make every decision.
They make sure a decision has an owner.
Microsoft's Operational Excellence guidance recommends clearly defining decision-making authority and using a directly responsible individual where necessary so responsibility is distributed without leaving decisions unresolved.
This role becomes particularly valuable because maintenance work arrives from many directions: monitoring, support, security advisories, technical debt, product requirements and platform changes.
Without somebody maintaining the overall view, the queue often becomes whoever shouted most recently.
[Internal Link: “How to Prioritize Bugs, User Issues and Feature Requests”]
Software engineers usually form the largest part of the maintenance team because most application problems eventually involve understanding or changing code.
The exact mix depends on the technology.
A web application may need:
A mobile application may require iOS and Android skills.
A distributed platform may need engineers capable of working across APIs, queues, storage and services.
Maintenance engineering differs slightly from greenfield development.
Writing new code is only one part of the job.
A strong maintenance engineer also needs to be comfortable:
This is why experienced generalists are often valuable on maintenance teams.
They may not be the organization's deepest specialist in every technology, but they can investigate a problem across enough of the application to determine where specialist expertise is actually needed.
Maintenance changes frequently touch mature functionality that users already depend on.
That creates a different testing challenge from validating a newly introduced feature.
The team needs confidence that fixing one behavior has not broken another.
QA responsibility should therefore cover:
In some teams, developers own most automated testing and a QA specialist concentrates on strategy and complex validation.
In others, dedicated QA engineers maintain broader regression suites.
Either model can work.
The dangerous structure is one in which testing is assumed to be somebody else's job but nobody actually owns it.
Tested App Health is not created by having a QA job title. It comes from having reliable testing responsibilities embedded in how maintenance changes move toward production.
Once an application is in production, somebody needs to understand the environment surrounding the code.
Depending on the organization, this work may sit with:
Responsibilities often include:
Microsoft's Well-Architected guidance explicitly includes DevOps engineers, infrastructure engineers and SREs among the disciplines that may make up a workload team, while recommending that teams take end-to-end responsibility for operating their workload even when centralized specialists provide support.
This function should not become a release gate that application engineers throw work over.
DORA's research on loosely coupled teams finds better delivery capability where teams can complete changes, test and release without requiring constant fine-grained coordination with external teams.
DORA: Loosely Coupled Teams
The healthier model is for maintenance engineers to understand enough operational practice to own their application, while platform specialists provide reusable capability and deeper expertise.
A maintenance team does not necessarily need a security specialist sitting permanently inside it.
It does need a defined security relationship.
Someone must be responsible for questions such as:
NIST's SSDF explicitly recommends integrating security responsibilities into software-development roles and identifying security specialists, champions and other relevant participants rather than leaving secure development outside the normal SDLC.
A practical model is often:
core team owns everyday secure development practices; specialist security teams support higher-risk analysis.
This avoids two bad extremes.
In the first, developers assume security belongs entirely to the security team.
In the second, every routine maintenance change waits for a scarce central specialist.
Support teams see application problems from a perspective engineering cannot reproduce through monitoring alone.
They hear:
“This keeps happening every Monday.”
“Only administrators seem affected.”
“Customers have started using this workaround.”
That evidence should reach the people maintaining the product.
A useful relationship is:
Customer
↓
Support
↓
Triage
↓
Maintenance engineering
↓
Product / technical decision
Support should not forward every user question directly to developers.
Nor should engineering remain unaware of repeated problems because support continues solving them manually.
A strong maintenance structure creates an explicit path for:
The support team provides customer context; engineering provides technical diagnosis.
[Internal Link: “What Does Good Post-Launch Application Support Look Like?”]
Maintenance teams need somebody who can make product decisions.
Suppose engineering identifies three pieces of work:
Engineering can estimate effort and technical risk.
It cannot decide business priority alone.
A product owner or equivalent stakeholder should help determine:
This does not necessarily require a dedicated full-time product manager in a small maintenance engagement.
It requires access to somebody authorized to make product decisions.
Without that, developers are forced to make business choices implicitly.
Not every maintenance team needs a full-time designer.
But mature applications accumulate experience problems.
A form becomes awkward after several fields are added. Navigation grows. Two workflows use inconsistent patterns.
Engineering can identify some of this friction but should have access to UX expertise when meaningful interface changes are required.
The same applies to accessibility.
The best structure is often shared capability: designers and accessibility specialists join when the maintenance backlog contains work requiring those skills.
That keeps the core maintenance team lean without pretending every problem can be solved through engineering alone.
Some applications can be maintained comfortably by backend engineers with good database knowledge.
Others cannot.
A high-volume transactional platform, analytics product or application with complex migrations may need deeper DBA or data-engineering capability.
The important responsibilities include:
The maintenance structure should reflect the application's actual risk.
Do not hire a specialist because a generic organizational chart says one belongs there.
Do not omit one because developers have managed so far.
The application should determine the skill requirement.
One of the most practical team models is to divide maintenance capability into two groups.
People involved continuously:
People brought in when relevant:
Microsoft describes a similar arrangement between a workload team and centralized teams, where the workload team owns the application outcome while centralized groups provide specialist services, governance and capabilities that individual teams may not need to maintain themselves.
This structure avoids two expensive mistakes:
building a permanent specialist team far larger than the application requires, or maintaining such a narrow team that every unusual issue becomes a scramble to find outside help.
A good maintenance team needs broad understanding and deep expertise.
Those are different.
A backend engineer should understand enough of deployment and observability to investigate production behavior.
They do not need to become the organization's deepest Kubernetes specialist.
A DevOps engineer should understand how the application behaves.
They do not need to implement every business rule.
Microsoft's current Operational Excellence guidance recommends deliberately building cross-functional teams whose members retain specialization while developing enough general knowledge of other functions to support one another and understand the workload end to end.
This is often described informally as T-shaped capability: depth in one discipline with sufficient breadth to collaborate across others.
For maintenance work, that breadth reduces handoff cost.
If only one engineer understands billing, that engineer has become part of the system architecture.
If only one person can deploy production, they are a deployment dependency.
If only one person can respond to database failures, every holiday and resignation becomes operational risk.
Critical responsibilities should therefore have:
Cross-training is particularly important for:
This does not require every engineer to become equally skilled.
It means the application should not become effectively unmaintainable because one person is unavailable.
[Internal Link: “Why Good Documentation Makes an App Cheaper to Maintain”]
Business-critical applications may require support outside normal working hours.
That does not automatically mean every maintenance team should run a 24/7 internal on-call rotation.
The appropriate model depends on:
If on-call is required, it must be sustainable.
Google's SRE guidance is useful here because it treats on-call load as an engineering-capacity issue rather than unlimited human availability. Google describes balancing both the quantity and quality of on-call work and deliberately protecting SRE time for engineering improvements and automation rather than allowing operations to consume the entire team.
Google SRE: Being On-Call
Google's specific staffing numbers are based on its own operating model and should not be copied blindly. The broader lesson is more valuable:
if the same small group is continually interrupted by production problems, the team needs either more coverage or fewer recurring problems.
A maintenance structure that depends on heroics is not adequately staffed.
When a serious incident occurs, the team's ordinary organizational structure may not be the most effective way to work.
A senior backend engineer may be the technical expert, while another person is better suited to coordinating response.
Useful temporary incident roles include:
Atlassian's incident-management guidance recommends assigning explicit response roles before or during an incident so coordination, technical investigation and communication do not compete for the same person's attention.
Atlassian: Incident Response Roles and Responsibilities
This is an important distinction.
Your maintenance-team structure defines normal ownership.
Your incident structure defines how those people reorganize when the application is under pressure.
[Internal Link: “Application Incident Response: What Should Happen When Your App Goes Down?”]
A maintenance team can become a ticket-processing machine.
Every day contains:
The team remains busy while the application barely becomes easier to maintain.
Google SRE uses the term toil for repetitive, manual, operational work that grows with the service and does not provide lasting improvement. Its operating model deliberately protects significant engineering capacity for projects that reduce operational burden through automation and system improvement.
An effective maintenance team therefore needs capacity for two kinds of work:
Operate the application today.
and
Make operating it tomorrow easier.
That might mean:
If every available hour is consumed by incoming tickets, the team's structure may be adequate for response but inadequate for maintenance.
Different roles often create separate queues.
Support has tickets.
Engineering has bugs.
Security has vulnerabilities.
Infrastructure has upgrade work.
Product has features.
That makes trade-offs difficult.
The maintenance lead should have enough visibility across these streams to understand total workload, even when each system keeps its own operational records.
Microsoft's Operational Excellence guidance recommends using a common, prioritized backlog and transparent planning processes for workload improvements.
The objective is not necessarily one software tool.
It is one prioritization conversation.
There is no universal maintenance-team org chart.
A useful way to think about structure is by increasing complexity.
A smaller application might have:
Several people wear multiple hats.
The main risks are skill gaps and excessive dependence on one engineer.
As usage and complexity increase, a dedicated pod may include:
Security, UX and database expertise can still be shared.
This structure provides enough continuity to build deep knowledge of the application without creating every specialist role permanently.
Large systems often become too complex for one team to understand deeply.
Maintenance responsibility may therefore be divided by domain:
Customer domain team
Billing domain team
Reporting domain team
Integration domain team
↓
Shared platform / SRE / security capabilities
Each team owns a defined part of the application while shared teams provide infrastructure, security and operational capabilities.
DORA's research on loosely coupled teams supports organizational structures where teams can make and release changes within their area without constant dependency on other teams.
The key is that the boundaries in the team structure should correspond reasonably well to boundaries in the software.
Maintenance problems often occur where everybody assumes somebody else owns the work.
A lightweight responsibility map can prevent that.
For example:
Responsibility
Primary
Backup / Support
Backlog prioritization
Maintenance lead + product
Engineering
Application defects
Application engineering
QA
Regression strategy
QA lead
Engineering
Production infrastructure
SRE / DevOps
App engineering
Security vulnerabilities
Engineering
Security team
Customer issues
Support
Maintenance lead
Database reliability
Backend/data owner
DBA/platform
Incident coordination
Trained incident lead
Engineering lead
You do not need a complex RACI chart for every task.
Use explicit responsibility where ambiguity creates delay.
Closing many maintenance tickets can look productive.
It may simply mean the backlog contains many small tickets.
Better questions include:
These measures reveal whether the team is improving the condition of the application rather than merely processing work.
That is also where Levelworks' App Health model becomes useful.
A maintenance team can periodically look across relevant health aspects and ask whether it has both technical coverage and organizational ownership.
If performance deteriorates, who owns investigation?
If observability is poor, who improves it?
If users repeatedly struggle, who converts that signal into action?
If nobody can answer, the gap is partly an organizational one.
Before finalizing the structure, confirm that you can answer these questions:
Area
What should be clear
Ownership
Who is accountable for overall application maintenance?
Engineering
Who can safely diagnose and change each major part of the app?
Testing
Who owns regression confidence?
Operations
Who owns deployments, monitoring and infrastructure?
Security
Who handles routine and escalated security work?
Support
How do real user issues reach engineering?
Product
Who decides business priority and intended behavior?
Specialists
Which skills are shared rather than permanent?
Coverage
Who backs up critical knowledge and operational responsibilities?
Incidents
Who coordinates, investigates and communicates?
On-call
Is after-hours coverage actually sustainable?
Improvement
Does the team have capacity to reduce recurring maintenance work?
The right answer will look different for every application.
That is the point.
It is easy to evaluate a maintenance team by counting people.
Four developers. One QA engineer. One DevOps engineer.
Those numbers reveal very little about whether the application is actually covered.
A six-person team can still have nobody who understands database recovery. A three-person team supporting a modest application may have excellent ownership, automation, testing and access to shared specialists when needed.
The stronger test is to look at the application itself and trace responsibility around it.
For every important part of keeping the software healthy, there should be somebody who owns the outcome, somebody who can step in when that person is unavailable, an understood path to specialist expertise, and enough engineering capacity to remove recurring problems rather than merely absorb them.
That is what turns a group of capable individuals into an effective maintenance team.
The roster matters. But what makes it work is that when the application needs defending, changing, recovering or improving, everyone already knows where they are supposed to be.
