← Back to list

What Being a Chief of Staff Taught Me About Being a Designer

A year as Chief of Staff, and why I’m going back to design leadership

Mariesa Lenz · 2026-07-16 19:40 · 5 claps · 13.2 min read
#leadership #design #product-design #chief-of-staff #technology
Open on Medium ↗
Wiki topics: PRD · Product Design DSN · Design · General BIZ · Business Strategy

Getting used to the new scenery from a beach in my new home of Oahu, Hawaii.

Getting used to the new scenery from a beach in my new home of Oahu, Hawaii.

What Being a Chief of Staff Taught Me About Being a Designer

A year as Chief of Staff, and why I’m going back to design leadership

Finding space to breathe again.

I return to my desk, newly assembled after making the almost 3,000 mile journey across the Pacific Ocean from Washington State to Hawaii. The space is new but the tools are so familiar. I look around and it feels like seeing good friends after a long hiatus. There’s something different though in this new space and it has nothing to do with the contents of the room. In fact, it’s not physical at all; it’s quality of mind. I can actually breathe again after almost a year of being pulled in so many different directions, Gumby himself would have snapped. There’s a new strange mix in this space of both infinite possibilities and relief. I want to be clear with myself that as I begin this next chapter, I go in with my eyes wide open and armed with new capacities that I’m excited to lean into.

Jumping into a Chief of Staff role

It wasn’t all bad, of course, or at least it didn’t start out that way. I’d only ever worked with a Chief of Staff once at Aurora Solar, and I genuinely liked the guy. I thought he had a good product head on his shoulders, even if I didn’t really understand what he did on a day-to-day basis. So when the role was proposed to me in a subsequent career step, I did my research to understand what a Chief of Staff was all about. On paper, I genuinely liked what I saw: access, impact, a big scope of work, proximity to all the right levers, and the ability to really help build something worthwhile to people out in the world. It was seductive in a totally new way that I wasn’t anticipating. I even synthesized the independent research I did on the duties of a CoS and folded into that my own design-engineering skillsets to create a nicely form-fitted job description. I wanted to kick off on the right foot and feel certain that my principal and I were on the same page. I had also heard horror stories from other CoS’s about how their roles had slowly devolved into administrative and operations work over time and I didn’t want that for myself. I saw Chief of Staff as a step that would allow me infinite space to build exploratory prototypes quickly ahead of the product team so we could learn & validate quickly as well as really execute on the principal’s vision. Hell, I even signed up for 5-star coaching from a top Chief of Staff in the industry, just to ensure I was hitting the ground running and acting as the force multiplier that the role required.

I saw Chief of Staff as a step that would allow me infinite space to build exploratory prototypes quickly ahead of the product team so we could learn & validate quickly as well as really execute on the principal’s vision.

And so the first four months sailed along relatively smoothly and I was happy with the work I was allotted. I built a native iOS privacy tool from scratch, working in Swift for the first time ever, and shipped both the app and a marketing site alongside it. Ultimately the technology didn’t achieve what we hoped it would; the space we were trying to compete in had a two-decade head start on the pattern recognition tooling we would have needed to counter. Our main priorities were elsewhere and so we archived the idea. It was a full end-to-end build though, and getting to ship something that fast, that early in the role, felt like exactly the kind of work I’d taken the job to do.

The next initiative I dug into was designing and developing a renewed search experience for our main product. This was such a perfect challenge that dovetailed my new role in with the rest of the product and engineering team, helping us develop rapport and trust. However, because I was so excited to be using new tools and bringing back old engineering skills that hadn’t seen the light of day in so long, I didn’t ask enough questions about the “why” and the “what” of what we were attempting to solve. A lot of the search “solution” got built with too many assumptions, despite this being a relatively common problem to solve. The team learned from what I built and carried the work forward in their own direction, which was exactly the right call. There are lessons in that experience I’m still sitting with, but ultimately I trusted the team to do what was right for the product and customers.

The downward slide

Then the end of 2025 hit and we started to transition into the New Year. That’s when things got… weird. All of a sudden it felt like getting hit with one fire drill after another and it landed on me to be the main firefighter for our team; running back and forth to each spark or flame to try and quell them before they grew too big. At one point early in 2026, I had at least six major work streams running concurrently, most of which required cross-functional coordination and several of which had real financial or legal stakes. During February through April, I simultaneously navigated a turbulent benefits platform migration, a leadership transition that reshaped how the team was organized, a free-to-paid conversion discovery sprint where I ended up rewriting our entire homepage copy to support. In addition to that, I also co-led pricing and packaging decisions, built a unified sales and marketing strategy, and introduced new decision-making frameworks to the organization.

I was doing all of that as a team of one from a Chief of Staff seat, without a BizOps or even an admin person to support me yet (I won the battle to bring someone on later). Those first several months of 2026 would have been a lot for any one person to juggle (probably too much) and it burned me out worse than I’ve ever been burned in my career. I would walk into a new week at work and wonder, “Which one of my eight jobs will I be doing today?” Sure, some of that is just start-up life, but let me be clear, a lot of it was something else entirely. The situation became unsustainable for many of us on the team, and at the same time the psychological safety of the working environment was deteriorating as well. It seemed obvious to a few folks on the team that advocating for a new or different way of working would mean sticking our heads out in a way to be noticed when that was the opposite of what we should do. Truthfully, the whole experience broke me & what remains will take the most time to repair.

Truthfully, the whole experience broke me & what remains will take the most time to repair.

Why Chiefs of Staff fail (especially women)

Fundamentally, I now realize that Chief of Staff roles overall are built to fail from a systemic point of view. I see that failure fall within three main categories, which at the onset of my own Chief of Staff tenure, I was blind to. I break these down into categories of gendered legibility, CoS scope volatility in the age of AI, and the operations drift being structural, rather than accidental.

Gendered Legibility & the CoS role

First, the gendered legibility problem of women in tech isn’t new, but I did find it extremely magnified within a CoS role, which ultimately became too much for me. My experience in the tech industry extends into almost two decades and at this point, so I’m unfortunately all too familiar with the biases and assumptions that women continuously experience. Namely that we’re constantly having to prove ourselves, our technical knowledge, and often leadership capabilities as well on any given day of work. However, over the course of a year in a Chief of Staff role, so often I would get confused as an Executive Assistant or Administrative Assistant rather than the impactful leadership role I actually held. I told myself, as I’ve had to tell myself for two decades, to step back and not take these assumptions personally. That is its own kind of tax of course. Over time ignoring these paper cuts was hard to put into practice; the weekly onslaught of encountering diminishing, condescending, or patronizing dynamics made it quickly obvious to me that this role would long-term not be a good fit for me, professionally or personally.

See, getting confused for an EA isn’t random; it happens to women Chiefs of Staff regularly, and that’s really unfortunate. The role itself is defined by acting on behalf of the principal; a force multiplier of the CEO’s abilities and capabilities, and yet I was so disheartened to see that even now in 2026 people are defaulting to gendered scripts of who gets read as the executive and who gets read as a support-level assistant. When you’ve spent over a decade fighting to be read as a leader, and the role you’re in structurally invited reading into a gendered stereotype you’d spent a career trying to escape, you learn very quickly that it’s not a role for you.

Volatility in the scope of a CoS’s work

My second category and reason to walk away from a Chief of Staff role was the volatility in the scope of work against what was originally outlined. I’m sure the role always has contained an element of volatility given changing founder, product, or market needs, but this was something else and far more acute. What I experienced was, given the ease and low barrier to entry of building initial prototypes via Claude Code or the like, the original volatility had now gone off the charts and was unlikely to return to baseline.

Now that founders are regularly creating prototypes for themselves by way of Claude Code and Design, they are also taking back the function of building out their ideas for themselves. That’s all well and good, but previously this was squarely set on the shoulders of a Chief of Staff, a Growth team, or Design Leaders. This is not because the CoS or others were doing it badly, but because Claude Code, Claude Design, and the like make it feel so easily doable for a founder to get it done on their own. They have a vision and want to realize it quickly, which is fair enough, but the downstream consequences impact the CoS role specifically in two ways:

  1. First, what do you think happens when the founder is so distracted with building a new idea out themselves that they neglect all the other duties that come with being a CEO and running a business? Well, those duties naturally get passed onto the Chief of Staff, and because, at least in my case, those were mostly HR, operational, financial, and legal responsibilities, I got the honor of learning on my feet and playing what felt like a solo game of ‘Let’s Run a Business®’. Honestly, as a former product and design leader, not only were all those responsibilities not in my wheelhouse, but doing them at the pace I did burned me out so hot and so fast, it’ll likely take me months to recover from the stress.
  2. Secondly, the CoS in a well-functioning setup isn’t just execution; it’s a product discovery function. When the CoS is in charge of building early experiments and ideas out with a CEO, one of the steps before ever writing a line of code or drawing out an interface is a discovery conversation: ‘who is this for?’, ‘what customer or business impact are we trying to make with this?’, ‘what problem are we trying to solve within our existing product?’. Suddenly, I found that none of these questions were being answered, and new ideas were being built out as fast as they could be thought of, with very little validation or direct customer influence. The CoS acts as a fail-safe to ensure that these baseline product questions are answered, but if they aren’t brought into the room because they’re too busy doing operations work, or because it’s 11pm at night and the CEO just wants to work on a side project, then the Chief of Staff can’t do the job they were hired to do: give the necessary gut-checks.

Ultimately, a prototype is really only as good as your understanding of the people who use it, the problem it is trying to address, and the outcome you’re trying to achieve. If you can’t clearly articulate those three things before building something, it doesn’t matter what role you’re in, you don’t belong behind the wheel of the maker machine.

Ultimately, a prototype is really only as good as your understanding of the people who use it, the problem its trying to address, and the outcome you’re trying to achieve. If you can’t clearly articulate those three things before building something, it doesn’t matter what role you’re in, you don’t belong behind the wheel of the maker machine.

Systemic drift into operations

Finally, the last category I identified and the ultimate reason for leaving behind a Chief of Staff role and returning to Design Leadership was due to the operations drift and my final realization that this was not situational but in fact structural. You have to understand, the CoS isn’t really one thing across all companies. A good Chief of Staff can change their shape and morph into whatever the founder currently needs. Ideally this malleability can become a really nice yin-yang balance of skills and needs with a founder or CEO, when it works well. For example, when a founder’s needs are more strategic, a CoS can lean in to becoming a strategist. When their needs are operational, you become the head of operations. That’s all good and is ok if it’s what the team and the company need. In fact, it can make the CoS role really exciting because it never becomes boring.

When you compare the Chief of Staff role to other roles in tech or product development though, one big difference becomes quickly apparent. Design leadership has a scope defined by craft and Engineering leadership has a scope defined by system. Those are clearly defined with a beginning and a clear ending. Chief of Staff, by contrast, has a scope defined only by “what the founder currently needs,” which is unbounded and constantly changing.

In hindsight, I realize I did the right thing by developing a job description for myself and the particular Chief of Staff role that I was stepping into, based on the founder and the product at the time. And yet, the drift happened anyway, because the drift is in the DNA of the role, not in the job description. The drift isn’t a personal failure, mine or anyone else’s, but it does mean the role fits some temperaments and not others. I know now which one I am.

The return to Design Leadership

So now, here I sit back at my desk after taking a month off to recover from the stress of a job I never anticipated having, with no plans to go back to a Chief of Staff role ever again. I’m glad I tried it and I’m glad I learned all that I did while I was in day-to-day survival mode, but what I’ve learned about myself in the process, is far more valuable than a paycheck or a fancy title full of implied power. I know now that as a creative person down into the core of who I am, that I need to bring that creativity into a daily activity of expression and making. I missed the making and the building more than anything and the possibility of doing that into the future gives me so much hope around my ability to even stay in the tech industry long-term at all.

I know now that as a creative person down into the core of who I am, that I need to bring that creativity into a daily activity of expression and making.

And that means for me, returning to design leadership again. I do this with my eyes full open to the shortcomings of design leadership especially in this current existential crisis where design is reinventing itself again in an era of AI (for more on the current design/AI reckoning, see resources linked at bottom). I’m also returning to the design practice fully knowing that design and product are no longer a perfect fit for me. My own skillset shape has sort of morphed and extended at this point; I’ve been stretched farther than ever by various engineering, operations, and Chief of Staff responsibilities that really grew my confidence and abilities as a leader, entrepreneur, and builder. I am however coming back because that’s the lane I find the most value in still. I’ve always found design and its close connection to human behavior and needs to align well with my core beliefs, and because the role of design leadership tends to be much more consistent in how I will show up every day.

Beyond the day to day, at the end of my career when I close my laptop for the final time, I will be so grateful for the opportunity to give back to a practice that I believe really matters and for the chance to coach some incredible individual contributors throughout their careers. It’s not just about building stuff (although that’s fun as well) but when you’ve guided, prodded, corrected, and cheered on PMs, designers, and engineers on a team for a while and seen them take their careers from zero to hero, there’s nothing quite like that feeling. I love seeing people grow and develop and really spread their wings, whether they’re in design practice or not, and that’s really the thing that I can’t wait to get back to now.

I move forward from here with additional abilities and capacities having touched so many new parts of business development. However, the thing that really stays with me is the confidence I gained in the last year as I realized I already had the skills, capabilities, and expertise to run a successful business and sustain a healthy productive team (or in collaboration with a tight group of aligned leaders). That confidence beats any other skill or lesson I could have taken from the CoS experience, and it makes the last year of turmoil and burnout worth it from that point of view.

I realize now that a design leader who has sat in the Chief of Staff seat works in a different way. Once a product leader has actively expanded into supporting funding rounds, investor meetings, or has come along for the ride in the rollercoaster of entrepreneurship, they can no longer return to their former shape. They’ve gained critical insight into the business side of startups, which not all product, design, or engineering folks ever get access to. The daily stressors of those who sit side-by-side with a CEO or founder are more real to me than ever, and I’ve gained empathy for those in the investor hot seat like I never previously understood.

Final reflection & conclusion

And so on and on we go on the career rollercoaster … as I sit here and stare at my dual monitors, their blue-white glow spilling light into an almost empty new office outside of Honolulu, I feel an overwhelming sense of relief. I’m grateful for the next step in my career being spread out before me and that within that, depth will be my new luxury. In a world so eager to grab my attention and sell me mass distraction, my sustained attention toward the things that truly fulfill me is a privilege I’ve not had in many, many years.

Resources:

  1. “Design, AI, and an Existential Crisis”, by Lance Shields, https://www.linkedin.com/pulse/design-ai-existential-crisis-lance-shields-thfec/
  2. “Designers are in complete denial about AI’s real impact on the industry”, Reddit r/UXDesign, https://www.reddit.com/r/UXDesign/comments/1sqw344/designers_are_in_complete_denial_about_ais_real/
  3. “The New UX”, by Louis Rosenfeld, https://www.linkedin.com/pulse/new-ux-louis-rosenfeld-ga4ue/?trackingId=agv1tsqcSUSGBVoVPFiVMw%3D%3D
  4. “Will AI Replace UX Designers? Facing the Existential Question”, by Gavin Jones, https://www.elixel.co.uk/blog/the-existential-crisis-of-ux-designers-in-the-age-of-ai

메타데이터
post_id
09a015339f5f
slug
what-being-a-chief-of-staff-taught-me-about-being-a-designer-09a015339f5f
url
https://medium.com/@MKLenz/what-being-a-chief-of-staff-taught-me-about-being-a-designer-09a015339f5f
canonical_url
https://medium.com/@MKLenz/what-being-a-chief-of-staff-taught-me-about-being-a-designer-09a015339f5f
author_url
https://medium.com/@MKLenz
status
ok
fetched_at
2026-07-21 16:18:20