At Shopify, the Developer Infrastructure team exists within a broader Developer Acceleration organization that defines their mission as making developers at the company highly productive. Although this mission statement helps guide direction, it is a broad description that leaves a lot of room for interpretation about what projects to actually focus on.

In this article, we cover the story of how the Developer Infrastructure team built on its parent organization’s mission statement to define its own team charter and guiding principles. This article is based on an interview with Mark Côté, who leads the Developer Infrastructure team.

The need for a charter

Shopify’s Developer Infrastructure team owns a wide range of work, spanning everything from developer environments and CI/CD to frameworks, libraries, and productivity tools. Without a clear charter, the team found that it could easily end up taking on projects that weren’t necessarily the highest priority for the business.

Another reason why the team decided to formalize their charter: to help clearly communicate the reasoning for specific projects with leadership. Côté explains: 

We wanted to better communicate to leadership about why we exist and how we think about our problems. That way if they’re looking at an individual project and wondering ‘How does that fit in?’ they can go to our charter and see, ‘Ok, this ladders up to a particular area of opportunity.’ It helps teams communicate about projects without getting into the nitty gritty of why a system needs a particular new feature in it, for example.

Defining a charter

The Developer Infrastructure team’s charter includes two distinct components: opportunities for impact, and guiding principles. These components both tie back to their parent organization’s mission of making developers at Shopify more productive. The following sections describe each of these components in further detail.

Opportunities for impact

Defining a team’s areas of focus, or “opportunities for impact,” helps answer the question of what problems a team does and does not work on. To identify these areas, the Infrastructure team reviewed projects they’d already worked on as well as future opportunities they saw. They also reviewed notes from blogs, podcasts, and conversations about how similar functions at other companies define their charter.

Once the team had reviewed and organized all of their notes, they came up with three categories under which all opportunities could be organized: tightening feedback loops, reducing cognitive overhead, and scaling up engineering. 

‍

Tightening development feedback loops refers to providing developers with the information they need when they need it. Two examples of projects the team has focused on that map to this category: 

• Building an automation system called "Caution Tape Bot", integrated into their service catalog, that monitors pull requests for specific patterns and posts warnings about potential problems or unexpected system interactions.
• Improving notifications from their deployment system to be more focused and ping the right people at the right time without unactionable noise.

Scaling up engineering is about finding ways to increase the total impact of the organization. For example: 

• Spin was put into place because of how hard it was to keep Shopify’s monolith and related services running locally. Côté says, “Keeping dependencies up to date slowly became a very large problem, frustrating developers and overloading our team with support requests.” By having individual, cloud-based systems that were already configured for use and quickly available, developers were able to stop fighting our increasingly complex app configuration.

Reducing cognitive overhead is about eliminating the number of decisions coders and managers alike have to make. This category has included projects such as: 

• Building a system that uses static analysis to identify and automatically remove dead Ruby code. “We're actually also building this into CI, so it fits with ‘tightening development feedback loops’ as well,” Côté adds.
• Simplifying their system that reports on completion rates for action items and degraded SLOs to “clarify the results and ensure they roll up to leadership so they can easily determine the engineering health of their organizations and make deliberate and informed trade-offs.” 

Today, the team focuses exclusively on projects that fall within these categories. The team identifies and prioritizes projects by surveying and speaking to developers. Their channels for collecting developer feedback include a quarterly survey, office hours sessions, and 1:1 interviews with developers. They also receive additional roadmap ideas from a separate team within their parent organization that provides direct support for their internal tools.

Guiding principles

The second component of the Developer Infrastructure team’s charter is a set of guiding principles. The guiding principles outlined below help define how their team should work and make decisions:

1. Maximize impact with effective two-way communication. “We have to talk to our users all the time,” Côté says, “both listening to their needs and communicating our solutions back to them. 

2. Pursue both incremental and big step-change improvements. Côté explains, “We have many services, and they all have rough edges, bugs, and missing features. While one of these services provides value, we'll continue to iterate on it. However, sometimes we need a significant alteration to the way engineering works; sometimes this is because we can't further scale a system, sometimes because we're getting diminishing returns on a solution, and sometimes because there's a new need or useful technology to leverage.”

3. Enable self-service by providing extensible platforms, information, green paths, and guard rails. The Infrastructure team can’t solve every problem for developers, so they try to build open and extensible systems that developers can build and extend on their own. This allows the Infrastructure group to concentrate on higher-impact work. 

4. Absorb complexity. Accelerating development requires reducing the overall complexity that developers face. “We take on some of this complexity for global simplicity,” says Côté. “Accordingly, we don't push any of the complexity of our systems onto our users. Sometimes this is a lot of work for our teams but saves our users more time and effort as a whole.”

In summary, although internal-facing teams focused on developer productivity may understand the value of their work, leaders of such teams still sometimes struggle to articulate this value to leadership and explain why they are prioritizing certain projects. If you're in a similar situation, you can look to Shopify's approach as a useful path forward: defining a team charter can help frame all discussions with leadership, ensuring that the value of a team's projects is properly conveyed.