[upbeat music] Hey, everyone. Welcome back to the Chief of Staff podcast. I'm your host, Scott Amenta. I'm really excited about today's guest.
Her name is Sarah Kislak, and she's been at Box for about ten years now, which is kind of remarkable in itself. What I love about her story is the path she took to get to where she is today.
She started out as an executive assistant, moved into strategy and ops, became a chief of staff to the head of engineering, and has recently made the leap into product management.
We're going to get into all that today, what that transition actually looks like in practice, what transfers, what doesn't, and honestly, what the chief of staff role taught her that most PMs just don't have.
She's got a really interesting way of thinking about how these two roles work together. And I think whether you're in a chief of staff seat right now or you're curious about what comes next, there's a lot here for you.
Let's jump right into it. All right, Sarah, welcome. Thanks, Scott, for having me. It's great to be here. So we're gonna talk about your role today and your career path because it's a very interesting one.
I wanted to start by talking a little bit about... You made a comment to me in our, our first conversation about having kind of a mini chief of staff role first, reporting to the actual chief of staff.
What did you learn by kind of watching before you were in the hot seat? What did that kind of experience look like for you?
It was a really good opportunity for me to learn because I got to really observe the role before being actually responsible for it.
So one of the things I was able to observe was how the chief of staff thought about priorities. And I think as a chief of staff, your priorities are your principal's, full stop.
And it sounds obvious, but it can be easy to overcomplicate. And if you're anxious about proving your value, you might end up creating and solving problems that don't actually exist.
And so I was watching the chief of staff at the time do something that, again, sounds simple, but was really, really effective, which was she would sit down with the head of engineering and just keep a running list of the top problems that they were facing, and they would do that week over week and be able to just kind of adjust what they're focused on to be able to stay agile and aligned.
And that was really effective. I think the equivalent in product is sometimes people design products that customers don't actually need.
And so as a chief of staff, you wanna make sure that you're solving problems that your principal actually needs you to be addressing.
Another thing that I observed was the really tight loop of relationship between the triad of EA, chief of staff, and principal.
I think that feedback loop is super important, and it was really a lot of trust and candor and really a personal relationship.
I think every role, of course, requires a high level of trust, but the chief of staff and principal relationship is a little bit unique because you're often expected to speak on their behalf, represent their thinking, and act with their authority at times, and that is only effective when there's an unusually high level of trust.
And so I also really saw how central that was to their relationship and effectiveness and really shaped how I thought about my chief of staff role, too. And you've been at Box for about ten years now? I have, yeah.
Pretty sizable chunk of your career, I'm assuming. What was your kind of initial experience at Box when you started in strategy and operations?
Was that the kind of mini chief of staff role that you're describing here, or did that come a little bit later on? That came a little bit later on.
I started at Box in a rotational program, actually, where it was kind of fresh grads out of college, and they put you in an assistant role for a year and a half to two years before you found a new role in the business.
Mine, after two years, of course, was the strategy and ops role, but I started out as an exec assistant for head of engineering.
So even before there was any chief of staff role, I was an EA, and that also helped me understand how to work really close with execs, how to build trust.
So that was actually my first jumping-off point before I ended up in strategy and ops for a few years.
And did you have an eye, having come from more of the administrative background when you started at Box, did you have an eye at what a more strategic or operational role might look like?
Was that something that you had to carve out for yourself? Was it something that your principal helped to orchestrate? How did that transition look like for you?
Because I was in this kind of rotational program where the expectation was after two years, you move on to something new, I think that set the tone for-- I definitely was hungry for bigger projects, and we didn't have a chief of staff at the time.
And so I worked really closely with head of product, head of eng, who I was working for at the time, to take on meatier projects. And there was a ton of runway because I was the only assistant for four execs.
Now I think we have five in the org, and at the time there was just me, no chiefs of staff. So I was doing really big projects. You know, I was helping run our all-hands and co-create the strategy for those.
I was running our hackathons. I was helping with the OKR process.
So a lot of these kinds of ops projects, sort of chief of staff projects too, I was able to take on just because there was so much to do, and there was only one of me, and so I was able to work on those projects, which was actually, of course, what enabled me to be in a strategy and ops role later and then eventually as the chief of staff.
So the chief of-- esque projects helped with that transition. But when you ultimately moved into your chief of staff role, Box is a big company, right? So the scope was obviously massive.
You've got in the engineering department over a thousand engineers. You're on a team of seven.
What does a chief of staff kind of actually do at that scale?So what's fun about operating at that scale is I sort of thought of it like running a small business in many ways because you're supporting an org of, like you said, almost 1,000 people.
I was running a team of seven, and so my job was really to help connect the dots across every part of the system recruiting finance, comms, of course, strategy and ops, and nothing really lived in isolation.
Any small misalignments can compound very quickly.
And so a big part of my role was, of course, that high-level thinking, asking the right questions, but then actually working with the leadership team to answer the questions. So it's not in the abstract.
So you're thinking about what are the priorities for this year? What are we building towards over the next five years? What are the headwinds?
And then this last question is one of the most important ones: Do we all share the same understanding of the answer to those questions? And like I said, this isn't abstract. This is very operational.
And so once you set up the team to answer those questions through... You know, we did stand-ups with the leadership team three times a week, quarterly off-sites.
I was building workshops to surface that alignment and agreement. And once there's clarity there, you actually shift into execution mode, and that's where real concrete plans happen.
And I was able to leverage my strategy and ops team to roll a lot of those changes out.
So whether that's redesigning the planning process, or how employees are onboarded, or building new dashboards to surface the right data so leaders can make better decisions.
So at that kind of scale, a chief of staff isn't doing everything, but they're really designing the system so the org can move coherently and at a high velocity.
Talk to me a little bit about the chief of staff org at Box. So you were one of a few chiefs of staff, right? That's right. What did relationships look like across the company?
Were you one of the first or were others hired kind of around you as the position was gaining more momentum? How did that look?
I think the eng org was maybe the second one to have a formal chief of staff, and then the function started to build out across the company.
The relationship and structure of the chief of staff looked super different across different orgs.
I think that's true of a lot of chief of staff functions at different companies, but even within Box, it varied a lot just because it's based on the size of the org, who the exec is, and what they actually need.
And so in some orgs, you had a chief of staff with a super large team. Others, there was no team at all. Others, the EAs were rolling up into them. In other places, it wasn't.
So it varied a lot, but I would say that the thing it had in common was we were all really focused on making the org operate as smoothly as possible and being the right hand to our exec, and the way that played out was just different based on the needs of each team.
So did you work with any of those chiefs of staff more closely? Since you were on the engineering team, I assume maybe the product chief of staff. Exactly.
The relationship between product and chief of staff is super, super important because it's really two sides of the same coin.
So we worked very closely together, and I think that a lot of our responsibilities overlapped, and so what was important for us was figuring out where was our dependencies and where could we operate independently.
So one example of a really dependent process that we had would be annual planning, and so this was something that, of course, product owns strategy, and eng owns execution and resourcing, so we couldn't work in isolation, and so we would really co-create that process to make sure that we were asking for the right information from teams at the right time so that we could get to where we needed to be by the end of it.
But then there were other projects that had less dependencies on each other, where we could delegate and work more independently and just kind of consult and approve with each other something like an OKR process, which is pretty standard.
So one of us could work on that and then share it across and make sure it worked for both of us, but move a little quicker that-- and when we could kinda delegate like that.
Something that we did that I thought was pretty effective was we would do what we called a two-by-two every week, where we would have both of us and our principals in one room together to review our deliverables, pressure test anything that would cut across both teams, like a new planning process, and having that joint work reviewed quickly would help us fix problems more proactively.
That's a really interesting format because, you know, often you have kinda those two principals getting together, maybe in an executive team meeting. Hopefully, the chief of staff is included in those meetings as well.
But it's a really good point to say, "Hey, why not just put chief of staff and principal, and chief of staff and principal if there's multiple, together on a recurring basis?"
Because that is how you get not just the broadest view of the landscape of the company, but also sometimes that ground-up view, you know, where you, the chief of staff, are kinda spending additional time with the principal who frankly just doesn't have to really understand the context of why teams are working a certain way or how teams are responding to certain decisions, or if communication has gotten lost somewhere in the shuffle.
Exactly. I have to ask because he's a good friend, did you know Connor Sweeney? Did you all cross paths at all? Oh, yeah, of course, I know Connor. Yeah, he was great.
He was our, I believe it was HR and finance chief of staff a couple years back. Yeah, that's right. So Connor was one of the first members of Chief of Staff Network.
I've learned a lot from Connor over the years, so yeah, good to know. How many chiefs of staff were at Box now? Do you know offhand? We've got maybe around ten.
There's a chief of staff to the CEO.Sales, marketing, HR, finance, eng, product So pretty much every division? Yeah, pretty much. Pretty much Cool.
I think we're seeing obviously more and more larger enterprises hire chiefs of staff across the board, and that's not just at the executive level, that's also sometimes at the VP, even director level.
And so I think kind of where the role is heading, we will see more stories come out about how chiefs of staff work together and, you know, what the context of those conversations and the mixing and matching of principles looks like as well.
So always interesting to hear kind of those stories.
I know we wanted to talk today a little bit more about this notion of, like, being an operator but also a PM and, you know, you're coming from kind of working with an engineering team, obviously working closely with a product manager.
You shared an interesting analogy with me in our first call about walking into an emergency room. I wanna dig into that a little bit.
Talk to me about what it means, th- this ER analogy as you kind of compare the operator and kind of PM mindset. So I like to think about this analogy of if someone walks into an ER, what do they see?
Because it's usually a very chaotic place with problems to solve, and so what you see and what kind of problems you're picking up says a lot about your natural inclination and mindset towards solving problems.
And so I think about if an operator walks into an ER, what do they see? They're looking at inefficiencies. They're seeing three-hour wait times. They're thinking about how do I reduce that wait time?
Where are the bottlenecks? Are there too few staffs doing intake? Are there too few doctors? Are there not enough beds? Why is this happening? Or is this a problem where patients aren't getting through?
Is staff having a hard time coordinating? Is that because of bad documentation between shift workers?
And so an operator is really looking at problems in the system and trying to figure out how to make things move faster, be more stable, be more safe, be more predictable, especially under pressure.
I think about then a PM walking into an ER, what are they thinking about? They might be looking at, "Oh, we're actually solving the wrong problems here. There's a ton of minor cases showing up and clogging the ER."
They are questioning if the system itself is structured to meet the needs. So they might be thinking about, "Okay, I'm seeing all these minor cases.
Maybe we need to create an urgent care zone so that there are fewer minor ER cases coming in in the first place.
Maybe we need to have something more upstream," because they're noticing people in the ER don't actually need to be there, so maybe they're just anxious and need reassurance and so maybe we can have something upstream of actually even going into the ER to help you figure out if you need to be there in the first place.
And so a PM is approaching the problem in a really different way, and they're thinking about it kind of outside the boundaries of the system. And one is not better than the other.
They're both incredibly valuable skills and very hard, but I just found myself leaning a bit more into that creative problem-solving, which felt more like a PM lens.
Do you see cases where a chief of staff has to kind of put on that PM hat to say, "Hey, look, we built the system this way, and I'm recognizing all the inefficiencies in the system.
Now how do we step out of our comfort zone, out of the normal way of doing business and go do it better?" And AI is an obvious use case for this, right?
Everything is being shaken up, not just business models, but entire products. Do you find yourself kind of wearing both hats as a chief of staff? Yeah.
I think a good chief of staff is sort of the ultimate generalist, right? Where you do have to think really creatively at the same time as being a real operator.
I think depending on the scale of the organization will depend on how specialized you get with what you're doing.
I think in smaller companies and smaller orgs, the chief of staff role tends to be one where you do have to be a lot more creative and push the boundaries more.
Whereas at larger orgs, you're more focused on kind of fine-tuning the system. So I do think the kind of company you're at demands something different of you.
But definitely as a chief of staff, I found myself doing that creative problem-solving and being excited by it, which is why I wanted to do more of it, where I thought I could do that in a product role.
That's a very fair distinction.
The size of the organization definitely is a huge determinant in terms of, like, what a chief of staff's mandate might look like and whether they're, like, working in the business or working on the business.
I've always looked at kind of the distinction between product manager and chief of staff, and I agree with you that they wear very similar hats most days, that the PM is really focused on, like, drilling into a specific problem and, and sometimes the narrowest sense.
And the chief of staff is, like, almost the PM of the organization in some ways.
And so, you know, while the chief of staff may be spending a lot of time, like, working inside the company, very often they're working on the company, right? Like, how does the organization live and breathe and grow?
Not just the things kind of within it, the product, et cetera. But I think there are obviously a lot of similarities between kind of these two paths.
When did you kind of realize that you wanted to be the person, let's say, redesigning the system rather than just tuning it? I think I realized this before I actually made the PM transition during a hackathon.
So I joined a small team during one of our hackathons a few years ago with a couple of engineers, and at the time our idea was how can we query videos with AI the same way you can documents and text.
And I thought this was a super cool idea.And I worked with a small team of engineers to build this hack. So you would upload a video and be able to ask questions on it the same way you would a Google Doc.
And we actually won the hackathon, and I loved this idea and this experience so much it almost felt like cheating to me.
There was kind of this moment of disbelief where I was like, "Wait a second, I can just come up with a cool idea, work with engineers, and talk about it, and then it just becomes real?" And it kinda felt like magic.
This was just a very validating experience because I realized how much energy I got from building something new like that. It also sort of clicked for me on a personal level.
When I was a little kid, I wanted to be an inventor.
[laughs] And so I would carry around this little red notebook, and it was my inventions notebook, and I would just look for different problems and create little products and inventions and design solutions for them.
So I remember one rainy day I was holding an umbrella, and I had my raincoat on, and it was super cold, and I thought, "What if the umbrella could actually emanate heat and so I wouldn't be cold in the rain 'cause I'm already holding this thing?"
Obviously, there's a lot of holes I could poke in that design, but I was always just thinking of ways to solve problems like that.
And then I realized at a tech company, the closest thing to being an inventor is being a PM. Yeah. And obviously the PM is nothing without an engineer or a good AI agent at this point.
It's interesting how you kinda made the leap because you're coming from, you know, chief of staff of an engineering team.
You obviously had a lot of exposure, as we talked about, you know, to the chief of staff for the product management team, but I'm assuming to the product managers themselves as well even before that hackathon experience.
Talk about the transition period. Was this a conversation that you were actively having with your principal?
Was this something that you had an eye on and you were looking or waiting for kind of the right position to open up? Did a project jump out and you raised your hand and kinda jumped on it?
What was actually kind of that transition for you? For me, I always knew that there was gonna be something after chief of staff.
I think there's a lot of chiefs of staff who are career chiefs of staff, which is an incredible path, but I knew for me there was always gonna be something next.
And so I had had my interest in product for a while, and it was something...
I think, you know, every person is in charge of their own career growth, and so it was something that I was definitely proactively bringing up with my principal.
And because I was interested in product, I was able to lean a bit more into that and do things like participate in our hackathon and be more proactive in designing our planning process, which includes what are we asking PMs to show us when it comes to evaluating ideas.
And when I was able to help architect those processes, it helped me learn a lot about what it takes to be a good PM, and I was able to learn a lot by being in the room with our product VPs, and that was a huge advantage for me.
So it was something I was able to observe a lot because of my position in the org, and it was definitely an ongoing conversation, and I did have to sort of wait for the right role to open up, but when it did, because I had started those conversations early, it felt like a really natural transition.
It's an excellent call-out that you got to learn from some of the more senior people in the organization because you had access to them by way of being the chief of staff and being present in those rooms.
And, and I'm sure you built up a lot of trust along the way as well on various projects you were probably leaning in on. When you moved from chief of staff to PM, what changed the most for you?
Obviously, with chief of staff role, you get a lot of access, right? You get really wide purview of the organization.
You get, you know, access to some of the most senior leaders of the company and the behind-the-scenes look of the decision-making processes.
That can feel like a real loss, almost like a step back when stepping into maybe on the seniority level, like, still the same sen-seniority but a lot less access, if you will, across most of the things happening in the company.
What did that feel like? What was the biggest change?
I think the shift in altitude is definitely one of the hardest parts of any transition out of the chief of staff role, but it was also something that I anticipated and was actually seeking out because I wanted to sharpen my skills in terms of how do I advocate for my ideas and align leadership towards my strategy kind of from the ground up.
And so when you're chief of staff, you're usually working on ideas that are already blessed, and so you don't usually have to question as much, "Should we do this? How do we execute, align?"
Communicated is more what you're focused on, and so you're operating with a lot of air cover. And when things get messy, you're kind of downstream of a decision that's already been aligned on at, at the highest level.
So I was interested in what happens when that flips. And so when you're a PM, you're on the ground, and your ideas don't come pre-approved. You're actually usually the one. You have to create the conviction.
You have to fight for your ideas. You have to pitch why something matters, why it matters now, why it deserves resources over something else.
And that means that sometimes good ideas don't go anywhere because you don't have the right timing or you don't have the right narrative.
I guess what surprised me about this was, yes, at first, this can kind of feel less powerful, right?
But, you know, you might be facing more friction or more rejection, but over time, it's actually way more rewarding because you're forced to sharpen your skills around storytelling, around judgment, and you don't proxy for authority.
You really have to earn it. And I think that when something finally lands, it's because your ideas are winning, and that is super rewarding.Yeah.
It's an interesting distinction between the two roles and, and kind of the proxy for authority, as you just said, is, is one of the biggest.
Leading without authority as a chief of staff, I think is one of the tougher parts of the role, and certainly things like storytelling and navigating without influence and [laughs] you know, you having strong communication skills is important as a chief of staff.
It might even be more important as a product manager, because as you get really deep into specific problems, you're fighting for time and attention now for a team that, like, directly responds to you, right?
Your engineers, your other PMs, which is going to... In a tech-focused product, like, is going to ripple across the entire company what those decisions actually entail. So really interesting.
I know that product management was not kind of the first thing that you were thinking about. You were actually thinking about marketing. Talk to us a little bit about kind of that decision.
Why did that end up being kind of the wrong choice for you? If, if wrong is maybe too strong of a word.
I'll preface this by there's a lot of different ways to navigate careers, but one of the things I think you hear a lot is, you know, follow your passion.
But that advice, I think, misses something really important, which is that I think it's more around following your skill set and thinking about where you can make the most impact.
And so I was considering marketing a while back. I thought it was super interesting.
But when I stepped back, I realized that there was a lot of distance between where I was and what it would take for me to be really effective, and there was maybe a big learning curve.
It took a long time to build credibility and took just a long time before I was able to contribute and have a lot of impact.
And so I think that when you're making a career transition, building momentum is really helpful. And so when you're able to move faster and more confidently, you're able to compound your impact and strengthen it.
I think Scott Galloway talks about this a lot, where it's, "Don't just follow your passion, follow your talent."
And so when you're anchoring on what you're already really good at and just sort of building adjacently, the transitions feel less like starting over and more like an evolution.
Unironically, I was just listening to Scott Galloway before this episode. [laughs] He's great. Yeah. Let's put these two roles head-to-head, chief of staff versus product manager.
Who is the ultimate generalist in your opinion? They're generalists in different ways.
[laughs] So I think that one thing that I didn't expect about being a generalist as a PM is how often you have to think on multiple time horizons at once.
And so in a single conversation, you might be dealing with a production issue that needs immediate fix. You might be building a roadmap for the next quarter.
You might be doing long-term platform planning for something that might not pay off for years. A lot of times, these priorities will directly conflict with each other.
And so a PM is a real generalist, I think, because they have to think on so many time horizons at once.
You have to optimize for not just a single moment, but things over time, and you're constantly going through questions around, "What do I have to build today so that things don't break in the future?
And what do I have to build in the future for things that don't have to paralyze us today?" So a lot of mix of, you know, judgment, context, restraints.
I think that PMs are generalists also because they don't have to know about everything, but they're just bringing coherence across a lot of different decisions, timelines, incentives with different experts across the field.
They're pulling the whole system together in that way. Chiefs of staff, I think, obviously are generalists too, but I think that it's a little bit more heavy on the people side of being a generalist.
You have to have a really good sense for how each function is working, how the people in each function are working, and leverage those individuals, whereas PMs are more generalists in, you do have to have skill set knowledge across design, across engineering, across marketing and be able to pull those in together, versus I think chief of staff have to be kind of more people generalists.
That's fair. It's broader scope. Chiefs of staff, I think, need to have a better sense of, like, organizational behavior, how are teams cooperating or not cooperating well with one another.
And then especially as you get into, like, more senior rungs of leadership, how are those folks working together, and how does that behavior trickle down or impact the rest of the company?
Everything from communication styles to just, like, interpersonal relationships, the chief of staff is very much at the whim of kind of [laughs] the principals that they're reporting to, and that obviously affects the entire organization.
And so that impact comes from kind of understanding the behavior and being able to help change that along the way. That's quite different from a PM, again, who's, like, a little bit more in the weeds sometimes. Exactly.
There are, like, very clearly transferable skills here.
What do you think you took from your chief of staff experience to your product management experience maybe that other PMs come in a little bit shorthanded with, or, you know, what kind of prepped you well for the role that you're in today?
I think one of the things that surprised me that translated was around problem discovery.
I think it might sound initially counterintuitive because a chief of staff, especially in engineering, is not customer-facing in the classical sense, and product obviously is.I think I had this light bulb moment a few years ago.
I was talking to a sales leader. I was curious about sales, and one of the first things he said to me was, "You don't have customer experience." And I remember thinking, "Of course I do.
They're just not external customers." And so as a chief of staff, you absolutely have customers too, right?
They're your execs, they're your teams, they're your cross-functional leaders, and you're chartered to solve problems that are mission critical, and the expectation's the same.
You have to understand the problem quickly, you have to solve it well, you have to make it stick. The same thing applies in product with customers, right? So the mechanics of this problem discovery are super similar.
Whether the customer is internal or external, the job is you have to show up very open-minded. You have to not assume anything. You have to get past the initial symptom into the root cause problem.
I really love the five whys method for this. You just have to keep digging until you understand the problem underneath. And of course, the context is different between a chief of staff and a PM.
The market dynamics, the stakes, the scale, everything about that is different, but I think that the core of the skill is the same, which is you have to get clarity in an ambiguous situation and really ask the right questions to your customers.
You've also said that a chief of staff kind of writes the organization's story, and we talked a little bit about this, right? Kind of working in or working on top of the business.
And the PM is obviously responsible for writing the product story. Can you unpack that a little bit? Are there clear distinctions between the two? Does there end up being some overlap?
As a chief of staff, you're helping shape how the company understands itself, how what they're working on matters, the trade-offs that leadership is making, and translate that into alignment across teams.
And so the story is about building context for the team, helping people all move in the same direction without needing every single little detail.
As a PM, you're responsible for making the product feel like a coherent system. So even when it's built across multiple teams, service areas, you have to make it all make sense.
And especially in an enterprise team, which is where I sit, you have to connect your enterprise products with everything else: with security, with AI, with governance. These are not distinct products.
They're not adjacent to each other. They're all connected as one, and that's actually how your customer experiences it.
And so when you're building one slice of the product, you have to connect it to the workflow of the customer and how your product fits into the life cycle of the product and how they're using it on a day-to-day basis and how it fits into the broader story of the whole product to make the customer's life better.
And I think especially in an enterprise settings, the customers don't just buy features, they're buying trust. And so trust comes from building a really coherent story.
The PM is narrating that story and building that trust with the customer to make sure all of the parts of it are working coherently together in telling that story.
Since the chief of staff role is so tied to the principal and the PM role is obviously tied to an engineering team, but also more broadly, like any customer-facing team, what does it look like in practice kind of managing those relationships?
Like the chief of staff has really one relationship that is the most critical to them, and then everything else is, you know, I won't say secondary, but less important in terms of prioritization.
The PM has kind of a lot more people banging on his or her door saying, "Hey, I need this done. I would... You know, this customer wants this. This internal customer needs this."
You're building both internal products and external products. How have you managed that shift?
Before, when I said, you know, the chief of staff's priorities are the principal's priorities, full stop, I think as a PM, your priorities are your business metrics, full stop.
And so you have to think with your big business hat on, and your principal is the business.
And so of course, every PM has their specific scope and their specific charter, but at the end of the day, you're in charge of moving metrics, whether that be new ARR or retention or stability of your system.
And so you have to be laser-focused on those outcomes.
I think in order to do that, something that is a common thread is you have to be a bit of an emotional buffer in both of those scenarios, where as a chief of staff, you know, you're kind of a buffer to your executive.
And by that, I mean you're helping absorb pressure and noise so that only the most important problems get surfaced.
And so you're filtering noise so that every issue, every escalation, every kind of half-formed concern doesn't make it to their desk.
And the same thing is kind of true for being a PM and you're a real buffer to your engineering team.
I try to really provide air cover so that all the kind of customer noise, escalation, shifting demands aren't pushed down to the team right away.
I'm able to provide clarity and a clear point of view on what actually needs to happen and what's important so that they can focus on actually doing their job and building.
And of course, something I actually do really like to do is bring engineers into customer conversations when I can, but you have to make it really thoughtful because their time should really be focused on building.
So yeah, I'd say in both roles, you do have to act as that emotional buffer, which isn't about hiding truth, but more around deciding what matters when it matters and filtering it so that you can help your team or your principal stay most effective.Yeah, I love the parallels.
For chiefs of staff considering moving into product management or maybe other business operators, other generalists, let's say, you've said that, you know, it's obviously very difficult to map your career ten to fifteen years out, but you should have a sense of the kind of problems that you wanna solve.
How do you figure that out? I think there's a couple of things. So yeah, like you said, things change so quickly. A lot of the jobs that we have today didn't exist ten years ago.
So instead of focusing on the career title or the ladder that you're trying to jump, think about the kinds of problems you wanna solve, and that's a lot more durable of an anchor than any sort of specific job title.
When you know what kind of problems you wanna solve, what gives you energy, what kind of challenges that you're willing to sit with over time, that is a really helpful base for you to work off of.
And so that comes from actually, I think, looking backwards more than looking forwards.
And so it's paying attention to moments in your career when you felt deeply engaged and really energized and think about when that happened, what were you doing? Were you untangling ambiguity? Were you aligning people?
Were you fixing something that was broken? Were you building something from scratch? And finding this trending pattern is really telling. And I think that under pressure, people really reveal their defaults too.
So think about times when everything was a mess and problems were undefined. What were you actually excited to do? Where were your natural inclinations?
Think about the kind of friction that you're willing to tolerate because it's not always a question of necessarily what do I enjoy, but what is the kind of hard that's worth it?
And so sometimes there's political complexity or technical depth or consensus building, and what are the trade-offs in those difficult moments that you're willing to make?
And that'll help, I think, with the strong internal compass that'll point you towards the problems that stretch you in the right ways.
And that is something that's stable even when the landscape of your career is changing. For our listeners right now who are PM curious, what should they do this week to start testing the fit?
I would say the goal isn't to make a decision, but it's just to run small experiments. I remember talking to a brilliant career coach a while ago, and she told me this story.
She had a goal to get more in shape, and she was super intimidated by that idea.
And so what she started doing was she would just put on her workout clothes, she would drive to the gym, and she would sit in the gym parking lot for ten minutes, and she would drive home.
And I love that story because it's just a really good lesson in baby steps.
And yes, eventually she got to the gym, and she was lifting weights, but you don't actually need to go ahead and do something really big right away. You just have to make small steps to move in the right direction.
And so what does it look like to run a small experiment about being a PM? I think the first thing is you could just pick one problem in your current role and approach it like a PM. And you could write a product spec.
Who's your user? What problem are they experiencing? How would you solve it? How would you know if you've solved it well?
And just write a one-pager and see if that exercise energizes you, and that's a really good signal. The other idea would be if you can shadow product thinking.
So not just product meetings, but actually sit in on a customer call or a roadmap review and listen to how decisions are getting made. What's the evidence that matters? Where do trade-offs show up?
How is uncertainty getting resolved? And ask yourself if that kind of environment is motivating or if it's draining to you. Another idea is if you're in proximity to a hackathon, hack.
This was how I learned I loved product. It's a really good way to just test if you actually like having an idea and solving it with-- directly with engineers.
Of course, there's also so many AI tools right now, so you should definitely experiment with just building something super small. Use Lovable, use Cursor.
Actually, just design a mock product and see if that's fun for you. Yeah, if you run these small experiments, just pay attention to your energy. Did it excite you? Were you curious?
Did you keep thinking about the problem after you solved it, or were you really relieved to put it down? You don't need a grand plan yet. You just need to run a little experiment and see if you like it.
That's the fastest way to kinda test a fit. I love it, Sarah. Small steps for the win. Sarah, thanks so much for joining us today. Really great conversation. We learned a lot from you. I appreciate it.
Thank you so much, Scott. I really appreciate everything that you guys do. I, I learned a lot from you guys when I was chief of staff myself, so it's cool to be here on the other side. Thanks a lot.
Thanks for passing it on. That's a wrap on today's conversation with Sarah. I hope you got as much out of it as I did.
I think the thing that's sticking with me the most is this idea of following your talent over your passion and just how much the chief of staff role actually sets you up if you're intentional about where you want to go next.
The ER analogy, the idea of running small experiments before making a big leap, the parallels between serving your principal and serving your engineering team as a PM, all really good stuff.
If you wanna connect with Sarah, you can find her on LinkedIn. And if this resonated with you, share it with someone who's in a chief of staff role or who's thinking about entering a product management position next.
We'll see you next week. [upbeat music]