Who's responsible for keeping the code healthy? Some organizations have dedicated teams - platform engineering, developer experience, infrastructure - that own code quality across the organization. Others distribute this responsibility across product teams, making each team responsible for their own code. Both models have advocates, and AI tools like Devonair are changing the equation.
Choosing the right model affects how effectively maintenance happens, how standards are enforced, and how teams experience their work. The wrong model can leave gaps (distributed without coordination) or create bottlenecks (centralized without capacity). AI-powered automation can reduce these trade-offs by handling routine work regardless of organizational structure.
Centralized Maintenance: The Platform Model
Centralized maintenance concentrates maintenance responsibility in dedicated teams.
How Centralized Maintenance Works
A central team owns maintenance:
Centralized model:
- Platform team owns tooling
- Platform team sets standards
- Platform team drives improvements
- Product teams consume platform services
Dedicated teams focus on maintenance infrastructure.
Common Patterns
Platform Engineering Team
Dedicated infrastructure:
Platform team responsibilities:
- CI/CD pipelines
- Testing infrastructure
- Code quality tools
- Dependency management
Platform team provides maintenance capabilities.
Developer Experience Team
Focused on AI-powered developer tools:
DevEx team responsibilities:
- Developer tooling
- Development environment
- Productivity improvements
- Automation
DevEx team makes maintenance easy.
Centralized Maintenance Squad
Dedicated maintenance capacity:
Maintenance squad responsibilities:
- Cross-cutting maintenance
- Organization-wide improvements
- Standards enforcement
- Technical debt reduction
Dedicated team for maintenance work.
Strengths of Centralized
Expertise Concentration
Specialists get good at maintenance:
Centralized strength:
- Deep expertise develops
- Best practices known
- Efficient at maintenance
- Cutting-edge knowledge
Specialists become experts.
Consistency
Same approach everywhere:
Centralized strength:
- Consistent standards
- Consistent tooling
- Consistent quality
- Easier compliance
One team ensures organization-wide consistency.
Efficiency
Do it once for everyone:
Centralized strength:
- Build tool once, use everywhere
- Fix problem once, benefit everyone
- No duplicated effort
- Leverage across organization
Central teams create leverage.
Career Path
Specialization enables growth:
Centralized strength:
- Maintenance as career
- Deep specialization possible
- Recognized expertise
- Growth opportunities
Central teams provide career paths for maintenance-focused engineers.
Weaknesses of Centralized
Bottleneck Risk
Central team can't keep up:
Centralized weakness:
- More teams than central capacity
- Requests queue up
- Teams wait for platform
- Frustration builds
Central teams can become bottlenecks.
Context Loss
Central team doesn't know every codebase:
Centralized weakness:
- Doesn't know product context
- May apply inappropriate standards
- May miss domain-specific needs
- Generic solutions for specific problems
Context is distributed across teams.
Ownership Confusion
Who's really responsible?
Centralized weakness:
- "That's platform's job"
- "We're waiting on platform"
- Diffused accountability
- Nobody fully owns quality
Central teams can displace ownership.
Scaling Challenges
Central team must grow with organization:
Centralized weakness:
- Organization grows faster than platform team
- Platform team headcount is precious
- Can't serve everyone
- Prioritization conflicts
Scaling central teams is hard.
Distributed Maintenance: The Team Model
Distributed maintenance spreads responsibility across product teams.
How Distributed Maintenance Works
Each team owns their maintenance:
Distributed model:
- Each team maintains their code
- Each team chooses their tools
- Each team sets their standards
- Teams are self-sufficient
Responsibility distributed to code owners.
Common Patterns
Full Ownership
Teams own everything about their services:
Team responsibilities:
- Build it
- Run it
- Maintain it
- All quality aspects
Complete ownership includes maintenance.
Embedded Expertise
Maintenance expertise in each team:
Team composition:
- Product engineers
- Plus maintenance-focused member
- Or rotation of maintenance duty
Expertise distributed to teams.
Shared Standards, Local Execution
Common guidelines, team implementation:
Distributed with standards:
- Organization guidelines exist
- Teams implement locally
- Teams adapt to context
Guidance without central execution.
Strengths of Distributed
Context Awareness
Teams know their code:
Distributed strength:
- Deep understanding of code
- Know why things exist
- Understand trade-offs
- Can make appropriate decisions
Context enables better decisions.
No Bottleneck
Teams don't wait:
Distributed strength:
- Teams control their timeline
- No queue for central team
- Immediate action possible
- Self-service
Distributed enables speed.
Clear Ownership
Teams are accountable:
Distributed strength:
- "We own this"
- Clear accountability
- Pride in quality
- Can't blame others
Ownership creates accountability.
Scalability
Scales with organization:
Distributed strength:
- Each team handles their own
- No central scaling constraint
- Grows naturally with organization
Distributed scales inherently.
Weaknesses of Distributed
Inconsistency
Different teams, different approaches:
Distributed weakness:
- Team A: Uses Tool X
- Team B: Uses Tool Y
- Team C: Uses nothing
- No organization-wide consistency
Without coordination, approaches diverge.
Duplicated Effort
Everyone solves the same problems:
Distributed weakness:
- Team A builds auth library
- Team B builds auth library
- Team C builds auth library
- Repeated work
No leverage without coordination.
Variable Quality
Some teams better than others:
Distributed weakness:
- Team A: Excellent maintenance
- Team B: Good maintenance
- Team C: Little maintenance
- Quality varies
Without standards, quality varies.
Expertise Fragmentation
No deep specialists:
Distributed weakness:
- Everyone knows a little
- Nobody knows a lot
- Best practices not shared
- Reinventing wheels
Distributed expertise is shallow.
Comparing the Models
Direct comparison across key dimensions.
Consistency
| Factor | Centralized | Distributed | |--------|-------------|-------------| | Standards application | Uniform | Variable | | Tool consistency | High | Low | | Cross-team compatibility | Good | Challenging | | Compliance | Easier | Harder |
Centralized provides consistency.
Speed
| Factor | Centralized | Distributed | |--------|-------------|-------------| | Team autonomy | Lower | Higher | | Wait time | Potential | None | | Bottleneck risk | Higher | Lower | | Execution speed | Depends | Fast |
Distributed enables speed.
Quality
| Factor | Centralized | Distributed | |--------|-------------|-------------| | Expertise depth | High | Variable | | Context awareness | Lower | Higher | | Best practices | Developed | Variable | | Minimum quality floor | Higher | Lower |
Each has quality advantages.
Scalability
| Factor | Centralized | Distributed | |--------|-------------|-------------| | Organizational growth | Constrained | Natural | | Central team sizing | Critical | N/A | | Team independence | Lower | Higher |
Distributed scales more naturally.
The Hybrid Model
Most successful organizations combine approaches.
Central Infrastructure, Distributed Execution
Central team provides AI tools; teams use them:
@devonair hybrid model:
- Platform: Provides scanning tools
- Platform: Provides automation framework
- Teams: Run tools on their code
- Teams: Own their maintenance
Central enables, teams execute.
Shared Standards, Local Ownership
Standards exist but teams own compliance:
@devonair shared standards:
- Organization: Sets standards
- Platform: Provides tooling
- Teams: Implements and maintains
- Teams: Accountable for quality
Guidance without micromanagement.
Federated Model
Experts in teams, coordinated centrally:
Federated approach:
- Each team has maintenance capacity
- Central guild coordinates
- Best practices shared
- Standards collaboratively developed
Distributed execution with coordination.
Choosing Your Model
Context determines the best fit.
Favor Centralized When
- Organization values consistency highly
- Compliance requirements are strict
- Teams lack maintenance expertise
- Leverage across organization is valuable
Favor Distributed When
- Teams are autonomous and accountable
- Speed and flexibility are priorities
- Teams have maintenance capability
- Context-specific decisions are common
Favor Hybrid When
- You want consistency with autonomy
- Organization is large and diverse
- Both expertise and context matter
- Scalability and quality both matter
Implementation
Putting the model into practice.
Implementing Centralized
Build central team:
1. Define scope and responsibilities
2. Staff with appropriate expertise
3. Build tools and infrastructure
4. Define engagement model with teams
5. Measure impact
Central teams need clear scope and capacity.
Implementing Distributed
Enable distributed:
1. Define standards and guidelines
2. Provide tools and training
3. Establish accountability
4. Measure quality by team
5. Share best practices
Distributed needs enablement and accountability.
Implementing Hybrid
@devonair implement hybrid:
1. Central team provides infrastructure
2. Standards defined collaboratively
3. Teams own execution
4. Guild coordinates and shares
5. Measure both consistency and quality
Hybrid needs clear boundaries.
Getting Started
Choose and implement your model.
Assess your context:
@devonair assess:
- Current maintenance patterns
- Team capabilities
- Consistency needs
- Scaling trajectory
Choose initial model:
@devonair choose:
- Based on organizational needs
- Based on team capabilities
- Plan for evolution
Implement:
@devonair implement:
- Build capabilities (central or distributed)
- Define responsibilities
- Enable execution
- Measure results
The right model isn't universal - it depends on your organization. Centralized models provide consistency and expertise. Distributed models provide speed and ownership. Hybrid models balance both. Choose based on what matters most to your organization, and adjust as you learn.
FAQ
Can we start distributed and move to centralized later?
Yes, but it's harder than the reverse. Moving to centralized requires building central capacity and getting teams to give up autonomy. Starting centralized and distributing later is often easier.
How big should a central platform team be?
A common ratio is 1 platform engineer per 10-15 product engineers, but this varies based on scope and leverage. If your platform team is a bottleneck, either expand capacity or shift execution to teams.
How do we ensure quality in a distributed model?
Set clear standards. Provide tooling that makes compliance easy. Measure quality by team. Create incentives for quality. Share best practices actively. Make poor quality visible.
What about small organizations?
Small organizations often don't need dedicated central teams. One or two engineers focusing part-time on infrastructure can provide central capability. As you grow, formalize based on needs.