SixFifty · 2026

Design Team Structure

Our VP of Design left the business and the role was never backfilled. I mapped what he'd been carrying, then designed the org that could carry it without him.

Tags
Team · Career Ladder · Process

Overview

Nobody asked me to redesign the design org. Our VP of Design left the business, the role was never backfilled, and the work he’d been doing quietly landed on whoever noticed it. I mapped what he had actually owned, wrote levels that defined scope instead of seniority, and modeled how the whole thing held up as the product org grew. The structure I drew was never adopted. The argument underneath it was.

The problem

I wrote the problem statement first, before any boxes and arrows, because I wanted to be sure I was solving the right thing.

As SixFifty’s product org grows, we have no shared definition of what designers own, how they level up, or how design quality gets maintained across teams.

All three of those were true and none of them were anyone’s job to fix. There were two designers. Both of us were assigned to “multiple” product areas, which is a polite way of saying nobody had drawn a line. There was no ladder. There was no answer to “what would it take for me to get promoted,” because there was nothing to be promoted into.

The gray boxes

The first thing I did was map the org as it actually was, not as the org chart claimed. CEO, Head of Product, and under that a Senior Designer and a Mid Designer. Another designer and me.

Then I drew a box off to the side and labeled it with our former VP’s name. Inside it I put the three things he had owned:

Sets design direction and process for the full app. Accountable for quality and consistency across the app. Reviews and coaches other designers.

Then I put a question mark on each one. Not rhetorically. Those three responsibilities had no owner, and had not had one for months. Some of them I had picked up by default. None of them were in my job description, my title, or my comp.

That box was the whole argument. I didn’t have to make the case that we had a problem. I just had to show people the gray boxes and let them sit with it.

Sets design direction and process for the full app.

Accountable for quality and consistency across the app.

Reviews and coaches other designers.

No owner. For months.

Those gray boxes finally have an owner.

Levels that describe scope, not seniority

Most career ladders I've seen describe how good you are. I wanted ours to describe what you're responsible for, because that's the thing people actually argue about. Every level got the same five dimensions: how many product areas you hold, how much autonomy you have, what you do with the design system, what you do with research, and whether you coach.

CEO
Head of Product

Designer

1 product area

Works independently in a defined scope.

Sr. Designer

1–2 product areas

Works cross-team; owns strategy and research in their areas.

Principal Designer

0–3 product areas

Accountable for quality and consistency across the whole app.

Not management

All three report to Head of Product. Principal holds scope, not reports.

Designer

Product areas
One
Autonomy
Works independently in a defined scope. Executes a defined strategy.
Design system
Contributor, with explicit review.
Research
Helps with user research in their area.
Coaching
Not yet

Sr. Designer

Product areas
One to two
Autonomy
Works cross-team, often exceeding scope. Partners with their PM on strategy and roadmap.
Design system
Contributor.
Research
Owns user research in their area.
Coaching
Reviews and coaches other designers.

Principal Designer

Product areas
Zero to three
Autonomy
Partners with the SVP on strategy and roadmap for the app. Not management.
Design system
Owner. Look, feel, and function of the app.
Research
Leads user research site-wide, partnering with the designer in each area.
Coaching
Reviews across the whole app. Accountable for quality and consistency everywhere.

The part I put in capital letters

On the Principal row of the board there’s one cell I wrote in all caps.

NOT MANAGEMENT.

That was deliberate and it’s the load-bearing decision in the whole proposal. The gray boxes needed an owner, but the answer to “who owns quality across the app” should not automatically be “let’s add a manager.” We were a two-person design team inside a growing product org. Adding a layer of hierarchy would have solved a coordination problem by creating a political one.

So Principal got the scope without the reporting lines. Accountable for the app, not for performance reviews. One of the explicit goals I listed was “no new hierarchy as far as management goes.” A senior person can hold a quality bar without owning anyone’s salary.

I also mapped how each level spends its time, as rough proportions rather than percentages I’d have to defend. A Designer is mostly team tickets. A Senior splits between tickets, strategy, the design system, and research. A Principal’s ticket load shrinks and the rest fills with design system, coaching and review, strategy, process and design ops, and research. The point of showing it that way was to make the tradeoff legible. If you want someone holding the quality bar across six teams, you have to accept that they are not also shipping six teams’ worth of screens.

Designer

Sr. Designer

Principal Designer

  • Team tickets
  • Design system
  • Strategy
  • Coaching & review
  • Process & design ops
  • User research
  • Product research

Hands-on ticket work is most of a Designer's week and a minority of a Principal's. If someone is holding the quality bar across the whole app, they are not also shipping the whole app's worth of screens.

Planning for the org we were about to become

The other half of the board is capacity modeling. I ran three growth scenarios and mapped several coverage options against each, so the conversation could be about tradeoffs instead of vibes.

4 teams, 3 designers

Workable. Two coverage options, both with full coverage and no one stretched past two areas.

6 teams, 3 designers

The squeeze. Every option leaves someone holding three product areas or leaves a team uncovered.

6 teams, 4 designers

Four options, and the only scenarios where the quality bar survives growth.

This was the part that made it a business document instead of a design opinion. I wasn’t asking for headcount because I wanted a bigger team. I was showing the specific point at which the current team stops being able to hold the product together, and what it costs to get past it.

What I was actually proposing

The proposal came down to three things, and each one had to earn its place.

Define the roles

A shared language of scope, growth, and accountability. Clear criteria for hiring. No new management hierarchy. And a model that could extend past design to PMs.

Create hierarchy

Formalize the Principal role. Someone to create and hold design process. A single voice for consistency across the app. The gray boxes finally get an owner.

Plan for scale

Full design coverage across every team. No designer spread too thin. A proactive plan instead of a design quality crisis we’d be reacting to in six months.

Built to extend past design

“A model that could extend to PM’s” was on the board from the first draft. That wasn’t an accident someone noticed later. It was a design constraint I set for myself.

The reason is simple. If the ladder only works for designers, it’s a design artifact and it dies in a design meeting. If the dimensions are general enough that product can pick them up without translation, it becomes how the company thinks about scope. So I wrote the levels in terms of product areas held, autonomy, and accountability rather than anything craft-specific. Nothing in the structure depends on the word “design.”

To be clear about what that is and isn’t: it’s a property I built into the model, not something that happened. Product never picked it up. I’m including it because the constraint changed how I wrote the levels, and I think writing them that way was right whether or not anyone took me up on it.

What was actually hard

The second draft is where it got uncomfortable, because I moved myself.

In the first version I’d put myself in the Principal seat. In the revision I added a Product and Design Ops role and proposed myself into that instead: owner of Pendo and insights, orchestrator of the design system, site-wide research, a seat on the product and HRBP advisory boards, and building the process that would let PMs push to production and design push design system changes to production.

Writing yourself into an org chart is an uncomfortable thing to do twice. The first time you’re arguing for a role. The second time you’re admitting the first one wasn’t where the leverage was. Neither seat existed when I started and neither one exists now. I’m still a Lead Designer.

The current state

Where it is now

The structure was never implemented. None of the levels I wrote are in use, and the capacity model didn’t drive any hiring decision I can point to.

What did happen is that the company hired a design leader. The three responsibilities I’d drawn question marks around have an owner now. He’s building his own structure, which is what you’d want a new leader to do, and it doesn’t look like mine.

I’ve thought about whether that makes this a failure. I don’t think it does, but I also don’t want to spin it. The diagnosis was right. The company acted on the diagnosis. My specific solution didn’t survive contact, and the honest reason is that I built it as a document when I should have built it as a coalition. I knew that lesson already. When I pitched the design system, the thing that turned leadership wasn’t the pitch, it was a group of engineers volunteering their own hours to help. I didn’t do that work here. I made the argument and waited to be told yes.

That’s the part I’d do differently, and it’s the reason I’m putting an unadopted proposal in a portfolio. The thinking holds up. The politics is where I got beat, and I’d rather say that than pretend the story ended somewhere it didn’t.

The design system is the other half of this story. That one is about what I built. This one is about how I got permission to build it. You can read it here.

Next case study

Design System

Nobody asked for it. I had to fight to build it. 50+ components with full token architecture, and every feature now ships on it.