BUILDING A DESIGN DEPARTMENT'S OPERATING MODEL

I turned a platform rebuild in chaos into the operating system a whole design department runs on

Cross-Functional InfluenceDesign LeadershipDesign QualityScaling and Transformation
Summary

Goal: turn a design function running on heroics into a department that delivers predictable quality and can scale

Task: I came into platform redesign chaos and built the rituals and methods design runs on, moving on-time delivery from 55% to 79%. This system became the operating model a department (3 divisions) still uses today.

Two levels:

  1. The high-level rituals for a department

  2. The rituals/methods used in the Feature Development Lifecycle.

1. High-level Department Rituals

What are the specific rituals?

Recruiters: Jump to Scope & Role Info

55% -> 79% On Time

Predictable delivery of committed scope across 5+ squads

~25% Less Rework

Clarity removed design-to-dev rework

4 of 8 Promoted

Direct reports up-leveled or advanced (in a turnaround with 3 org reductions)

Departmental Adoption  

Adopted by 3 design divisions (still running a/0 2027)

Our Operating Goal: NO SURPRISES

  • Clear, shared priorities
  • Just enough system
  • Principles & process are embedded in the artifacts

2. The tactical-level rituals/methods in the Feature Development Lifecycle

The immediate problem

*Drag the center divider left or right to compare the before and after
Before After
*All activities are representative, not exhaustive

Project Summary:

  • The Ask: level up a design division so “design moves faster”
  • The Problem: design was pulled in at build time; no shared operating model; every squad did things their own way
  • The System Fix: quick, high-value rituals and methods first, under fire; –
    • Later: polished into a best-in-class operating system
  • The Output: the feature design cycle’s rituals and craft standards, from critique and gates to hypothesis-first design
    • Later: Best-in-class departmental OS and a cross-org upskilling program
  • The Outcomes: on-time delivery 55% to 79% | rework and blockers each down 25%
    • Later: Operating system adopted by all three divisions | still used today

Company Context:

Pluralsight is a multi-sided enterprise learning platform

  • ~500,000 active learners
  • ~$400M ARR
  • ~1,900 employees
    • A design department spanning three divisions
  • My Team: 5+ delivery squads, product-area scope 6 to 12 product surfaces
Problem
The Problem

Problem: design was relegated to a tactical implementation function only, with each squad running their own processes.

Operating Context: Third year of a turnaround, so no added headcount and three org reductions in the past. One of three design directors under the VP of Design. Partnering with five division leaders and 6 to 12 delivery teams across engineering, design, and product.

Design delivery ran on heroics

  1. Design pulled in at build time, not at planning
  2. On-time delivery stuck at 55%
  3. Rework and cross-team blockers eating lots of capacity

No shared way of working

  • Each squad has its own cadence and quality bar
  • Design department (3 divisions) couldn’t improve as one
  • No common path for growing skills

1 Designer: 3 Dev Teams

  • Working with an outside offshore engineering consultancy
  • Design to dev ratio at 1 designer:~30 developers, or 3 dev teams for each designer
(Ask me about guiding a last-minute engagement with offshore engineering consultants)

“I feel so stupid about missing this deadline – this [first] team does things completely different from [the second] team and certainly is more lax than [the third team]. I’m so confused all the time.

Also – shouldn’t someone have caught this in the meeting last Thurs – the one that should have been but wasn’t a sprint planning meeting? I don’t think this team even has planning – I know they don’t have stand ups. How is anyone supposed to know what anyone is doing or should be doing?“

– Slack message from a designer

What could have failed, and why was this mine to lead? (click for more)

I got my boss’ buy in to create an operating system that all of design could use, using my own squads as a test to prove the value. But focusing on ‘standardization’ does have risks.

  • Creating processes only my own squads could use risked looking like the bottleneck.
  • Standardizing across squads, divisions and cross-functional partners, with true buy in, is a difficult change-management challenge. In a turnaround, it takes time away from the fires we’re putting out.
  • Designers and squads were stretched thin – would processes be more work for them?

I was the right leader for the job because I’ve built and rebuilt design functions before, so I had the frameworks, playbooks and models. I could – and did! – prove the model worked with my own squads.  My craft standards were what the VP of Design, our designers, and our partners wanted.

I believe a big part of my job is to help create the systems that enable people to do their best work.

Playbook
The Playbook

Playbook: I quickly fixed delivery with high-value rituals and set craft standards inside my division, proved it worked, and then did the hard work of advocating for a coherent system across the company

What I Did

  1. Fixed delivery first (and under pressure)
    1. Scope the rituals and methods into a cadence that fit our capacity
    2. Set best-practice craft standards
    3. Use my team as example of outcomes
  2. Developed best-in-class departmental operating system
    1. Rituals on a predictable cadence
    2. Institute systems to develop designers
    3. Change management aligned disparate squads into a unified operating model

Tradeoffs: At what cost?

Who made a change, and what did it mean to them?

  • IC designers:
    • Start with hypothesis-based design, quickly communicating purpose (vs start anywhere)
    • Lo-fi, messy work shown early for feedback (critique is a core competency of designers)
  • Senior designers: Institute readiness gates and a unified quality bar (elevating them with important mentorship opportunities)
  • Cross-functional leaders & all squads: Their own processes, cadences and quality bars replaced with a shared system

High-level Department Rituals:

The tactical-level rituals/methods in the Feature Development Lifecycle:

How did I keep quality from slipping while standardizing across people I didn't manage? (click for more)

For the initial processes and rituals:

  • Co-created the delivery rituals based on our actual capacity balanced with desired outcomes.
  • Collected metrics to prove the impact
  • Cross company alignment (change management) and voluntary standardization

In addition, I recognized the vulnerability of learning and applying radically new skills in a company already running org reductions.

  • I rewarded learning over polished demos
  • I kept track of and addressed the human concerns
  • Managers/ Staff designers, product, and engineers were enabled and trusted, so they functioned as strong partners in the adoption work

Results
The Results

Results: The operating system took on-time delivery from 55% to 79%, cut rework and blockers 25%, advanced 4 of 8 of my reports. Today, this system is run by the director I developed.

Outputs:

The department's ritual operating system

A library of different methods (grouped by outcome)

A competency ladder plus peer calibration

A cross-org upskilling program (Skillcraft) with OKRs and a franchise playbook

Outcomes:

Voluntary cross-org adoption of the upskilling program (Skillcraft)

On-time delivery 55% to 79%; rework and blockers each down 25%

Adopted across the department (three divisions) for all projects

4 of 8 direct reports promoted

I don't know how you knew what we needed, but I'm glad you jumped in right away.

The processes we have now are so much better than the chaos we had before. I know it was hard work to get everyone on board, but it's so worth it.”

– M.S, Offshore consultancy partner

Current Status (a/o Q4 2026)

  • The ritual operating system is still how the department works.
  • The director running it is someone I developed and promoted.
  • The rituals and methods are documented and in use, so the team can spend its time on the most important work.
How do I use my own assignments as a way to upskill designers & design leaders? (click for more)

I build senior capability by handing people the work one level above them, with cover.

  • Several senior designers stepped up to mentoring our jr designers, extending our capacity greatly and proving their Staff skills
  • The design-system lead became the in-house expert and built reusable systems the rest of the department adopted
  • A director, once a manager I developed, now runs the design department

Lesson
The Lesson

Lesson: I couldn't order cross-functional teams to standardize, so I fixed my own team's pain and built a scalable system people could easily opt into

What do you do when you don’t have the authority to require cohesion?

The Constraint: no cross-company mandate to standardize

  • No buy-in from the company, just a lot of chaos and confusion
  • It’s risky to ask for people’s time on operating-model work in a turnaround, on my boss’s priority alone

What I did instead: proved it worked and made it scalable

  1. Fixed the immediate delivery pain first, with my own team
  2. Gathered metrics and proof this was better
  3. Good change management to get buy-in
  4. Created rituals and methods that I know were valuable and could scale
  5. Make the system cheap and easy to adopt

How I knew it worked: The other two divisions adopted the operating system without being told to, and the director who replaced me still runs it today.

Project Information

Cross-Functional Influence Design Leadership Design Quality Scaling and Transformation

Building a Design Department’s Operating System

Building the operating system a design department runs on. The Proof: adopted by all three divisions, and still used today.

  • Design

    Built and run across the platform rebuild, 2024 to 2026

  • Client

    Pluralsight. B2B SaaS, EdTech. ~ 1,900 employees.
    PE-backed, in stabilization.

  • My Role Then

    Director of Product Design, then Director, UX Product Design and Research. One of three design directors under the VP of Design.

  • Scope & Span

    5+ delivery squads, product-area scope 6 to 12, across a three-division design department.

  • Team & Reach

    15-person org (8 direct, 2 managers). One of 3 divisions under the VP of Design. Delivery done in pods.

  • Platform Type

    B2B SaaS, multi-sided (Enterprise admin, individual learner, internal authoring)

  • Status (a/o Q4 '26)

    The ritual operating system still runs the department, under the director I developed.

  • Tags

    Change Management, Governance, Operating Model, Team Capability, Transformation

Back
Next Project
Post-Merger Product Unification