Running Design as a Function, Not a Service
For years, my job was leading design rather than doing all of it myself — running UX and UI teams, and before that designing products inside a large media network across a family of news sites.
The lesson that stuck, the one that still shapes how I work independently, is this: design earns its seat when it's run as a function — accountable to outcomes — not as a service that turns tickets into mockups.
Service vs. function
A design service takes requests in and sends visuals out. It's measured by throughput and how nice things look. It's the first thing questioned when budgets tighten, because nobody can quite connect it to the business.
A design function owns something: the quality bar, the visibility of the work, the connection between what's designed and what the business is trying to achieve. It has a point of view on priorities. It shows up in the conversation before the requirements are frozen, not after. The difference isn't seniority of the people — it's whether design is accountable for an outcome or just for output.
Make design measurable without killing craft
Invisibility is the enemy of craft.
The way you move from service to function is to make design legible to the rest of the business.
Leading the team, that meant real operating discipline: design OKRs and KPIs, delivery visibility, review cycles, workload that could actually be seen and planned. Measurement makes some designers nervous — they think it's the enemy of craft. It isn't. Invisibility is the enemy of craft. When leadership can't see what design is doing or why it matters, design is the first thing cut. Numbers bought the team the room to do good work.
Quality is a system, not a heroic act
You cannot keep quality high by caring hard. You keep it high by building the machinery for it.
That's review frameworks, a real design system, component governance, and yes, pixel-level QA — so quality doesn't depend on which designer happened to touch the screen. Designing for a network of six news sites made this concrete: consistency at that scale isn't willpower, it's infrastructure. Build the system once and quality becomes the default instead of a fight you have every sprint.
Grow people, not just deliverables
The real output of a design lead isn't screens. It's other designers getting better.
Mentoring, role clarity, helping people grow into scope they hadn't held before, supporting the promotions when they earned them — that compounds in a way no single deliverable does. A team that levels up is worth more next quarter than any one project you personally rescued this one.
Why I now build alone
After running the function, I saw exactly how much speed and quality leak out in the handoffs — strategy to design, design to build, build to launch, each seam a place for intent to get lost.
So I build differently now. Independent work lets me keep the whole chain under one accountable owner: the product thinking, the interface, the implementation, the launch. It's not a rejection of teams — I know what a good one is worth. It's the right shape for founders and small teams who don't need a whole department, they need one person who owns the outcome from idea to launch.
The principle is the same either way, leading a team or building solo: design is accountable to the outcome, or it isn't really design leadership — it's just decoration with a deadline.