The Management Poles of Developer Infrastructure Teams - Shopify

Balancing Act: The Management Tensions Unique to Dev Infra

Managing multiple developer infrastructure teams at once reveals tensions that are hard to resolve. In my experience, three poles naturally pull against each other: management support, system and domain expertise, and road maps. None of these can be fully optimized simultaneously, and perhaps they shouldn't be. Dev Infra managers balance them according to current needs and context, adapting as necessary.

Why Dev Infra Magnifies These Tensions

While this model likely applies to any software team, developer infrastructure makes these challenges particularly acute. Infrastructure teams typically lack dedicated product managers, so engineering managers fill that gap and also take on tasks that usually belong to UX experts, like user research. The maintenance burden is heavy: teams of only six to eight developers keep multiple critical systems online for hundreds or thousands of users, often handling many support requests since in-house software has no community outside the company. Teams naturally organize around phases in the development workflow or specific technologies, building deep domain expertise over time that informs both system improvements and road maps.

Pole One: Management Support

Supporting career growth is core to any engineering manager's role. Direct involvement in team projects creates the tightest feedback loops, enabling the highest-quality coaching and mentorship. At the same time, we want to maximize the number of reports per manager—good managers are hard to find, and even the best adds overhead to a team's impact. The complication arises when balancing the scope of individual Dev Infra teams against the needs of the whole organization. The requirement for specific system and domain expertise on each team directly creates this tension.

Pole Two: System and Domain Expertise

Dev Infra teams are built around domains representing workflow phases, or occasionally specific critical technologies. Each team needs both domain knowledge and expertise in the systems involved, yet the scope of opportunities in any given area can be broad, and systems grow in size and complexity over time. Expertise is essential just for day-to-day operations: managing dependencies, migrating underlying infrastructure, and investigating incidents. Teams may also need on-call schedules—discovering your deployment tool is down while trying to ship a security fix is a poor experience for everyone.

Larger teams mean less individual on-call time and more hands for support, maintenance, and projects. As teams expand their domain knowledge, they discover more opportunities for increasing their services' impact, driving constant improvement in their area. This drive, however, risks disconnecting from the greatest opportunities for impact across Dev Infra as a whole.

Pole Three: Road Maps

Domain-specialized teams develop road maps that expand existing offerings: smoothing interfaces, scaling solutions, and looking for new ways to impact developers during specific workflow phases like code writing, CI execution, deployment, and monitoring. Early on, when Dev Infra teams are first formed, there's usually abundant low-hanging fruit, so multiple teams can improve the developer experience in parallel.

At some point, though, certain workflow aspects become much smoother than others. CI times drop to five minutes; deploys run without attention. Edge cases, bugs, and special requirements always exist at a large organization, but their impact diminishes compared to the department's broader needs. The big opportunities shift—perhaps toward a large new initiative that will radically change development in a particular way. There may be a few such opportunities, but rarely the need for radical change across all domains. Unexplored domains may exist for which no team has been assembled, but these can be hard to spot when most people are focused on well-defined existing scopes.

Idea One: Temporary Cross-Team Assignments

If leadership decides the best impact is concentrated in one team's work—call it Team A—and that team's manager can't effectively handle more reports, one direct approach is assigning several people from Team B to Team A's projects. This spreads familiarity with Team A's systems and gives people a change of pace.

The immediate question we faced was whether reassigned people should stay on their home team's support rotations. From a technical standpoint, their expertise keeps those systems running; leaving them on rotations prevents total focus on Team A and extends onboarding time. Factors to weigh include project length, Team B's size, and its maintenance burden. I favor removing reassigned people from home rotations, while understanding Team A will slow down as it picks up extra work.

Another problem emerged: Team B's manager becomes disconnected from their reports' work. Since the core issue is that Team A's manager lacks bandwidth for more reports, the loaned people receive less mentoring, performance management, and prioritization. Individual contributors can end up feeling disconnected from both their home team and the new one.

Idea Two: Whole Teams Contributing to Another Team's Goals

Having an entire team—Team B—work on systems owned by Team A mitigates the isolation problem. Team B members retain their working relationships, and Team B's manager doesn't split attention between two teams. This works well when a focused project in Team A's domain requires Team B's expertise.

This is a blunt instrument: no project work gets done on Team B's systems, which still need maintenance. There's also a demotivation risk for Team B members who may feel their domain isn't valued—mitigated if the project benefits from or requires their expertise. Our Test Infrastructure team had success here on an ongoing project adding CI system data to Services DB, the application-catalog app stewarded by another team, Production Excellence. Their expertise helped expose the data intuitively and they learned Services DB's codebase quickly through collaboration.

Idea Three: Tiger Teams

A third option is the tiger team—a specialized, cross-functional group brought together to solve a specific critical problem. People from multiple teams form a new, temporary team for a single project, often prototyping a new idea. These teams operate fast and autonomously toward a specific goal, with limited management oversight. Since members usually don't work together, the home/new team dichotomy is sidestepped, or deliberately managed. Focus means members set aside maintenance, support, and other home duties for the team's duration.

The first proof of concept for Spin was built this way over about a month. The value became clear enough that we formed a whole team around it, staffed to turn it into a proper product. That first prototype was crucial in getting the project off the ground.

None of these approaches is perfect, and they each carry trade-offs. In practice, Dev Infra managers rotate among them as contexts and priorities shift, keeping the three poles in as much balance as the current situation allows.

Trade-offs Are Inevitable

Across a decade of managing developer-facing organizations, I have not found a structure that cleanly satisfies all three poles — management support, maintenance of core systems, and preservation of domain expertise — without some degree of compromise. Every organization has its own constraints, and the balancing act demands explicit, deliberate choices about which pole takes priority in a given context.

There is no universal playbook that resolves these tensions, because the weight of each factor shifts with team maturity, system complexity, and company stage. A structure that serves a rapidly scaling platform team may hinder a stable, well-established group that benefits from deep specialization. Rather than pursuing an elusive ideal, engineering leaders should weigh the costs and benefits of each approach against their immediate organizational reality.

The most effective approach is to treat these trade-offs as ongoing decisions rather than one-time organizational fixes. Revisiting the balance on a regular cadence allows teams to adapt as systems age, headcount changes, and leadership expectations evolve. The key is to avoid inertia — the structure that made sense two years ago may no longer be the one that serves your teams best today.