Mapping Dev Infra: A Workflow-First View

Developer Infrastructure—Dev Infra for short—covers a wide range of systems at Shopify, from local development environments and CI/CD pipelines to frameworks, libraries, and productivity tooling. After nearly a decade managing such teams, I've found that a clear mental model of how these teams interrelate is invaluable. It clarifies dependencies between domains, exposes gaps in our solutions, and helps every team member see how their work contributes to a larger vision.

No single model is perfect. The structure of teams changes, and it's useful to have different lenses to highlight different relationships. Below is one model I used last year, reflecting the org at that time. Constructing it actually helped me think through alternative structures and ultimately led to a reorganization. First, a quick overview of the teams that reported to me:

  • Local Environments: Tooling for setting up projects on a local machine (MacBook Pro), including cloning repos, installing dependencies, and running backing services.
  • Cloud Environments: A new team exploring development on remote, on-demand systems.
  • Test Infrastructure: Owners of our CI systems, focused on continuous improvement and scaling for Shopify's growth.
  • Deploys: Handles the final steps of the development process: merging commits to main branches (we've outgrown GitHub's standard process), validating on canary systems, and promoting to production.
  • Web Foundations: Accelerates React-based app development with dedicated tools and libraries for our large front-end codebases.
  • React Native Foundations: Similar to Web Foundations, but standardized around building React Native apps.
  • Mobile Tooling: Builds specialized tools since mobile apps have distinct needs compared to web apps.

The Development Workflow Lens

One way to view these teams is as parts of a development pipeline, split into three discrete phases:

  • Develop: Setting up local dependencies, creating patches, and local testing.
  • Validate: Building on CI and running test suites.
  • Deploy: Merging patches, building final images, and shipping to production.

The Local Environments, Cloud Environments, Test Infrastructure, and Deploys teams each map neatly to one phase. Their scope is broad, defaulting to support for Ruby on Rails apps, but each owns a specific part of the generic workflow.

In contrast, the systems supported by Mobile Tooling, Web Foundations, and React Native Foundations span multiple phases. For instance, Web Foundations focuses most of its effort on the development phase with frameworks and libraries, but also maintains a separate application executed during validation to monitor bundle sizes. Their work builds on top of the systems owned by the horizontal teams, adding specialized front-end tooling as a complement.

The Mobile Tooling and React Native Foundations teams' work spans all three phases, though their deployment phase is independent from the generic workflow given the very different release process for mobile apps.

Horizontal vs. Vertical Integration

We can extend this workflow model by borrowing a concept from manufacturing. In that industry, horizontal integration means each point in the supply chain—producer, supplier, manufacturer—is a separate entity, providing deep specialization in a particular area.

Viewed this way, Local and Cloud Environments, Test Infrastructure, and Deploys are horizontally integrated. The generic development workflow is the supply chain, and each team owns one phase of it: maintaining relevant systems, implementing optimizations, and scaling to handle increasing development activity.

Vertical integration, by contrast, involves a single owner handling multiple parts of the supply chain. IKEA is a classic example, owning everything from forests to retail stores to take a holistic approach to their industry.

The Mobile Tooling, Web Foundations, and React Native Foundations teams operate similarly: they own the entire development workflow for a specific technology stack, spanning two or all three phases. They aren't fully vertically integrated—they still rely on the horizontal teams' underlying systems—but rather than specializing in a single phase, they act as subject matter experts on the end-to-end development lifecycle for their respective technologies, building bespoke solutions where generic ones fall short.

What the Model Reveals

Examining these teams through this lens surfaces a few useful insights. First, it gives the whole area a clear mission statement: "Improving and scaling the develop–validate–deploy cycle for Shopify engineering." Having this framework makes it easier to push back on work that doesn't fit, and to distinguish Dev Infra from other teams in our parent group, Accelerate.

There's also a fundamental contrast between the two groups: horizontal teams enjoy broad scale, while vertical teams carry broad scope. Nearly every developer interacts with the systems owned by the horizontal teams—environments, CI, deploy—which inherently means constant traffic and scaling pressure. On the other hand, vertical teams serve a smaller segment of engineers, but have the latitude to improve the entire development journey for their technology, giving them a different kind of ownership.

This structural difference also creates distinct collaboration dynamics. Vertical teams, due to their scope, have more chances to partner with product teams—but this also creates a risk of product teams building their own divergent solutions when Dev Infra can't prioritize everything. Close contact with product engineering is essential to avoid duplication and to steward infra projects that outgrow their original teams. Horizontal teams see fewer outside contributions because their infrastructure is deep, complex, and critical at scale. However, they enjoy more consistency, since there are few alternative paths around such foundational systems.

From Model to Practice

Shopify's Accelerate and Dev Infra organizations have begun using the horizontal/vertical classification to decide where to invest. Work on any part of the development pipeline now falls into one of three categories:

  • Concentration: strengthening existing systems, improving user experience, and making incremental scaling improvements
  • Expansion: finding new problems to solve within a domain and pursuing step-change or exponential scaling
  • Interfacing: improving connections between phases in the pipeline, both in data flow and user experience, and identifying gaps where a new or existing team should take ownership

The two team orientations lend themselves to different strengths. Horizontal teams have well-bounded scope, which simplifies prioritization, but their impact stays within that boundary, and interfaces between teams are harder for them to address. Vertical teams face the opposite trade-off: a broader mandate opens up more possibilities for impact but makes prioritization harder, while interface work can be easier when it falls between components a single team controls.

The analysis also shaped the org chart. Earlier this year, Accelerate launched the Client Foundations team, made up of vertically integrated, technology-focused groups specializing in front-end and mobile. On the Dev Infra side, the model opens the door to bringing in teams from other organizations that can extend the workflow model and add new horizontal integrations. Both orgs are also experimenting with more active collaboration between teams so engineers build a broader understanding of the full workflow.

Going forward, the plan includes user research that spans the entire development workflow. Most prior research was scoped at the team level: investigating repetitive tasks for mobile developers, friction in the test infrastructure, or the usability of deploy systems. With a shared vocabulary for the developer journey from first patch to production, the work can instead target holistic improvements that give developers the smoothest end-to-end experience.