What Gets Built vs. What Ships

There’s a version of design leadership that’s mostly about craft — hiring well, reviewing work, raising the bar on visual quality. That part matters. But the design orgs I’ve seen fail weren’t failing on craft. They were failing on agency: designers who had good ideas but no ownership of whether those ideas reached production, teams who did thorough research but couldn’t protect the findings when priorities shifted, functions that produced strong deliverables but let other parts of the organization take credit and move on.

The design org problem is a political problem as much as it’s a design problem. Getting it right requires being deliberate about three things at once: who you put on the team, how you build the operating process, and how visibly the function advocates for its own work.

How I Hire

My bias in hiring is consistently toward eagerness over credentials. A designer with a strong portfolio from a major technology company and a polished interview isn’t automatically valuable — often they’ve been one node in a large machine and have more opinions about process than experience making hard decisions with real constraints. A designer who is newer, genuinely excited about design as a discipline, and willing to learn is often a stronger investment. They’re building habits rather than carrying them.

What I look for in a portfolio is decision-making evidence: not just what something looked like, but why it looked that way, what was considered and rejected, and how constraints shaped the outcome. Communication style matters as much as the work itself. Someone who can explain their choices clearly in an interview is someone who can defend them in a product review, which is ultimately where the work lives or dies.

The body of work, how someone talks about it, and whether they’re genuinely curious about design — those three things predict performance better than experience level or employer pedigree.

How I Inherit

I’ve always inherited teams before I’ve built them from scratch. The instinct at a new Director job is to assess and restructure. The better instinct is to learn first.

With each person I inherited, I started with two questions: what do you do best, and what’s frustrating you? The answers to those two questions together usually tell you everything. The strengths tell you where to give someone ownership. The frustrations tell you where the organization is blocking good work — and fixing those is often the fastest way to earn trust and improve output simultaneously.

The hardest part of inheriting a design team isn’t the design itself. It’s the habits. Designers who have worked in organizations where their work gets overridden without explanation, where requirements change after sign-off without consultation, where their name doesn’t appear on the things they made — those designers have learned to protect themselves by not owning anything too firmly. That’s rational behavior in a bad environment. Changing it requires demonstrating, consistently and over time, that ownership is real and that the function has standing to defend its decisions.

The Operating Model

One framework I’ve returned to consistently when diagnosing design org problems is the Danish Design Centre’s Design Ladder — four steps that describe how design is positioned relative to the organization: Non-design (not applied systematically), Design as Form-giving (used for styling), Design as Process (integrated into the development lifecycle), and Design as Strategy (a key element in how the business makes decisions).

Most companies I’ve joined have been at Step 1 or 2 — design either not applied systematically, or used mainly as styling on top of decisions already made. The operating model work at each company has been about moving to Step 3: design as an integrated function in the development process, with its own research track, its own documented reasoning, and genuine ownership over product decisions. Step 4 — design as strategy — requires organizational conditions that take years to build and C-level sponsorship to sustain. The realistic target is Step 3 done well: design embedded early enough to shape what gets built, not just how it looks.

Across every team I’ve built or led, the operating model has been a variation of the same dual-track structure: a discovery track running ahead of the delivery backlog, and a delivery track where validated work moves into engineering cycles. The two tracks give the team a way to invest in the future without interrupting the present — designers can be running research and concept experiments while simultaneously supporting engineering delivery on previously validated work.

The discovery track is where the design org generates its credibility. Research findings, tested prototypes, and documented decisions made in discovery are the artifacts that give design a defensible position in product conversations. Without that track, design is always reacting — responding to requirements that engineering or product has already committed to rather than shaping what gets committed to in the first place.

The scenario and prioritization work shown above is what discovery produces in practice: structured documentation of who needs what, how often, how severely, and what the potential product response looks like. That kind of artifact changes the character of a roadmap conversation. It’s harder to move the goalpost on a product decision when the reasoning behind it is documented, customer-grounded, and visible.

SecureAuth — Foundation Before the Org

The operating model work at Cylance and BlueVoyant had a predecessor, but not a predecessor team. At SecureAuth I was the first designer and front-end developer — later Sr. Product UX Architect, Engineering — and eventually directed additional UI designers and front-end developers while personally owning UX architecture, AngularJS implementation, SDK contracts, and native mobile design across iOS, Android, and Windows. There was no design org to inherit when I started. The work was breadth: too many projects shipping in parallel to stay in a single-track discipline.

That period established the instinct this essay later formalizes — design embedded early enough to shape what gets built, with enough technical credibility that engineering and sales engineering treat design output as production input, not a polish pass. The SecureAuth case study covers the product foundation; what follows at Cylance is where that instinct became an operating model others could run.

Cylance — What the Operating Model Looks Like in Practice

The dual-track model wasn’t invented at BlueVoyant. The version I’ve described above was first formalized at Cylance, where the discovery and delivery tracks ran in parallel across a team that was simultaneously building an enterprise SOC console, a consumer antivirus product, and a design system to support both. The enterprise console case study and Home Edition case study cover what shipped; this section covers how the org learned to deliver it.

The designer-to-developer relationship was documented explicitly — not as an org chart but as a workflow map showing how requirements moved from definition through design, into the design system, and through to engineering implementation and QA. The purpose of making that explicit was the same as documenting any other process: to make the friction points visible and give the team a shared language for talking about where handoffs broke down.

The most honest summary of what the design org achieved at Cylance in three years was captured in the project retrospective as a single phrase: Design Inclusion. Not “we shipped a design system” or “we improved handoff time by 33%” — both true — but that design was embedded in the product lifecycle as a structural partner. That’s the outcome that makes everything else possible: research findings that influence roadmaps, design decisions that don’t get overridden without evidence, and a team that has standing to push back and be heard. Getting there at Cylance required starting from scratch, establishing process before product, and consistently making the design org’s work visible to the parts of the organization that needed to understand its value.

BlueVoyant — Operating at Scale Across Product Lines

When I joined as Director, Product Design, design output had been outsourced — UI work arrived when Engineering or Product needed it. There was no systematic approach to how services became products, design maturity was low, and teams were structured to deliver against siloed objectives. Leadership brought design in-house to facilitate digital transformation: unify a fragmented portfolio, reduce redundant work, and give customers self-serve products instead of operator-dependent surfaces. My mandate was agency — standing, process, and visibility for design as a structural partner.

BlueVoyant was the most organizationally complex environment I’ve applied that model in. Three product lines — MDR, Supply Chain Defense (managed risk), and digital risk protection — each with its own engineering team, PM, and conventions. Designers were embedded per line with no natural center of gravity. Getting consistent work from a distributed team required building the operating model from scratch. The unified portal case study covers what shipped; this section covers how the org learned to deliver it.

The first problem was tribal knowledge — each product line’s designers understood their own product deeply and the others barely at all. The weekly cross-functional working session became the primary mechanism for breaking that isolation: a standing meeting where each squad brought current work, open questions, and blocking decisions. Over time, patterns that had developed independently in each product line surfaced, got compared, and either got reconciled into shared standards or documented as intentional divergence.

The harder problem was the PM dynamic. Each product line PM was managing their own sprint commitments, their own stakeholder relationships, and their own roadmap. Any cross-product design work was structurally nobody’s priority. Moving through that required consistently framing cross-product decisions in terms of customer outcomes PMs already cared about — not design coherence, which they didn’t — and using the research program as the standing evidence base for why those outcomes mattered.

The cumulative flow chart above is an artifact I wouldn’t usually include in a portfolio — it’s a Jira throughput diagram, not a design deliverable. It’s here because it shows something the case studies don’t: a design org that went from roughly 50 tracked items to over 200 in 18 months, across three product lines, without a meaningful increase in headcount. The volume growth reflects the operating model working — more work in the discovery track, more visibility into what was in flight, fewer decisions being made by individual designers in isolation.

The outcome framing I’d put on BlueVoyant from a design org perspective: I didn’t build the team, I built the conditions under which the team could do consistent work at scale. The dedicated front-end engineering team, the cross-functional rituals, the shared researcher, the design team charter, and DesignOps to maintain the design system — those were org design decisions. Customer research with client account teams and service operators gave those rituals a grounding in how services actually worked. The UI Guidelines made the output legible across squads. Together they gave design the agency the role was created to establish.

The Failure Modes

Design orgs fail in predictable ways, and most of them aren’t about design quality.

The most common failure is invisibility: a team that does good work but doesn’t actively promote it, doesn’t create organizational moments where the work is attributed correctly, and doesn’t build the relationships that give it standing in cross-functional decisions. Good design that nobody can point to becomes a cost center. Good design that’s visible and credited becomes a competitive advantage. Those are the same deliverables. The difference is whether the design org is treating its own work as a product to be communicated or as a service to be delivered and forgotten.

The second failure is a process failure: research and design investment that becomes obsolete when leadership changes or priorities shift. This is partly unavoidable — organizations change, and design has to adapt. But teams that don’t document their reasoning, don’t make their decision trail visible, and don’t maintain stakeholder alignment through their process have no protection when the goalpost moves. The work disappears without a record that it happened, and the next iteration starts from zero.

The third is structural: designers who don’t have genuine ownership of their decisions. This produces a particular kind of mediocrity — teams that execute competently but never push, because they’ve learned that pushing doesn’t change outcomes. The fix isn’t motivational. It’s organizational: design needs enough standing to say no, to require evidence before requirements change, and to be the accountable voice for user experience decisions in the same way engineering is the accountable voice for technical decisions.

When Engineering Builds Ahead

The scenario that tests every design org is when engineering gets ahead of design — when code is being written against requirements that haven’t been fully designed, or when features ship in states that design would have changed if it had been consulted.

The reactive response is to call a stop, which rarely works and damages relationships. The more durable response is to become a helpful steward of what’s already in production: acknowledge the reality of what shipped, identify the highest-leverage improvements, and make the case for them in terms of customer outcomes rather than design principles. That’s not capitulation — it’s the recognition that design’s value in that situation is expertise and forward vision, not aesthetic correction.

The harder and more important work is structural: ensuring that design is in the room early enough that it doesn’t get lapped. That means being present in sprint planning, in requirements reviews, and in the conversations where scope is set — not as a gatekeeper but as a contributor whose early involvement reduces rework for everyone. The design org that earns that position through demonstrated value doesn’t get built ahead of very often.