There's a particular kind of challenge that doesn't show up in a brief.

It lives underneath the product work: in the processes that don't exist yet, the workflows nobody has defined, and the question of how a historically physical industry learns to trust software design as a core value driver. You can't prototype your way out of it. You can't run a workshop and call it solved. You have to show up, consistently, and build the infrastructure that makes good design possible before you can make good design.

That's what this engagement was really about.

The context

A major American agricultural machinery manufacturer was building a new aftermarket digital product: software for the dealers and parts specialists who keep machinery running in the field. This wasn't a consumer app. It was a complex, multi-layered tool for people who spend their days moving between physical parts books, digital systems, and their own hard-won expertise to diagnose problems for customers standing in front of a broken machine.

I was brought in to pair with the Product Principal, working alongside client design leadership on a program that spanned multiple products and workstreams. I directed two program-wide designers placed to support across streams rather than anchor to any one, which meant leading at a scale and spread that required as much systems thinking as design craft.

What I saw in the field

Early in the engagement I did on-site observations with parts dealers, watching them work through real customer problems in real time.

A farmer calls. Something on the machine isn't right. The dealer moves between a physical parts book, a digital tool, their own memory, and whatever institutional knowledge they've built up over years. The process is slow, fragmented, and deeply reliant on expertise that lives in people's heads rather than in the systems they use.

Watching that, I knew we could help. Not in an abstract “design will solve this” way, but in a specific, grounded one: if we got the experience right, we could reduce the cognitive load of a genuinely hard job and give dealers back time and confidence they were spending on friction.

The flip side came later, when dealers used a first version of our solution intuitively, navigating a complex, multi-layered experience without needing to be taught. Watching people move through something we built with ease and recognition is one of the things I work for.

Building the Blueprinting Process

One of the first things I recognized was that the program needed a structured, consistent way to take ideas from conception to validated prioritization. Without it, good ideas would stall, weak ideas would move forward on momentum, and the design team would spend more time reacting than shaping.

What became known as the Blueprinting Process came out of a genuine three-way collaboration between me, the Product Principal, and the Technical Principal. That's not a detail. It's the point. A framework built by design alone would have solved a design problem. A framework built across all three disciplines solved a program problem. Think of it like weaving: Product, Design, and Technology each brought a thread, distinct in texture, weight, and color, and the Blueprinting Process is what emerged when we learned to work the loom together.

The result was a repeatable path for taking an idea through structured exploration and validation before it ever reached a development team, giving product owners the confidence to move forward or the clarity to pause and revalidate. It also became an upskilling tool for newer product owners, giving them techniques to break down and structure ideas that made them stronger partners to design and engineering.

It's the kind of work that doesn't show up in a portfolio the way a beautiful screen does. But it changed how the program operated, and it only worked because three principals brought the full depth of their craft to a shared problem and trusted that the combination would be stronger than any one perspective. It was.

DesignOps and design quality at program scale

Alongside the Blueprinting Process, I was asked to weigh in on, and eventually own, the program's DesignOps: the tooling, processes, and ways of working that let a distributed design team produce cohesive, high-quality work across multiple products at once. I also took on delivery assurance, making sure what shipped actually delivered the customer value the program strategy intended.

This is my bread and butter. Nothing energizes me more than aligning work across products and workstreams so the overall experience lands as one coherent, intentional thing rather than a collection of individually designed screens. Sometimes that meant empowering the program-wide designers to manage alignment themselves. Sometimes, depending on the complexity or the politics, it meant stepping in directly. Most of the time it meant finding how design could flex to let the work move forward without sacrificing the integrity of the overall experience.

The crucial conversations

My counterpart relationship with the client design leader was one of the most important of the engagement. Our conversations weren't always easy, but they were always necessary.

Some were about the ongoing case for design in a company that had spent most of its history making physical things. The idea that how something feels to use matters as much as what it does wasn't an intuitive truth in this environment. It had to be demonstrated, argued for, and proven through the work. That's the hill design keeps climbing in organizations new to it, and I'm comfortable on that hill. I bring evidence, empathy for where the organization is coming from, and patience for how long real cultural change takes.

Others were about people: how to grow the designers on the team, how to structure the team as it grew, how to find the right contexts for each person, and how to give feedback that lands and sticks. Those conversations take the same radical transparency I bring to everything, and the same belief that honest, caring feedback is one of the most generous things a leader can offer.

What this project taught me

The most important design work on this engagement wasn't a screen or a flow or a component. It was a process that helped a program think more clearly, a DesignOps foundation that let a team work more cohesively, and a set of relationships built on enough trust and honesty to make difficult conversations possible.

Design leadership at program scale means accepting that your impact is often invisible: embedded in how a team operates, how decisions get made, and how quality holds across work you didn't personally touch. That invisibility used to feel uncomfortable. Now it feels like the point.

When that dealer moved through our solution intuitively, they didn't know about the Blueprinting Process or the DesignOps framework or the conversations that shaped the work. They just knew it worked.

That's enough.