Compared to other companies of the same size Shopify’s engineering is surprisingly effective. They’re better than most at prioritizing work, keeping track of what is being done, and killing things that aren’t impactful.

An important reason for this is the way all work is defined in clear projects and made visible to the rest of the company with a goal and a timeline. This is a standardized process, with an internal tool to manage it, but it’s a very light process. It’s an interface to the rest of the company that defines the who, what, why, and when, but not the how.

Most work is planned by defining a “project”, which has a goal, and a rough timeline. The project has a “champion” and other members who are typically focusing only on that project. Within the project the team can manage the work however they like.

This works because it:

1. Limits “work in progress”, forcing focus on shipping one important thing at a time.
2. Provides visibility into the work.
3. Forces all work to have a goal.
4. Provides timeline accountability.
5. Decentralizes project management by delegating some responsibility to a project champion.
6. Provides complete autonomy to the team for everything else.

Let’s examine those in detail.

1. Limiting work in progress

Focusing on “flow” is one of the most impactful concepts in project management. This means putting all available resources toward one thing at a time until it’s done. Of course there’s a limit to this, not all tasks can be partitioned (said more humorously, and famously, by Fred Brooks as “the bearing of a child takes nine months, no matter how many women are assigned”).

But the optimal strategy is to focus as many people as possible on shipping one small thing before moving on.

There is great analysis on this by Will Larson and Lucas Costa.

2. Providing visibility

Leadership can see everything the teams in their organization are proposing to do before it starts, and approve or redirect the effort. And it’s clear at all times what goals the company is working towards, which helps make more informed decisions about where to pull resources from if needed.

Others in the company can also see the projects that are being proposed, which helps avoid duplicated effort or doing something that’s locally optimal (for the team), but globally sub-optimal (for the company). And it helps interested people across the company share their expertise (or occasionally just uninformed opinions, but that’s a small price to pay).

3. Forcing work to have a goal

All work has a clear purpose, and a lack of purpose or misalignment is more visible. This helps make sure effort is going toward something valuable in the big picture, and avoids the treadmill of just pulling things from a backlog sprint after sprint. And having a goal gives something to celebrate when it’s achieved.

4. Timeline accountability

Teams usually have rough goals for when they’re going to ship something. But having it visible for all projects across the company is a game changer.

And it’s important to have an expected timeline up front when deciding to start a project. Everything we do is to achieve a business goal. Whether explicitly or not it has a budget, and probably an expiry date where it’s no longer impactful enough to be worth it.

Keeping both the time goals and business goals visible (and top of mind together) encourages decisions with more options when things go wrong, such as changing scope.

(We can also go one step further and start with the timeline, like Shape Up’s concept of appetite before we get too invested in a particular solution, but that’s a subject for another day.)

5. Project “champions”

Typically engineering managers and product managers wonder how they’ll manage multiple projects that are being run separately. Does it mean multiple project boards and planning meetings? That sounds hard to manage… but managers have an important tool: delegation.

Projects have a “champion”. This can be the PM or EM, but is most often an IC (individual contributor, AKA an engineer or designer on the team). It’s often someone who cares a lot about the particular project for some reason, and they’re the person who does whatever is needed to keep the project on track. Apple made the concept of the directly reponsible individual (DRI) famous, and when done well it’s exactly this.

It’s also one of the best tools for allowing people to practice and demonstrate leadership.

EMs and PMs will of course be there to guide and ultimately manage the projects, but having one of the team as a champion does more than just scale the managers, it empowers the team.

6. Complete autonomy within projects

This is standardizing at the right level, it forces all teams to have a standard but very light interface with the rest of the company, while leaving the implementation details up to the team.

Teams can use whatever process they like to manage each project. You’ll find lightweight agile or occasionally no process at all, but you won’t find a heavyweight process or even strict Scrum (as expected in the best tech companies). If the team’s process isn’t working then it’s clearly visible and a conversation about it can occur.

Shopify always resisted adding a lot of process, and one of the Tobi quotes that I will always carry with me is to make process “a floor, not a ceiling”, meaning that good process provides a lower bound to how well something can be done, but does not impose an upper bound. If a process can interfere with finding a better way than the standard, then it’s a bad process.

What it’s not

There are a lot of bad project-oriented ways of working. In this context it doesn’t mean splitting up and re-forming teams (although it may have long ago in Shopify’s history, and “missions” at Shopify are a topic for another day).

A team remains a cohesive unit, with ownership over a constant product or feature. Some of them will be focusing on different projects at different times, but they should be relatively short-lived and so team members generally all get a chance to work with each other on different projects. As the book Team Topologies puts it:

The other common anti-pattern is shuffling team members. This leads to extremely volatile team assembled on a project basis and disassembled immediately afterward, perhaps leaving one or two engineers behind to handle the “hardening” and maintenance phases of the application(s). While there is a sense of higher flexibility and a perceived ability to respond faster to deadlines, the cost of forming new teams and switching context repeatedly gets overlooked (or is unconsciously factored in the project estimates). A computer will perform the same whether it is placed in Room A or Room B, but an engineer placed on Team A may perform very differently than if placed on Team B.

Summary: who, what, why, and when, but not how

Defining work in terms of projects, when done right, is a lightweight interface to the rest of the company, making all work and goals visible, but allowing autonomy within the project. Resist the urge to overdo the tooling and process. Keep it simple!