In last week’s article, I advocated for people who don’t know how to code to still have an important role on design system teams. At first glance, that probably makes sense, but, in practice, it’s easier said than done. Most enterprise design systems focus the most of their time and energy on things that are code-related, like components and tokens; it’s difficult to be involved in the critical path of those without having at least some code prowess.

So: what else is in the critical path of design system work that non-coders can be working on?

First, let’s define critical path work. Esther Cohen of Workamajig explains the critical path as the “scheduled activities [that] must be performed if the project is to be considered a success.” A few years ago, I sat down to define what I think the critical path for design system work might look like. That turned into the Design System in 90 Days workbook, 52 activities that set a team up well for a sustainable design system practice. Of those 52, 32—more than half—can be done by someone who doesn’t know code.

In Breaking Down Design System Effort by Week, I outlined the average relative effort of work between 4 roles on a design system team within a 90-day time period:

• Engineer: 57%

• Designer: 47%

• Writer: 35%

• DesignOps: 59%

(Adds up to more than 100% because some activities are collaborative. Normalizing for collaboration, it shakes out like this:)

• Engineer: 32%

• Designer: 19%

• Writer: 11%

• DesignOps: 38%

It probably surprises no one to see that engineers are responsible for a significant chunk of design system work (about a third). I bet it surprises a lot of people to see that designers are only responsible for less than a fifth of design system work, and instead, DesignOps does should be doing more work than anyone. (As an aside, if your design system team doesn’t have an embedded DesignOps role, that might be a reasonable explanation as to why design system work feels more difficult than it should.)

Design system like a startup

The simplest explanation I can find for this is to think of a design system team as a startup, not a feature team. Design systems are products, so it stands to reason that you might model your team and process after the kinds of companies that build products in our world: startups.

66% of startups have a technical founder/co-founder. According to entrepreneur Rui Delgado, a technical co-founder for a product “will save you a lot of money when you're bootstrapping as well as making sure you deploy a great product as soon as possible.”

This is usually the point where design systems diverge. The next most obvious choice for a design system “co-founder” is a designer. That’s usually because the assumed next step is to crank out “foundational”—yuck—elements for other teams to use. Said differently, they think the thing to do is to build product. Especially if you think about a design system team like a feature team, of course the answer is product. What else is there to work on?

Turns out: a lot! Longtime venture capitalist Marc Andreessen explains in his post, The only thing that matters:

What correlates the most to success—team, product, or market? Or, more bluntly, what causes success? If you ask entrepreneurs or VCs, many will say team. If you ask engineers, many will say product. Personally, I’ll take the third position—I’ll assert that market is the most important factor in a startup’s success or failure. Why? In a great market—a market with lots of real potential customers—the market pulls product out of the startup. The market needs to be fulfilled and the market will be fulfilled, by the first viable product that comes along. The product doesn’t need to be great; it just has to basically work. And, the market doesn’t care how good the team is, as long as the team can produce that viable product.

Hubspot CEO Yamini Rangan seems to agree in her advice on go-to-market strategy:

The paradigm used to assume that everything in sales had to be about the product or the brand. In fact, buyers make decisions based on the seller—their interactions with the seller, the whole sales process, and the experience of that process. The trend of companies switching gears to focus on how they sell as much as what they sell has driven a much greater focus on really understanding the customer—not just who they are and what they need, but also how they want to buy.

In my experience with design system work, you have to work on all three—team, product, and market—but there’s definitely a pattern in how the most successful design system efforts have structured their hierarchy of focus:

1. Market

2. Team

3. Product

The teams that focused heavily on their market even at the expense of their product did just fine. The teams that focused heavily on their product at the expense of their market created design system ghost towns and graveyards and ultimately got defunded and reallocated.

My advice? Allocate 2 engineers and a designer on your design system team to building the product and everyone else to helping you find product/market fit. The latter is the real critical path of design system work.