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.

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.

One practice I kept consistent: every designer had a clear picture of what the next level looked like for them specifically, and I maintained a standing view of where each person was against it. Growth conversations happened in the work, in critique sessions, in 1:1s, not saved for a formal annual review.

When a designer was ready for the next level, I made the case. In years when company-wide salary increases were limited, I built specific, evidence-based arguments for individual promotions and got them approved. One designer joined as a junior and reached senior over several years. That progression required deliberate coaching, documented milestones, and persistent advocacy with HR and leadership. It did not happen by default.

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).

Before any of that, I asked new designers to do one thing: become the customer. Buy a product on HSE. Use their own credit card. Wait for the confirmation email. Track the delivery. Unbox it. Most of the team would never shop at HSE on their own. Without that, their instincts would be shaped by looking at screens, not by what the journey actually feels like. The audit they wrote afterward became the entry point for almost every meaningful product conversation we had in those first weeks.

Guardrails, not a blueprint

Once the design system was running, I assigned two designers as captains: they accepted or declined component proposals from designers and front-end developers, monitored transgressions across the org (the team called it the "UI police"), and trained colleagues on the rules. They had genuine authority and my complete backing.

My role contracted to one standing slot: bi-weekly numbers in a stakeholder session, keeping the initiative visible and the case for it alive. The rest belonged to them.

I could have stayed more involved. I chose not to, because ICs are not there to produce a miniature version of me. If I expected them to solve problems the way I would, I would be frustrated constantly and micromanaging constantly. What I trust is the outcome, not the method. I watch the data to understand the impact of their decisions and step in only when the numbers require it. My job is to create the guardrails that let designers shine, not to define what shining looks like.

The system ran well while the right people were in place. When key front-end champions left the company, compliance weakened and inconsistencies crept back into implementation. What amplified the problem was structural: there was no engineering leader at the time. All developers reported directly to the ecommerce director, and with no one positioned to own the discipline within the dev team, the vacuum had nothing to fill it. The culture around the system eroded faster than the system itself.

Recently, an engineering lead was hired for the first time. That changes the recovery. I now have a structural partner on the dev side, someone who can hold the team accountable from within, rather than relying on informal champions. The revamp is in progress.

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.

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.
• Designers are covered publicly. When a stakeholder pushes back on a design decision, I defend it in the room. Designers should not feel that taking a position puts them personally at risk.

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.

Navigating the organisation

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.

Influence without authority: one Discovery process for every team

Across the digital product teams, every designer worked a different way. When it worked, it worked by luck. When it did not, ideas reached development without validation, and design paid for it in rework. The problem was not mine to fix on paper. I did not manage the product lead, the engineering leads, or the agile coaches. I decided to fix it anyway.

I proposed one shared Discovery process, built on the Double Diamond: validate the idea and align on the problem before anyone builds. The framework was the easy part. The real work was getting peers who did not report to me to adopt it. I earned my director's backing first, then took it to each lead on their own terms, framed around their pain and not mine: less rework for engineering, earlier alignment for product. We built the roadmap together, with designers, PMs, and developers in the room, so it belonged to them, not to me.

My role was to see the problem, make the case, and then step back. The teams made it theirs. Validation now comes before development across all of them.

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 current 2026 site redesign, securing approval for each initiative and presenting progress at each stage 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.

Vision

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

The hire is the highest-leverage decision

Every other leadership decision is bounded by the quality of the people in the room. That is why I treat hiring as the most important thing I do, and why I built the entire process at HSE from scratch: the brief, the portfolio review, the exercise format, and the debrief structure. Getting a hire wrong costs far more than the search time. Getting it right creates leverage across everything else.

What I am still building

Growth conversations at HSE are grounded in specific criteria: demonstrated scope expansion, measurable squad impact, quality of reasoning in critique. But those criteria live in 1:1 notes and my own model. I am working with my director to formalize a career framework with explicit levels and competencies, so that career progression is legible to every designer, not just the ones I happen to coach well.

What I would do differently

Before HSE had a dedicated research tool, I introduced dog-fooding: structured internal testing using colleagues from other departments as stand-ins for real users. I commissioned an employee with strong cross-departmental relationships to build that coalition, because she knew the company better than I did at that point. It worked. The process ran smoothly for years.

When she went on maternity leave, it collapsed. Without her relationships, the departments outside ecommerce stopped participating. I had not built a structure that could survive her absence. I had built a dependency.

That is the thing I would do differently. A process that runs because of one person is not a process. It is a person. I should have identified her absence as a structural risk early enough to build the redundancy in. I did not, because it was running smoothly, and smooth-running processes do not feel like they need attention.

The design system had the same vulnerability. I learned the lesson twice.