Four principles.
Not a management philosophy deck. These are the four things I actually do differently, and what each one looks like on a Tuesday.
Stay close to the work
Leadership does not require distance from the craft. I am in research, critique, Figma, prototypes, design systems, and implementation often enough to know where the real problems are — not where the status report says they are.
I write production HTML and CSS, so implementation review is a conversation rather than a complaint.
Give designers context, not instructions
Strong designers do not need someone dictating screens. They need clarity on the customer, the business, the constraints, the strategy, and what success actually means. Then they need room.
Bring one recommendation and the alternatives you rejected. Exploration is cheap now; deciding is the job.
Build leverage, not dependency
The goal is not to become the person every decision runs through. Systems, standards, rituals, documentation, and stronger designers — so quality holds when I am not in the room.
Serving five product teams at once forces this early: quality has to live in the system, not my calendar.
Make the work matter to the business
Design earns influence by connecting customer outcomes to product and business outcomes. I teach teams to explain why the work matters, not only why the interface is better.
Set the metric before designing. If we cannot say what should move, we cannot claim we moved it.
Three situations, and what I did about them.
Six things I am actually responsible for.
Hiring and developing designers
Hiring across disciplines, mentoring, direct feedback, career development, and building teams whose strengths complement rather than duplicate.
In practice: hired designers, engineers, product managers, interns, and virtual assistants — six role types, because a product needs more than designers.
Several products at once
Setting priorities, allocating design capacity across roadmaps, and balancing what has to ship this month against the work that compounds.
In practice: up to five product teams simultaneously, and as a VP the product management function alongside design.
Raising the craft bar
Critique, system standards, accessibility, interaction quality, and implementation review — because design ownership does not end when the file is handed over.
In practice: I write production HTML and CSS, so implementation review is a conversation rather than a complaint.
Making design scale
Design systems, process, documentation, and the cross-functional rituals that make product and design collaboration boring in the good way.
In practice: a company-wide Figma system at Green Street covering every web and mobile product the company ships.
Deciding what to build
Framing the problem before the solution, choosing what not to do, and connecting the roadmap to what the business actually needs to happen this year.
In practice: on several products I was the designer, the product manager, and the project manager for the same work — so the strategy and the craft stopped being a negotiation.
Earning design a real seat
Working with founders, executives, and engineering leadership — translating design decisions into business terms, and absorbing the organisational friction so the team can design.
In practice: reported to and worked directly with founders and executives at a startup, a public company, and an analytics firm — three very different rooms.
The operating system behind the team.
Weekly design critique
Quality control that is not micromanagement. Problems get argued in the room instead of in a review thread three weeks later.
Product trios
Design, product, and engineering in from the beginning. Most handoff problems are actually late-inclusion problems.
Early prototypes
Resolve ambiguity before implementation is expensive. A working prototype settles arguments that slides cannot.
Design-system reviews
Solve recurring problems once. Anything solved twice belongs in the system, not in another file.
Implementation reviews
Design ownership does not end at Figma. We check what shipped against what we intended, and fix the difference.
Research feedback loops
What ships becomes the input for what comes next. Otherwise the process is a line, and design work is not a line.
Great teams are not collections of great portfolios.
I look for complementary strengths rather than ten versions of the same designer. Some people excel at systems, some at research, some at visual craft, some at interaction, facilitation, or product thinking. My job is to build the environment where those strengths compound instead of collide.
That has become a genuinely new problem: designers can now produce competent work before they understand it. So I ask people to explain their decisions out loud, often. Anything you cannot justify is not finished, however quickly it arrived.
What designers get from me
Context
You will understand why the work matters before you are asked to do it.
Autonomy
You own the problem, not just the screens assigned to you.
Feedback
Direct critique without ego. Vague feedback is not kindness.
Air cover
I handle the organisational friction so you can design.
Growth
Stretch beyond the work you are already comfortable doing.
Still in the work.
Leadership did not replace designing for me — it changed where I can create leverage. I will go from an executive product conversation to a critique to a prototype to a component architecture discussion in the same day.
What my team should expect from me.
You will always know why
I do not want a team executing requirements blindly. If I cannot explain why the work matters, the work probably does not.
I will tell you what I think
Clear feedback is kinder and more useful than vague feedback, even when it is less comfortable to give.
You can disagree with me
The best idea should win regardless of title. If I am the smartest person in every discussion, I hired badly.
I will protect the craft
Timelines matter. So does shipping something we are willing to put our names on.
I will not be the bottleneck
A healthy organisation should get stronger as leadership scales, not more dependent on one person's calendar.
Different titles. Same job: make the team and the product better.
Titles changed with the organisation. The responsibility stayed surprisingly consistent: understand the problem, create clarity, develop people, raise the quality bar, and help the team ship.
Full role history →Leadership without an org chart.
I served as President of two Southern California experience-design organisations, bringing designers together across San Diego and Orange County through events, mentorship, portfolio reviews, and community programmes. Nobody in those rooms reported to me — which is a useful education in getting people to follow anyway.
President of one of the two largest UX organisations in San Diego — running the events and reviews that a generation of local designers came up through.
Bringing the same community to my home base in OC — events, portfolio reviews, and a network of design leaders who help each other hire and grow.
Chris is an amazing designer and gifted author. His designs are clean, creative, well thought through, and concentrate on the message and call to action. I strongly recommend Chris to anyone looking for a superb designer and CSS guru.
“Chris walked into a fragmented product suite and came out with one design language, a real component library, and engineering actually using it. Delivery got measurably faster and the arguments about patterns stopped.”
“The rare design leader engineering trusted. He read our codebase, prototyped the hard interactions himself, and never handed us a spec he could not have built. Ambiguity went away.”
“Chris gave me the context and then got out of the way. Direct critique, no ego, and air cover when the organisation pushed back. I grew faster on his team than anywhere since.”
Need a leader who can still build?
I'm interested in Head, Director, VP, Lead, and Principal-level opportunities where design has a meaningful seat at the product table.