Building the Design Function at Knapsack
How I repositioned design from an execution function to an organizational partner, and what it took to change how leadership saw the role.
01 — The Situation
What the function was
When I joined Knapsack as a Senior Product Designer in September 2021, design existed in a familiar but limiting way: we made things look good. The function was execution-focused by default, brought in after decisions had been made to apply polish and produce deliverables. There was no expectation that design would have a perspective on what to build, when, or why. That wasn't anyone's fault. It was just how the company had grown up.
That model doesn't just make designers feel undervalued. It makes the work worse. When design enters a conversation after the shape of something has already been decided, the best it can do is optimize the surface. The harder questions, about what a feature actually needs to do, what mental model a user is operating with, where the real friction lives, product and engineering answer those without design in the room.
I started working on that problem before I had a director title. By December 2022, when I was promoted to Director of Product Design, the work of changing how design was perceived was already underway. The promotion gave me more leverage, but the approach didn't change.
02 — My Approach
How I thought about the job
My core belief was that design's influence had to be earned through usefulness, not argued for through process or hierarchy. I didn't come in with a playbook. I didn't propose new rituals or lobby for design to have a seat at the table. I started by understanding what each stakeholder actually cared about and finding ways to be genuinely useful to them on their own terms.
That meant resisting the instinct to formalize too early. A lot of design leaders in this position start by establishing critique cadences, design reviews, definition-of-done checklists. Those things have value, but installed before the organization has seen why design is worth the investment, they read as overhead. I chose to earn trust first and put structure around what was working once I had it.
It also meant staying a working leader, in more ways than one. As the sole designer for the full run of the role, stepping back from hands-on work was never an option. But staying close to the craft also meant staying close to the codebase. At Knapsack I owned the front end: built design system components in both Figma and React/TypeScript, shipped full sections of the application, and handled ongoing bugs and enhancements across the codebase. That firsthand involvement kept me honest as a leader. I understood what the work created downstream, and when the gap between design intent and shipped product opened up, I could close it myself.
03 — The Work
What I actually did
The most important work happened in relationships, one at a time. With the CEO, I tried to be a thinking partner on product direction, not just someone who could execute a vision. With the CTO and head of engineering, I invested in understanding the technical landscape well enough to have honest conversations about tradeoffs rather than just advocating for design preferences. With the head of product, I built a working rhythm where design and product were solving problems together rather than passing work back and forth.
One relationship that paid off in ways I hadn't fully anticipated was with the head of customer service. Most design leaders focus their stakeholder energy upward and across to product and engineering. Customer-facing teams at a B2B company see patterns in user frustration that never make it into analytics, and getting design into those conversations earlier meant we were working on real problems rather than inferred ones.
Working closely with engineers was a constant part of the job. A lot of that time was in spec reviews — making sure what was getting built matched the intent behind the design. But just as often the conversation went the other direction. Engineers would come to me to think through a technical tradeoff, pressure-test an approach before committing to it, or just talk through frustration when something wasn't working. I wasn't their manager, but I was operating in that space where trust either exists or it doesn't. Getting it meant being genuinely useful in technical conversations, not just present for them.
04 — What Changed
The shift that happened
The signal that something had changed came gradually and then felt obvious: I started getting pulled into initial conversations across almost every workstream. Product and engineering, yes, but also customer service, strategy conversations, early problem framing. Across nearly every function, the default shifted from "bring design in when it's ready for polish" to "bring design in while we're still figuring out what to build."
That kind of broad organizational pull doesn't come from a single champion or a well-timed pitch. It comes from enough people having enough good experiences that it becomes the expectation. By the end of my tenure, design had relationships and visibility at every level of the organization, from the CEO down through individual contributor teams, that it simply hadn't had before.
There are no clean metrics for this kind of work. What I can say is that the change was visible and broadly felt, not the result of a single initiative but of consistent presence and earned trust over roughly three years in the director role.
05 — What I Learned
What I'd do differently
The relational approach worked, but it took longer than it needed to because I was too patient about formalizing what was working. Once I had enough trust built across leadership, I could have moved faster to turn those informal patterns into explicit expectations. I waited for things to feel settled before putting structure around them, and some of that structure would have helped the team, not just me.
I'd also document the design function's value more explicitly and earlier. The work I was doing in stakeholder relationships was largely invisible inside the organization, which is fine when things are going well, but it means the function's contribution can be hard to articulate when it matters. I got better at this over time, but I wish I'd started sooner.
Finally, I'd invest earlier in formalizing the cross-functional relationships that were actually driving results. The working rhythms I built with engineering were largely informal, which is fine when things are going well. But informal trust is hard to hand off and hard to articulate when the work needs to be defended. In a future role I'd turn those patterns into something more durable earlier, so the function's value isn't dependent on my specific presence in every room.