Recent thoughts

The Hardest Part of Design Leadership (That No One Teaches You)

January 28, 2026

There is a persistent idea in tech that design leadership is a softer form of leadership. Less political, less exposed, and more vibey. Design organizations are often seen as a place where experienced leaders can focus on craft, culture, and quality, while product and business leaders handle the harder edges of accountability. This framing glosses over the demanding, strategic, and often invisible work required to align creative teams with business goals.

I did not learn how to lead in design school. I learned how to see, how to critique, and how to care deeply about form, clarity, and intention. School taught me taste, process, and confidence in my point of view, but not how decisions actually get made once design leaves the room. That gap widened during a decade in creative agencies, where persuasion and presentation are rewarded, success is measured in approval rather than outcomes, and you can sell ideas without ever owning their consequences. I did not fully understand that gap until I moved into product management, where the shift was uncomfortable in all the right ways. The work stopped being about proposing the best idea and became about choosing which imperfect idea to ship, with real accountability attached. You learn quickly that conviction without prioritization is noise, and that strategy only matters if it survives contact with constraints.

In recent years I’ve landed somewhere in the middle, leading a design and product experience teams. I’m not gonna lie, at times it’s more awkward than I expected! What has surprised me most is not how familiar the work feels, but how much harder it is than the version of design leadership I was implicitly trained to expect.

Influence Is Harder Than Authority

One of the biggest misconceptions about design leadership is that it becomes easier as you move away from delivery and closer to influence. In my experience, influence without authority is much more demanding than authority itself. In product roles, decision rights are usually explicit. When conflict arises, there is a known escalation path. When tradeoffs must be made someone is expected to decide, and teams, especially newly formed ones, often look to product. That clarity does not eliminate tension, but it gives it shape.

Design leadership rarely comes with that kind of clarity. More often, it places leaders in a position where responsibility significantly exceeds formal control:

  • You are accountable for experience quality without owning the roadmap, the staffing model, or the delivery cadence.
  • You are responsible for coherence across teams, systems, and products that do not report to you.
  • You are expected to raise the bar without becoming a bottleneck, and to advocate for users without positioning yourself as anti-business.

None of this is soft work. It is difficult systems work

This is where many design leaders struggle, especially those who have stayed close to craft throughout their careers. They assume that strong ideas, good taste, and well-researched arguments will naturally carry weight. Sometimes they do, but often they do not. Being right is not enough when you do not control the conditions under which decisions are made.

What I learned in product management, and continue to rely on in design leadership, is that prioritization is the real language of leadership. Strategy only matters if it shows up in sequencing, tradeoffs, and resourcing. If you do not understand how those mechanisms work, your influence will always be partial. Your ideas may be admired, but they will not reliably shape outcomes.

Craft Doesn’t Scale. Systems Do.

Design education prepares you to solve problems within a frame, but at the leadership level, design leaders are required to understand how frames get set in the first place. Who defines success? Who absorbs risk? Who pays the cost of delay? These dynamics determine what is possible long before a designer sits down with an overpriced coffee and launches Figma.

Senior design leaders are constantly shaping systems, whether they intend to or not. Team topology, review rituals, decision rights, and escalation paths all influence experience quality far more than individual artifacts. If you do not have a point of view on structure, people, and process, you end up reacting to symptoms instead of addressing causes. You push for better design while the system quietly produces the opposite.
Business acumen ties all of this together. This is not about becoming a finance expert or chasing revenue at the expense of users. It is about understanding what the organization actually optimizes for, how success is measured, and where pressure originates. Without that fluency, design advocacy often lands as resistance rather than contribution. You are speaking a language the business does not fully understand.

Leading Without the Levers

In my current role, leading through influence rather than direct ownership has forced me to become more deliberate. I spend less time arguing for what I believe is right and more time understanding how decisions are actually made. I invest in relationships not as a soft skill, but as infrastructure. I think carefully about when to push, when to wait, and when to escalate, knowing that timing often matters as much as correctness.

This work is not glamorous. Much of it is invisible, and keeping it from staying that way requires constant effort. When it goes well, it often passes without notice. When it goes poorly, design is usually blamed anyway.

That is why the idea of design leadership as a safe haven persists. From the outside, it looks quieter. There is no end-to-end product mandate, no engineering armies to deploy, no obvious decision point where the buck stops. But that quiet is deceptive. It is the quiet of diffuse responsibility, where outcomes depend on alignment rather than authority, and where progress is incremental until it suddenly compounds.

Design leadership without strong product judgment, organizational literacy, and business fluency collapses into focusing on craft and vibes. The work may feel aligned with design identity, but it rarely scales. It depends on heroics rather than structure, persuasion rather than leverage. It can be safer, but then its impact is severely limited.

The hardest part of design leadership is learning how organizations work, how businesses decide, and how to lead effectively without guaranteed authority. I learned this the long way, by crossing boundaries and living with the consequences. I am not sure there was a faster path, but it left me prepared for the work ahead.

Craftsmanship in the Loop

November 1, 2025

“Craftsmanship is a quality that some lack, you gotta give the customer a reason for them to come back.”
–Buck 65 – Canadian rapper, poet, and storyteller

That line has followed me for more than twenty years. I’ve quoted it in interviews, in team offsites, even in design critiques. It’s a simple truth that has always felt like the backbone of good work, whether you’re making music, code, or products. Craftsmanship matters.

But lately, I’ve been wondering what that word even means anymore.

The Setup

Geek alert: I promise this comes back to something actionable, and hopefully relatable.

A few weeks ago, I built a new home lab server using Proxmox, an open-source virtualization platform. Basically, I wanted to tinker with Linux, learn the latest server tech, and play with modern development tools, which I haven’t done much of in recent years (thanks for draining all of my energy, loving family).

It started innocently enough: an old laptop I had repurposed as a home server was on the brink of death, so why not turn that into a weekend project? Pick up a cheap mini PC, then rebuild (and break) things for fun. What surprised me wasn’t the setup itself, but what I felt while doing it.

For the first time in years, I was installing dependencies, connecting to servers, configuring proxies, and editing configurations by hand. I used VS Code to SSH directly into the system, and ChatGPT helped when I got stuck. That combination—VS Code’s near-telepathic autocomplete and ChatGPT’s “I-know-everything” energy—was… eye-opening.

The Old Way

Twenty some odd years ago, I worked as a web designer and front-end developer. Back then, HTML and CSS weren’t just markup and styling—they were a survival game—and even before starting my professional career I was hand-coding in HTML. We didn’t have autocomplete or inline validation or Stack Overflow.

When I started working full-time, my prized possession was a $20 zip file of HTML and CSS references, which became my bible. It lived on every machine I touched. I knew those specs inside and out. I knew how to make layouts behave across Internet Explorer and Netscape. I learned the tricks, the weird float bugs, the clearfix hacks, the pixel rounding issues on nested tables.

I wasn’t special; that was just what being a front-end dev required. There was pride in that. You earned it through repetition, through pain, through the discipline of not having shortcuts.

When something didn’t work, you didn’t copy-paste a fix, you understood why. You opened “View Source,” you experimented, you internalized. It was slow, but it made you sharp. It built a sense of craftsmanship that stayed with you.

The New Way

Fast-forward to today. VS Code and other modern development tools don’t just autocomplete your syntax, they complete your intent. These tools now read the context of your project, the dependencies in your packages, the shape of your markup files. They know enough to suggest what “should” go there before you even know it yourself. And when it doesn’t know, ChatGPT does. Or at least, it tries to.

The mix is intoxicating: instant feedback, context-aware suggestions, explanations on demand. It’s like pairing with an infinitely patient senior developer (who’s maybe a little too confident and sometimes pretty darn wrong). I caught myself coasting. I’d paste an answer from ChatGPT into VS Code, hit save, and hope it worked. No debugging. No real understanding of why it worked.

That’s when it clicked: I suddenly understood why some modern dev teams—especially ones full of younger engineers—can feel like they’re moving fast but learning slowly.

The Concern: When Speed Replaces Understanding

In the last few years, as I’ve led design and product teams, I’ve noticed a pattern:

  • Delays across organizations don’t generally come from lack of effort, but from a lack of understanding.
  • Fixes that solve one issue often create… more issues.
  • Teams seem technically fluent but conceptually lost.

I’ve always chalked that up to the natural growing pains of complex systems. Modern stacks are so massive that nobody on the team can know everything. But now, after this little Proxmox experiment, I’m not so sure that’s the whole story.

Maybe what we’re seeing is a generation of developers raised by autocomplete. The tools that once helped experts move faster are now helping beginners skip the hard parts. And skipping the hard parts can make you productive, but not necessarily skilled. When your tools predict the next line of code, it’s not teaching you; it’s shielding you. When ChatGPT explains a configuration, it’s not giving you understanding; it’s giving you an answer that sounds right. Multiply that by deadlines, side projects, and never-ending sprints, and suddenly you have a team that ships a lot, but may know very little.

Everything looks fine. The code runs. The PR gets approved. From the outside, everything’s humming. But under the surface, the team’s collective understanding is shallow. The system becomes a black box, glued together by trust in tools they don’t fully grasp. And when things break—as they always do—the fixes take longer. Debugging turns into archaeology.

For what it’s worth, I’ve seen this happen across disciplines, not just in Engineering. Designers often rely entirely on Figma plugins and auto-layout logic without understanding CSS; Product Managers might generate AI-generated requirements that sound amazing, but collapse under scrutiny. In each case, the tool gives us speed and confidence but quietly erodes the craft beneath it.

The Shift: From Syntax to Systems

In AI-circles, the phrase “human in the loop” describes exactly this: a setup where people remain essential, guiding and refining rather than being replaced.

Twenty years ago, craftsmanship meant knowing every HTML tag by heart. Today, that kind of knowledge is commoditized. The new craft—whether you’re in development, design, or product—is shifting from syntax to systems. It’s no longer about how fast you can write code, mock up an interface, or produce a requirements document. The real skill now lies in understanding how things connect—how technology, decisions, and people intersect. The new craft might be in:

  • Understanding systems instead of syntax.
  • Knowing when to trust the AI and when to override it.
  • Building guardrails, not just outputs.

Developers may move from writing logic to curating intelligence. Designers may move from pushing pixels to composing behaviours. Product Managers may shift from writing specs to shaping ecosystems. It sounds poetic, but curation still requires taste, judgment, and experience, which only come from doing the hard work that modern tools increasingly let us skip.

Leaders have a new kind of responsibility here. We can’t just evaluate output anymore; we have to look at how that output was produced.

  • Did the person rely entirely on AI suggestions?
  • Do they understand the implications of what they shipped?
  • Can they explain their reasoning in their own words?

I’m already seeing a widening gap between those who understand the systems they use and those who simply operate them. The first group uses AI as leverage; the second uses it as a crutch. It’s not about gatekeeping or nostalgia for “the good old days.” It’s about protecting the link between curiosity and competence, and making sure people still learn through friction.

Ultimately, that leaves us with fast teams that truly get better. And maybe, just maybe, that’s what will give our customers a reason to come back. Which brings me back to Buck 65 and why that lyric still hits home…

The Hidden Differentiator: Craftsmanship

That’s what Buck 65’s quote was getting at: craftsmanship isn’t just about outcomes. It’s about the care and intention that goes into great work. It’s the difference between a layout that looks good today and one that’s maintainable a year from now, or a system that “just works” and one you can trust.

In a world of generative everything, craftsmanship might be the last true differentiator left. Because here’s the thing: anyone can now produce something that looks polished. AI can write, design, code, compose. The outputs are getting scarily good. But the feel of good work—the intentionality, the invisible polish, the understanding of trade-offs—that still takes a human who cares.

Craftsmanship is what keeps people coming back. Ironically, it’s the very thing most at risk right now.

The AAA Trap: Prestige Is a Hell of a Drug

September 27, 2025

If you’ve spent any time around youth sports, you know the obsession with “AAA.” It’s the top tier, the big leagues before the big leagues. Parents whisper about it in arenas, and their kids pin their self-worth to it. Coaches act like making it is the only thing that matters. As a parent, I get it—there’s this weird social pressure to make sure your kid is on “the best team.” You find yourself scanning rosters, comparing tryout lists, and wondering if you’re ruining their future because they’re in AA instead of AAA (or God help you, house league!). As if future happiness is determined at age 9 with a pair of skates.

Personally, I don’t think double or triple letters are always the best place for a kid. Some thrive. Others burn out. Some are just playing the wrong sport altogether. You can grind your way up to competitive-level hockey and still be miserable if, deep down, you were meant for soccer, or track, or playing guitar in the basement.

That’s the trap: with the right skills and a little bit of luck, you can make it to the highest level of the wrong game. From the outside, it looks like success; from the inside, it might be quite the struggle.

This trap has defined a good chunk of my career, a decade in product management. On paper, it looked like the dream: influence, visibility, high-stakes decisions. I was in the room where things happened. And I was good at it—just like some kids are good enough to make AAA even if it’s not their natural game. I built roadmaps, ran prioritization sessions, wrangled stakeholders, and lived in the land of trade-offs.

But… it always felt… off. Like I was running a marathon in a weighted vest. Meetings drained me. Wins felt like relief, not joy. Often, I didn’t want to wake up in the morning. It took many years for me to realize that deep down, I knew I was out of position. This wasn’t obvious right away—I convinced myself for years that my struggles were just part of the gig.

Building Something From Nothing

After a layoff, I caught a break and stumbled back into my game. Almost immediately, I felt how different it was to be in the right place. That realization hit hard when I rejoined Telus a few years ago. The company wanted to enter the smart home space—they had a business case, but no product. No roadmap. No definition beyond “we should do this.”

I led design on what would become their new SmartHome+ app. In less than a year, a scrappy team of us designed it from the ground up. And here’s the thing: design wasn’t just decorating the edges—we were instrumental in defining the product. We set the vision, mapped the journeys, decided what mattered first, and collaborated with engineering to make it real. It was messy and intense, but the work with my design team felt right.

Now, a year and a half after I moved on, Telus is still shipping features based on our design foundation. Stuff we sketched and argued about back then is just now hitting production. I don’t know what the team is doing day-to-day anymore, but it’s strangely validating to see those ideas still alive and being built. It’s like leaving behind blueprints and coming back to see the house not only built but with new wings still being added.

There was a big gap in the cultural fit for me (I had left Telus years before for a reason), but that experience is when it clicked for me: this is what it feels like to be in the right game. The long hours didn’t grind me down—they energized me. Instead of dragging myself through prioritization meetings, I was excited to shape the direction.

Shaping What’s Already There

Fast forward to today: I’m at Coveo, leading a team of designers in a very different setup. No blank canvas. No greenfield product. Instead, I inherited a team working on a mature platform in one of the most competitive spaces imaginable: AI.

Coveo has always been about technical depth. Our products are built on precision, scale, and sheer engineering prowess. But now the opportunity is to win on experience. To make the power of our AI feel effortless and indispensable to the people using it. Walking into that, my first job wasn’t to “revolutionize design.” It was to stabilize:

  • Get clarity on roles in a restructured team.
  • Sit down one-on-one with people throughout the company to actually listen to what is working (and what is broken).
  • Prioritize what matters most across people, processes, and eventually, product.

And here’s the irony: all those product management skills I carried like baggage? Suddenly, they’re jet fuel. Juggling backlog prioritization, trade-off discussions, and stakeholder alignment all felt like survival tactics during my time in product management. In design leadership, these skills and my experience over the years now amplify my strengths. I’m not forcing myself to play the wrong game anymore; I’m using skills from other games to excel in the right one.

Twenty Years, Many Teams

Looking back, my career reads like a closet full of mismatched jerseys. Agencies. Small companies. Corporate gigs. Large enterprises. Product management. Design leadership. Some of those moves definitely felt like wrong turns at the time. But here’s the truth: every stint taught me something I carry now.

It’s like spending a season in the wrong sport. Maybe you weren’t cut out to be a rower, but 5 a.m. practices still drilled discipline into you. Maybe your coach was a hardass about conditioning, and that toughness stuck. The wrong game can still prepare you for the right one.

That’s what product did for me. It toughened me up. It taught me patience and how to navigate endless ambiguity. And now, in design leadership, those lessons are assets—not weights.

Choose the Game, Not the Jersey

The AAA Trap is seductive. Prestige hits hard at first, but the crash comes fast. You keep climbing because you can, because everyone around you cheers when you make the cut. But the truth is brutal: the wrong game at the highest level is still the wrong game.

The right game doesn’t necessarily feel easier. It’s still hard work, long hours, and tough calls. But it feels different. The hard work energizes instead of draining. The wins feel like fuel, not relief. And the impact lasts—like seeing a product you helped define continue to ship features years later, or watching a team you stabilized grow into its stride.

If you’re thinking about switching sports yourself, here’s the short version of my playbook:

  • Track your energy, not just your résumé. Pay attention to what gives you flow versus what feels like slog.
  • Reframe detours as training (both in your mind and on your résumé). Practicing at the wrong game still builds muscles you’ll use later.
  • Don’t confuse prestige with fit. The “AAA” title doesn’t mean you’re in the right sport.
  • Expect to start fresh, but not empty. A pivot might reset your role, but you’re carrying transferable skills (and scars).

In the end, it’s not about making the AAA team. It’s about knowing whether you’re playing the right sport in the first place—and having the courage to switch when you finally realize what that is.

Read more thoughts…