Leadership

The operating model shift

When I joined HSE, design was a shared-service function: two designers serving multiple product managers, brought in after decisions were made to produce screens. Quality was inconsistent. Designers had no ownership of outcomes. Impact was invisible because no one was measuring it.

I changed the model. Designers moved out of the shared pool and into product squads, one designer per squad, accountable for that squad's outcomes. This sounds simple. It required significant organisational negotiation, a new hiring brief, a different onboarding process, and a complete change in how design progress was reported upward.

The result: designers went from executing requests to shaping decisions. From being called in late to being part of discovery. From producing output to owning outcomes. That shift is the foundation underneath every metric on the Impact page.

Three rituals that made the difference

I don't believe in process for its own sake. But three practices changed how the team operated.

Design critique: decisions, not aesthetics

Most design critique sessions I've seen are really feedback sessions: someone presents work, others say what they like or dislike. That produces polish, not better thinking.

I ran critique differently. The presenting designer had to open with the decision they were trying to make, not a summary of what they'd built. Feedback was structured around trade-offs: what does this option give up? What assumption is this testing? What would make this the wrong choice? This made critique a thinking tool, not a review gate.

Discovery kickoffs: earlier means fewer surprises

The most expensive design work is work done twice. Redesigns happen when designers are brought in after product decisions are already locked; they're designing around constraints they had no input into.

I pushed for design to be present at the start of every discovery, even informally. A designer at the kick-off catches scope problems, constraints, and user questions before they become expensive assumptions. This didn't require new processes, just earlier calendar invites.

Visual QA before release: the design veto

On revenue-critical journeys (checkout, search, product page), I introduced a design sign-off step before every release. Not a full redesign review. A focused 30-minute check against the approved design: does what's shipping match what was approved?

This reduced UI bug tickets by approximately 25% on high-risk journeys. More importantly, it changed the culture: engineers started flagging ambiguities earlier rather than making calls and hoping nobody noticed.

Usability testing: standing practice, not a ritual

Usability testing at HSE was not reserved for big launches. I introduced it as a regular part of how design teams validated assumptions before committing to a direction. The question driving every session: what do we need to know before we ship this, and what is the cheapest way to find out?

This meant small studies, run often, with clear decision triggers. Not every feature needed a full research sprint. Some needed five user sessions. Some needed one. The discipline was in knowing the difference.

Building and scaling the team

How I hire

I hire for judgment under constraints, not portfolio polish. A beautiful portfolio proves craft. It doesn't prove that someone can navigate a difficult stakeholder conversation, make a decision with incomplete information, or know when to stop exploring and start shipping.

The signals I look for in interviews:

• Reasoning about trade-offs: can they explain why they chose one option over another, and what the alternative would have cost?
• Calibrated confidence: do they know the difference between "I don't know yet" and "I've decided"? Both are fine. Confusing them is not.
• Collaboration fluency: how do they talk about engineers and PMs? Do they describe them as constraints or as partners?
• Evidence orientation: do they reach for data and user input naturally, or only when asked?

How I help people grow

The best feedback I give is during real work, not in a quarterly review. I run 1:1s as coaching sessions: what decision are you facing right now, what are your options, what would you need to know to choose confidently?

I calibrate how much space I give based on the designer's stage and the risk level of the work. Senior designers get broad direction and space to own the execution. Earlier-career designers get clearer support and more frequent check-ins, not because I trust them less, but because ambiguity without support is just stress.

Growth at HSE was tied to three things: demonstrated scope expansion, measurable impact on their squad's outcomes, and the quality of their reasoning in critique sessions, not time served.

How I onboard

The first 90 days for a new designer are not about shipping. They're about building the context that will make everything they ship afterward better. I structured onboarding around three things: understanding the business (how HSE makes money, what the critical journeys are, what "good" looks like numerically), understanding the users (joining research sessions before touching Figma), and understanding the team (how decisions get made, who the key collaborators are, what the failure modes of the current setup are).

Stakeholder management and C-level alignment

Design influence at HSE required more than good work. It required making design's contribution legible to people who do not think in design terms. I aligned directly with C-level stakeholders on the HELLO App, the 2020 rebranding, and the AI copywriting tool, translating design decisions into business cases and framing trade-offs in terms of revenue, risk, and speed.

This is not peripheral to design leadership. It is how design earns its seat at the table, and keeps it.

Culture

The culture I build is high-standards and psychologically safe, and I believe those are compatible, not in tension. High standards without safety produces people who hide mistakes. Safety without standards produces comfort without growth. Both are required.

• Decisions are argued, not postponed. If someone disagrees with a design direction, I want to hear it in critique, not in a Slack message after the fact.
• Mistakes are reported, not hidden. The faster a problem surfaces, the cheaper it is to fix. I try to make it clear that coming to me with a problem is better than hoping it resolves itself.
• Learning is structured, not accidental. At HSE, the team ran biweekly knowledge-sharing sessions, including hands-on AI sessions focused on day-to-day design work, and a design guild that covered customer journeys, affinity mapping, and design systems in depth.
• Impact is visible. Every designer knows how their squad is performing, what metrics they are influencing, and whether their work is moving the numbers.

Trust without micromanagement

Giving designers space is easy to describe and hard to sustain. The practical difference between trust and abdication is visibility: a designer I trust completely still needs to know I know what is happening.

In practice, this runs on three things. Shared tooling: design work lives in open Figma files, so I can see where something is stuck without asking. A culture where problems surface fast: flagging a blocker early is always the right move, and I make that explicit from the first week. And covering the team publicly: when a stakeholder pushes back on a decision, I defend it. Designers should not feel that taking a position puts them personally at risk.

Together these create the conditions for trust to work. Without them, you either micromanage or you learn about problems too late.

What separates good from outstanding

A good designer can solve problems. An outstanding designer can articulate why their solution is correct.

The craft part is necessary but not sufficient. What distinguishes senior designers is not the quality of their work in isolation. It is their ability to make the reasoning visible: to explain the trade-off they chose, name the assumption they are testing, and defend a direction with evidence when the room pushes back.

This is what I develop in designers who are ready for the next level, and what I look for when hiring seniors. Critique sessions are where that skill gets built: designers who can argue for their decisions under pressure learn to make better decisions in the first place.

When design gets bypassed

It happens. A PM commits to a feature without a design brief. Engineering ships a change without design sign-off. A stakeholder approves a direction in a meeting where no designer was present. The wrong response is to escalate in the moment. The right response is to have built the conditions where it rarely happens, and to address it structurally when it does.

At HSE, I set a small number of non-negotiable design checkpoints on revenue-critical journeys: checkout, search, product page. I made the case for them once, in business terms, and got alignment from product leadership. After that, the checkpoint was the process, not a request.

For everything else, I relied on proximity. Designers were in planning meetings. I shared work in progress with engineering leads before it was finished. Cross-functional design reviews were structured as decision inputs, not approvals. When people see design thinking early and often, the instinct to bypass it diminishes because it stops feeling like a gate and starts feeling like useful input.

Takeaway

I build design teams where quality is a habit, impact is visible, and designers are trusted to own outcomes, not just output.