How to Navigate “Growing Pains” in Scaling Orgs

Read The Transcript:

We're trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn't correct 100% of the time.

Hannah Clark: Ah, growing pains. I'm sure we've all heard one parent say to another, "if you think it's hard when they're little, just wait until they're teenagers." And frankly, that's as true of startups as it is of children. The challenges don't get easier, they just get more complex. In fact, scale-ups tend to have a lot in common with teenagers. They're constantly outgrowing things, they're still figuring out who they are, and they're not quite mature enough to have a firm grasp on things like realistic goals and how to reach them.

And don't get me wrong, I'm not knocking them because ultimately, this stage isn't a failure, it's a rite of passage. Reaching that teen stage of maturity is a signal that things are moving forward as they should. But being responsible for that growing org is not for the faint of heart.

My guest today is Matt Wensing, Head of Product and Design at Customer.io. Before joining Customer.io, Matt has worn just about every hat in the product leader closet. He's founded two startups and held leadership roles at several others, so he's had plenty of time to observe and deconstruct the ways that scaling orgs navigate the long and awkward transition period from early stage to mature enterprise.

You'll hear what experience has taught Matt about the connection between high level strategy and frontline leadership, why your org's actual capacity is probably much higher than you realize, and how to turn a cycle of endless failed experiments into an engine that actually powers sustainable growth. Let's jump in.

Oh, by the way, we hold conversations like this every week, so if this sounds interesting to you, why not subscribe? Okay, now let's jump in.

Welcome back to The CPO Club podcast.

Matt, thank you for making time on your Friday to talk to me.

Matthew Wensing: Thanks so much for having me.

Hannah Clark: So can you tell us a little bit about your background and how you got to where you are today at Customer.io?

Matthew Wensing: Sure. I joined Customer.io eight months ago now. And when I initially joined, I was technical director, was the title on the engineering team.

Really part of a small team with the CTO and another technical director looking at how AI could be used throughout the product and platform. So really AI innovation. Before that, I had started a startup. Ran that for five years, had raised some funding. It was a low-code, no-code startup, so a lot to do with marketing automations as well.

And then prior to that, the previous 15 years, I started a startup out of kinda my first or second job outta college. I decided I wanted to do one of these web 2.0 things and started a startup that was the first interactive maps on the internet that had weather on them or the first interactive weather maps on the internet.

And that was a really interesting ride. We ended up going out market and selling of all things B2B SaaS for supply chain, and did that for quite a while and really have done, had to do as a founder and have done pretty much every role from engineering to sales.

Hannah Clark: I remember when that came out. That was crazy.

Wow. Okay. Well, what an honor. I'm learning things and I'm becoming more starstruck as we get talking anyway we won't be talking about weathers and maps and that kind of thing. We're gonna be focusing today on what it's like to lead and manage products in this. Very tricky stage. I feel like we've all had this experience of being in this between stage of startup and scale up when things are really starting to ramp up and things start to go off the rails.

So in the past, we chatted before and you talked about Customer.io as being sort of this frontier town where it's past the wild west kind of startup days, but not quite into fully established city. So, in your experience, what are some of those key leadership challenges that really emerge in this specific stage of maturity?

Matthew Wensing: I think it depends a little bit on how you got here. There's a certain amount of culture that you bring into that situation. Where is everybody on the same page or is everybody understanding that? We are in this phase. We're not a city yet, and by city, to extend the metaphor, those are the places where you go and everyone has their box.

You know where to get your mail. Everything's delivered a certain way. And the thing I say internally to the folks that I work with directly is in this phase and this in-between phase, you have two jobs. One of them is your core job, the function that you perform that creates value for the company and the business.

But the other part of your job is figuring out the best way to do your job. And you might even say to figure out what your job is because you have a title, and that title is probably the umbrella over the core of your focus. This transition phase. If you come from the earliest days that this, figuring out what I should do today is the most of the job.

I mean, I would say that's 95% plus of your job most days. You're really just making it up as you go. This is a bit in between and you can end up hiring people who are used to the Wild West, where they're figuring it out every single day. And then you can hire people who are really, you could say, leaning into the future and saying, I'm even more comfortable the more established it gets.

And I think it's just important to recognize and for each person to know that, hey, that feeling you're feeling of not knowing for sure if the thing you're doing is the right thing. That's actually part of the job and that's normal. We want your help in figuring out the full definition of your roles and responsibilities, and that's how you participate in building the company you wanna work at.

Hannah Clark: Oh, that's an interesting take. I feel like it's a question that tends to linger, that doesn't communicate it often between leadership and ics. So, that's interesting that you point that out. I wanna dig a little bit further into that, if that's okay. So when you're working with, say, a new hire, for example, that's come onto the team during that stage and like maybe you're building their job description out or getting a sense of what their main contribution to the company needs to be, how does that ideally need to go?

Like where do you see the, the boundary between how much the IC should be participating in their, just kinda dictating what their role should be versus what leadership should be dictating to them.

Matthew Wensing: If you can tolerate more metaphors.

Hannah Clark: Oh, I love them. I love them.

Matthew Wensing: Yeah. The way I think about these early hires, and by early I mean less than 500 people, which means each department, if you break it down, you could all fit into a pretty big room or an auditorium together and you know everyone's name.

You're under that Dunbar number where you know every single engineer by name and you know a little bit about them. So it's still small compared to a large company scaled. And in those situations, if I am leading a group like that, I try not to make many assumptions about how the future's gonna unfold, what their full scope of responsibilities are gonna be.

We're trying to ultimately get as much contribution out of each individual. We're trying to give as much individual as much opportunity. As we can. And in that case, there is a job description as you put out in order for them to respond to and join the team. But what I will often do is initially you're trying to learn how this person works and what they're comfortable with.

And I like to start with, and this can happen in a period of days. This doesn't have to take months. In fact, when you're at this stage, you can't take. But you really try to figure out what is the most ambiguous direction that this person can comfortably work under.

Hannah Clark: Oh, interesting.

Matthew Wensing: Not because you're trying to be ambiguous, right?

You actually, if you're interfacing, say if you're reporting to a VP or a CPO or maybe the CEO, depending on where you are, the direction you're getting is often extremely high level.

And it's because those people have such a wide purview that they have to be extremely parsimonious in how they share direction.

So we need to do something about X. What I try to do initially is say, okay, I'm not gonna put this person into a box or create a ceiling on them. I'm gonna take what I just got given, and I'm not gonna just pass it along as is. I'm going to bring it down one level into make it a little bit more concrete, put some boundaries on it, but not much more because ideally they can run with it.

And I like to see how people run with or don't run with that kind of direction. And it's very interesting to see what the follow through or responses are to that. I think you can learn a lot in, like I said, days, not weeks, in terms of how people handle that kind of direction. And again, you're not abdicating your responsibility, but what you're looking for is this a person who can thrive with a lot of autonomy?

Or is this a person that actually needs more supervision, more management, more clear direction and boundaries in order to thrive. And you need both kinds with an organization, but you can either frustrate or you can really dishearten a person that needs one or the other if you don't test for that.

Hannah Clark: That makes sense to me. I think that's, I actually feel that's a really good indicator for a strong leader to have that kind of emotional intelligence to get a sense of, like how. Be able to read someone's ability and comfort level with a level of ambiguity and kind of see and be perceptive to how they kinda rise to that occasion.

I kind of wanna take a little step back here and I apologize. I'm throwing you a curve ball because what this is making me think of is. The role of strategy and how it evolves from that really early stage startup as you start to get more mature as an organization. And I think this is an area like where we're talking about deployment of personnel and that kind of thing and how that kind of can be so individual.

But I, I see kinda a pattern of strategy being a little bit more, it gets more complex, as when you're a small team, a strategy can be really just an action plan. And then as you get bigger. The components of a strategy become more diffuse across different organizations and it becomes more challenging for someone kind of in senior, but not, executive leadership or a director level to interpret that strategy and kind of be able to fulfill their end of it, especially in a remote organization where people just aren't quite communicating as fluidly as they would be in maybe in an office situation.

So what have you seen in the field as far as managing the role of strategy in terms of deploying and translating a vision into actual outcomes.

Matthew Wensing: What I've learned is you cannot afford to play the game of telephone with strategy. And what I mean is you really need to have that the spine of the organization, meaning there needs to be continuity and to end in terms of, maybe there's a few gaps or levels between.

This manager and the CEO or this VP and this director, but you can't afford to have that understanding. Shared or communicated in a low fidelity way between those participants. So what I mean is you should be able to draw a line from sort of the lowest level manager all the way to the CEO of conversations that have happened where that understanding really got cemented by in between those people.

Let me tell you what's the opposite of this is. So the anti-pattern would be, here's this vision, here's this understanding. This is our strategy at a very high level. So maybe it's the company strategy. We want to be the greatest X. Insert your company here. That's often the kind of thing that comes from board to the CEO.

And then maybe the C-level socializes it a bit. And then one failure mode would be you then convene your S team, 'cause we want to imitate Amazon in this case. And we say, okay, here's our strategy. And you just hand it out to each person and you say, go implement this, or go run with this, make this real in your world.

And you will essentially create a gap in understanding where the way it gets carried out. Then on the ground, it doesn't end up looking and feeling the way that it was intended to, because people will interpret things. Change is hard, right? And if that strategy involves trade-offs or hard decisions, or we're gonna focus on this customer instead of this customer, if you really haven't cemented that knowledge between each level of the chain.

You will end up with reinterpretations that happen along the way. That end up accommodating certain realities on the ground, such as. Well, Bill's not gonna be really excited about this because this essentially puts aside the project he's been working really hard on for the last year. So I'm sure I can figure out a way to work this in here and have these be compatible.

And what you end up doing is you can end up creating what I think of as think of it as. If anyone's a Star Trek fan, the Borg, it assimilates, right? Yeah. It synthesizes things. It absorbs things, and what you end up doing is you have a strategy at the top that is extremely, maybe it's more disciplined or it's part of what makes, I almost said strategic, right?

What makes a strategy strategic is that it forces trade-offs. It makes hard decisions. It says, we're not gonna do this, we're not gonna do that. The sign that you haven't done the cementing as I call it, is that. Somewhere in the chain, someone goes, it must not mean that we can't do this, or we must be able to also accommodate that, and they will glom on, or it becomes the sticky ball, right?

Where there's really nothing that isn't in play anymore. It's, of course we wanna do this. And that's how you know you haven't done this part. This part is the people really coming to grips with what this says we're not doing.

Maybe anymore, or we're not gonna do instead of this. If that person understands that, then there's an accountability chain as well.

It's very hard if you don't have that come to grips with moment. I think especially for remote teams, this is easy to skip, is did that person really go away? Understanding the trade-offs and what we're gonna have to give up in order to do this. And I think that's how you prevent that. But we can also do this of course, right?

Or this doesn't say that we can't keep doing this.

And then you have a leader that goes, how come we have the strategy? That we're only gonna do this and we're gonna focus on this. There's the word, right? Everyone wants focus. We're gonna focus on this. But then when I'm looking at how we're spending our time, I don't see that focus.

And it's because somewhere along the way that chain got broken and someone assumed that it didn't mean that we can't also do these other things. Right?

Hannah Clark: Yeah. Okay. This makes sense to me. And I think part of why I asked this and why that kind of came to me as we're talking about folks sort of choosing their own adventure, so to speak, about how they can contribute best to the company.

I think that when we misfire in that area, that tends to be where work gets duplicated or people who are well-meaning tend to spend time serving the strategy to their understanding. And then we get some breakdown in terms of, again, what's the right process and how do we really show value or present value if we don't have a very clear picture about the scope of our.

Influence within that bigger picture. And that kinda leads me into when should we introduce process versus maintaining this kinda like startup agility. Like I feel like this is just a constant struggle. Like how do you make a judgment call about avoiding this chaos versus death by committee kind of battle?

Matthew Wensing: I like to introduce process on the heels of success.

So something worked, I think of process and I was explaining this to somebody earlier this week. This gives a helpful way to introduce process without even using the process word, is I like to think of process as it is writing down a story of what success looks like.

That we want to repeat. So you say, wow, that call between product and sales went really well. That call where we got brought on to have that conversation, that customer went really well. It wasn't written down. There was no process. Thank goodness we have some people on the team who can just leap headfirst into those situations without a playbook.

And have it go well. And maybe we've tried it three other times that it didn't go well and this time it did. Writing down the process is simply then saying to the company, Hey, here's what just happened. This was awesome.

So let me tell you why this went so well or why I think this went so well. It went so well because first, Glenn and I got together and we did this, or the next thing we did is, Sam and I did this.

You just tell a story of the success that you had. And naturally, people want to imitate. Success process is really just a way for people to imitate a successful story, and therefore everyone wants that, right? Yeah. And it's what salespeople, when people are on their, educational products or info products, right?

What are they selling you recipe for success. And a lot of those obviously are not real, a great manager. Calls a timeout or notices success and says, how did you do that? Please write it down and teach it to the team. And then I like to separate. So that's the process is just repeating the story.

I like think of ops. Ops is also extremely helpful. Ops is a way of saying that is the story we wanna have at. We want these three people to get into a room together and reconcile why this thing wasn't done on time. Not in a bad way, but in a good way. That's a healthy conversation. We need to have that.

How often should we have that? Yeah, I think we should have that at least every couple weeks. Great Ops, can you help? Yes. Ops comes in and says, I'm going to essentially create the structure, the context that allows us to repeat this. And it seems really simple, but this is the part about saying out loud what otherwise is just assume.

It's very easy for a less experienced manager to assume that, hey, they had success. They're gonna do that again. They want that to happen again. I think this phase is about. Saying, Hey, write that down, share that story. And then, Hey, ops, how do we try to recreate that success? Let's get them in a room. How long should the conversation be?

What's the agenda? And before you know it, you have this process, but everyone sees the value because it was organic. You've productized essentially a human interaction by just starting with a story.

Hannah Clark: Kind of the takeaway that I'm hearing here is that as opposed to thinking about processes strictly a checklist or just an objective, you're thinking about.

Ops is developing that sort of process guide, but what we really need to be thinking about process as sort of like the beats of the story. Okay, what beats did we have to hit for this to have happened? Yes, for it to be replicated. And then from there, that's your. Outline, and then from there to create like a repeatable process when ops comes in, that's more the checklist, izing of things like the actual, the things that can help you scale, the things that kind of help you to standardize something.

As invariably your team grows or people turnover.

Matthew Wensing: Ops makes it manageable, right? Without ops, you're not tracking it you're not measuring it. Ops is what lets you go. Oh, so that means we could have up to this many beats per whatever with this group. This, and I love your beats analogy.

I just have to say that to me is the story is the movie. The beats are the scenes that you need to create. And if we don't have this scene, if the scene doesn't happen, the story falls apart and everyone wants to be a part of that.

Hannah Clark: Yeah. Well, everyone wants to be in a good mood.

Matthew Wensing: Yeah, that's right.

Hannah Clark: Okay. Let's talk a little bit about because you'd mentioned, creating process out of success, but success also creates problems. And so if we think about the ways that companies tend to attribute sometimes their wins to the processes, but maybe it was more due to, the timing that their product came out or the market fit, then they happened upon how do you separate, what is actually working?

How do we verify that this process is functional rather than it just happened to work at the right time.

Matthew Wensing: That's a good one. I think you're getting, I mean, this is a fundamental fallacy or one of the fundamental fallacies of people is you're misattributing results to a certain way of doing things.

And I think to some extent, congratulations, you're succeeding, which most people don't get to that place. And I think Customer.io for sure where I work is at the place where it's working and that's awesome. What you have to be open to. I mean, unless you have a group of people who just love attending meetings and process, and most people don't.

You are going to end up with feedback on is this working for us or not? I do think that there's a time for kind of molting, if you will, in shedding those processes that got us to now, but won't get us there. And I think you can. These are even the good ones. So that story worked when we only had one product manager and three salespeople.

It doesn't work anymore. I think if you don't have that operational mindset. You will just coast into those and before you know it, people will start to say, I don't really see the success. The success is not coming out. We're still doing the behavior, but I don't see the success there. I think what you're talking about is almost the world where we continue to have the same level of success and we're going through these motions.

There's worse problems to have in the world. What I think people are really worried about is we're starting to see the top of that S-curve in terms of. Things just don't feel as quick as they used to. Or decisions are taking longer than they used to, or frustrations will start to come out. And I think that these are the gear shifts or the metamorphosis or these moments in time where it takes a deliberate action on behalf of the leadership team to say, it's time to reorganize.

It's time to reboot or refactor the way this is working, it's not working anymore. And there's a certain founder mentality or there's a certain. Pioneer that you need mentality in those cases to say, Hey, the well that we have, it's not gonna work. That's not gonna get the population has, we've, it's outlived its purpose and there is a moment there where you have to be willing to remove the well and replace it with something else.

And that's risk. There has to be a certain amount of appetite for risk that says we don't wanna lock in our gains at this point. And I would say a technique that I've used in terms of. Having this conversation with people where it's already working is you say, okay, put aside what's working. What are our aspirations?

How big do you want this to get? And most of the time people will not say, oh yeah, I just want it to be like 5% or 10% more than we have today. Most people, if you ask them, where do you want this to really go, they'll share something very grand with you, and then you have that new. Vision or that new version of the story where you go, okay, so you can see how a well isn't going to, like, how is that gonna work when we have 20,000 people living on this street?

Well, clearly it's not right. And so if you want to get to that, if those are your aspirations, we have to take more risk. And how much risk a company's willing to take internally is unfortunately not something that any one individual can decide. That's where the senior leadership has to come in and really.

Have that grounding conversation again and say, if our aspirations are to be a public company, or our aspirations are to be this, we've got to take more risk. And then letting yourself wipe the slate clean in some cases, or reboot what you've been doing that got you here and say, this isn't going to get us where we need to go next.

But I think just being sensitive to those frustrations and intellectually honest with the results you're getting. And then thirdly. Can we actually get to where we're trying to go? Using what we're using now? And this all comes down to the right people. And answering those questions honestly is itself a challenge. But that's the job.

Hannah Clark: Yeah. Well, okay, so this is making me think of this let's say. Thing that happens sometimes where when we decide to change course, the company is scaling, we decided that whatever processes or something needs to be replaced. We tend to look at bigger companies, larger companies, more successful companies as sort of like our North star.

How can we copy and paste some of their playbook and replicate those results in our own organizations. But of course, like those can also be subject to the same kind of stipulations of maybe they, yeah, right. Time, market fit, et cetera. How do we evaluate or how maybe, how specifically, how have you evaluated what practices that we borrow from big company playbooks are worth adopting?

Matthew Wensing: I think in those cases, the best scenario is you bring in a leader that has lived and done that before, elsewhere, and you dramatically reduce the risk that they copy the form but not the substance of that. Because they know. They know that if you were on the outside and you had your understanding of Apple, you thought that it was just Steve Jobs walking around and telling everybody what to do.

What you don't know is we actually had these conversations like this, and these used to take hours and we would do this and that. And what you find out is that the fictionalized or the depiction of that. It's so superficial because everybody wants to believe that if you just imitate, you can have, and we just talked about how that mimetic nature internally can be used for good to replicate success.

It can be used very dangerously to try to imitate success as external to you because the amount of information that you lose by observing across and even reading business books, or a really inspiring blog post. There's some weird things here too to consider that's maybe the company's doing that because they have to, because it's compensating for a weakness that we don't have.

There's all kinds of reasons why people do certain things, and if you. Assume the reasons you can end up in a dangerous situation. I think OKRs is one of those that is, this is a great example of there are so many implementations of OKRs and we all know them, but finding somebody who's done it before and then can build a department and do it the same way they've done it and hire people who have done it that way.

That's one thing. An excited CEO or CPO reading a book by John Doer and saying, we need to do OKRs too, and then trying to implement them for the first time. It can work, but just consider that. What you're doing is you are experimenting. You are trying to figure out if this imitation is the solution for your problem.

Do you even have the same sets of problems that they had when they started to adopt those tools and those rituals and you don't know yet. So it's okay, try that. But somehow you need to try it with a very light hand or grip on it and say, if this doesn't work this quarter, if this doesn't work, this sprint.

We are not going to stick to it because it's not about our ego, it's not about our pride, like we're gonna try it and see if it helps. So I would recommend those things in very small doses with a light grip, unless you have someone that's lived it and can really tell you the inside story of, we tried those and this is what didn't work.

I'm gonna do it the way that I've known has worked before. And also, I'm gonna hire the people that work this way because. If you could hire someone from Google that's familiar with OKRs and if this person uses them at a completely different company, even that might not be compatible. So I think there's a lot of danger there.

We know that. I also think that it's worth trying. We don't need to learn everything over again ourselves. There are certain risks that we figured out how to avoid. Just be careful.

Hannah Clark: Yeah.

Matthew Wensing: In terms of that.

Hannah Clark: I'm gonna press you a little bit more on kind of a related angle here. I like the way that you mentioned using a light hand when piloting tactics or strategies that.

You're not a hundred percent sure gonna be compatible with the mission. I have seen the opposite extreme of that, of what I would refer to as too much too fast and not enough time. So how do we avoid the issue of perpetually being in an experimentation phase, but. Managing our timeline so that we can really evaluate the outcome.

I've seen this happen across many organizations and with people that I've spoken to as well, where it's we tried this experiment. It's almost like we have a 10 step experiment. We get to step three. Leadership gets concerned that it's not giving us the results yet that we're aiming for, and then we decide, you know what?

Nevermind, we're gonna go back to step one on a different experiment. And it's like we don't ever get that real learning from the payoff.

Matthew Wensing: Yeah. And this is true. Even if it's this is a pattern of how do we learn and test. That's true. All the way down to the feature level, right? And all the way up to the company As product and product, product as product.

I have adopted a technique. The technique isn't new to me, so I'm a big fan of the observe, orient, decide, act framework. Food loop, which is really just a way of, and I use this all the time in life. This helps me in my personal life, even of saying we've got to split the observations from the orientation around those observations from the decision about those, and then from the actions.

And I'll also say there are failure modes, and you just described one, which is if you take a single letter out of that. Equation. There are the companies that just observe, and they never decide anything. And what you just described is a company that maybe observes, does some reasoning around those observations and then makes a decision to just go a different direction and kind of starts over.

You want to make sure you go through all of those, and we can certainly talk about what all those are, but it's tough. Organizations are only as strong as the leaders that. Get to run them. And so I don't know necessarily what to do if leadership doesn't do these sorts of things, but what should be happening is someone needs to say, I'm going to lay this out and if everyone else is too busy, this could be a special assignment of someone where as the company, I like to say the Jane Goodall approach of, I'm going to go observe.

I'm the ethnographer of the company. I'm gonna go talk to everyone. I'm gonna observe, I'm gonna study, I'm gonna write everything down. I'm gonna be a scientist. Right. Capture that and then lay that all out. And if you lay it out in a certain way, if you can really split out the observations from the judgements, and I see this fail a lot in terms of people who are frustrated and say, we shouldn't move on to the next thing next, right?

They'll lead with that. They'll say, here's 13 reasons why we shouldn't do this next, and people immediately put up their guard in defenses to that because you've, you're treating it like a court case, and as soon as it's a court case. Where I'm going to show that my client is innocent or why that person's guilty, people put up their defenses.

I would highly recommend a more scientific approach where you say, I observe this, I observe that, and you can catch yourself. If you get good at writing this way, you will catch yourself halfway through a sentence about observations going, that's not an observation, I'm making a judgment. Or that's actually like I'm thinking about the observation.

If you can come and lead with observations, people's minds will open up. A lot more because now they're almost eager to know, I'm seeing the same things you are. Right. Because you've left that part out. Take me now. Okay. Why are those observations there? Oh yeah. I believe that too. Yeah. That's this way because we did this and that's this way because he did this and then you finish with your, and so we should recommendation or decisions.

Very helpful technique in terms of writing more persuasively internally, and sometimes all it takes is this kind of, Hey, the pen is mier than the sword, right? All it takes sometimes for those of you who are in those situations, maybe aren't the senior leader. If you can lay that out in that way, you might be surprised at the kind of impact that can have where the right people reading it in the right ways, and there's a lot of management there of making sure that it's received in the right way.

But those are very, those are powerful. Companies can sometimes. These are groups of people, right. Group dynamics are real, but leading everyone through that thought process takes a very disciplined approach to laying the information out, and I don't think it's practiced often enough.

Hannah Clark: Yeah. Okay. Again I wanna reiterate what I'm hearing here. Like the takeaway that's emerging from this for me is, it's silly to, to reframe it like this because what you're saying is you should treat experiments as experiments. Yes. Which sounds obvious, but I think it's not obvious because oftentimes experiments are treated like coaching conversations or vague guidance.

It's kinda like we should try this. And someone takes that as a marching order. And I think that's, it's really the communication breakdown and kind of the failure to treat it like an experiment in which, if you say we're gonna run an experiment between a group of leaders versus we're gonna run an experiment around a group of researchers, they're gonna think very different things with regards to what you just said.

And I think what you're saying is you gotta think about it like a researcher would say, we're gonna communicate about what exactly we are setting out to do. We're gonna set benchmarks and timelines according to what we're going to try, when we're going to reevaluate, and we're going to be researching throughout the whole thing, right?

We're going to be making observations and communicating about what those observations are. What I'm hearing is probably where a lot of this breakdown is happening is that there is no real management of the experiment. And so it makes sense why there would be frustration between the leader saying this isn't working, and then you know, the managers or ics, et cetera, who are trying to, work on that experiment going, well, hold on, we're not finished.

And so who would've thought experiments should be treated like experiments?

Matthew Wensing: Yeah. I will say I have a strong belief that we adopted as product people. We adopted the whole lean startup methodology. So I know Eric wrote that book in 2007. It was amazing. It was amazing. At the time, I think it was so amazing that a lot of us adopted scientific language.

We learned to, once again, imitate the craft of being scientific when it comes to business and validation and feature building and product development without the discipline of, okay, I can say we're gonna test this. If I say, Hey, we have this idea for a feature and there's three ways we could do it, I really believe that we have to have include this deep research function, which is gonna be a lot more expensive to build.

And so we're gonna test that theory by first releasing a version. That's where we do that manually. And see if people like it or not.

There should be red flags or alarm bells or whatever it is. Butterflies going off in your stomach right now if you think about it, because what I just did, I'm not testing the right thing at all.

What I should be testing is. This is really expensive. What we should be testing is can our customers live without it?

But I use language of experimentation and fooled you into thinking that I was being scientific. Now obviously, maybe I didn't actually, but like this happens all the time in product management where someone will say something like that and be like, yeah, we should do it manually.

'cause then we're not really productizing it, which avoids that research and like we don't have to build it yet. That's lightweight. Yeah, that's smart. That's a good experiment. That's a terrible experiment. All you're gonna get is the person going this is awesome. You're like, yeah, we thought you would think it was awesome.

Oh shoot. What were we testing again? You weren't actually testing the thing. You should be testing. You just tested. Do people like the thing that I think they're gonna yeah, don't do that test. Can they live without the thing that's really expensive that we hope we don't have to build because we're not here to build really cool stuff.

We're here to build a business and if that business is more profitable and can execute faster, because we don't have to build certain things. Let's not. And so I think that intellectual honesty or that, are we really experimenting? It is a pervasive thing in our zeitgeist as product people to be using words like this.

But we didn't really study the book. We highlighted the book and started using the language and. We weren't mentored about how to actually apply those principles. So if that's you, we've all done it. But see if you can catch the next person that you're working with saying words like experiment and test and theory and hypothesis, and see if they're really testing a thing that, wow, if this ends up being false, I'm uncomfortable because I thought it was gonna be true, but I'm willing to test if it's false because that would be better for the business.

What we like to do is we like to put our opinions out there and test and see, can I find validation for my opinion? That's my test.

Hannah Clark: Yeah. It's like how can we put AI into this product instead of how do we solve this problem?

Matthew Wensing: That's right. I have a strong opinion that we need to do X, therefore we're gonna do some cheap version of X. And when people like it, I'm gonna get to show all of you that I was right.

Hannah Clark: Yeah.

Matthew Wensing: That's the actual thing going on behind in our minds. And science and ego don't have a lot in common.

Hannah Clark: Oh, that, that's a quote. I think that this whole conversation, a lot of it hinges to decision making. So you've seen the evolution from founder-driven decisions to more distributed decision making.

Organization grows, decision making power changes. What's your approach to finding decision rights and ensuring that everyone's got the right context to make good decisions within their capacity?

Matthew Wensing: I think it goes back to what I started with is you were sending out feelers all the time as a leader, as a manager to understand.

How much context can this person handle and what do they do with the autonomy they're given? I used to manage developers and I had a scale for how autonomous is this developer, and you could work your way off that ladder starting with, do I know what code to write? If they need help with that, then they're junior by definition.

That's okay. But they're an associate in that sense. Up to the level of I know why we did this work, and I know how it fits our strategy. That person is the person who you're hoping you hired or found. Maybe you know that you hired The other one. Where I'm going with this is, remember I said at the beginning, you're testing to see what level of ambiguity it can handle.

I also like to test how much context can they absorb? Are they taking full advantage of all the information that's being said on all the meetings, all the calls, and all the notion docs and all the strategy docs that are being written by the CEO in our mandate? Are they starting to find discrepancies between things where they're going, I was reading this and I was reading that, and these kind of don't agree.

These are good signs. If you find someone that notices the wrinkles or the air bubbles in your strategy or in your thinking, they're paying attention, right? They can reconcile things, and that means they're ready to work at a higher level. The other tests I like to run is when you give them something, Hey, we need to make it over that lake.

Do they disappear from view run? And suddenly you hear a splashing sound and they get, there's a bunch of screaming and stuff, and then maybe they come back half torn up and they bring you the thing that was on the other side of the lake, and it's okay. You did it. Thank you for doing it.

Or do they disappear for half a day and then come back and say, so I took a survey of the lake and I wanted to understand, when you say we need to get across it, are you intent on crossing it at the widest part? Is there a reason that we need to do that? Or can we cross it over here? 'cause we can cross it over here.

Now you found someone who knows how to take that autonomy where you gave them the room to go do all of that, right? You weren't checking in on them six hours later saying, Hey how are you doing? But did they know enough to run a survey first? Did they know enough to say he can't really meet? I see alligators in there.

They can't really mean that I should just swim across. I should probably grab him on Slack and say, Hey, I took a look. Quick look, and this is what I found. As a senior leader, you are not necessarily looking for someone who throws himself into the water kind of thing.

Hannah Clark: The Labrador Fever approach.

Matthew Wensing: Yes. Super heroic, super friendly, your best friend in that sense, but painful from a cost standpoint, and that could lead to some bad outcomes. And I think the thing is this, if this is you, if you're the, if you're that person who's reporting to someone knowing this, there's a, I think, and I know 'cause I've been there, my first jobs.

They're in your gut. You're like, I don't wanna bother them. Like I don't wanna seem like I don't know what to do. Don't worry about that. If you come back with smart questions, having done your research, having taken it down the field, if you will, and saying, Hey, I wanna understand a little bit better why you think we should do this, what, et cetera, et.

What you're doing is you're giving them the opportunity to give you a little bit more clarity, give you some boundaries, explain why they were asking for that. All these things which you should not be making assumptions about, don't make assumptions about. Just 'cause they didn't say it yet doesn't mean they don't have opinions.

And I've seen a lot of failures in that case. So back to your question, if you do this right and you find someone who uses their autonomy wisely and can work their way up that ladder, it can absorb a lot of context. Now you know who you can trust with localized decisions. Because you can truly delegate and say, in this case, I don't have to be in all those details.

But if you don't do this work as a leader, if you don't test, if you don't give them the opportunity to fail, you won't discover. And then as a leader, you're not gonna know how much capacity do we really have because. I'm holding back on delegating because I haven't really tested the resources that I have, but if you test them, you'll find out, and if you don't have enough of one kind, you can augment.

If you don't have enough of kind of another, you can fix that too. But I think distributed decision making is the dream, but if you haven't done the research on who can handle it and who can make a better decision than I would have had I done it myself, then you're just flying blind. Then you're just hoping that they make great choices and that's where you get the chaos.

Hannah Clark: What I'm hearing here is and I also tend to think that sort of compatible with this theory is that most people have a lot more capacity within their existing headcount than they think because...

Matthew Wensing: Absolutely.

Hannah Clark: ...you're not doing that investigative work or that collaboration to really discern what someone's true capacity is and what their capabilities are to operate within that scope.

It sounds really like you have someone in mind when you're saying this. I do wanna say, before I ask you further, this actually reminds me a lot about an episode on systems thinking that we recently did with Sheryl Cababa, because what you're describing to me sounds very much like the systems thinking mindset, which I think is, I'm sure that it can be trained, but I think a lot of people tend to be very just adept at that kind of ability to hold a lot of context at once and be able to work with it sort of simultaneously to find win-win situations. So for anyone listening who wants to dive further into that, we did that a few weeks ago, it was a great episode. It puts it all into perspective. But I do wanna ask, do you have an anecdote or an example of somebody who really embodied that trait that kind of stands out to you when you tell us this?

Matthew Wensing: I'll use a friend of mine. When I started my first company, at some point I needed a director of marketing and he joined me, having been a consultant at Deloitte and was really good at that job. And crushed it and it did all the things that consultant needs to do. One of the job interview questions was like, Hey, develop it.

And I didn't know much better. So I didn't ask the best questions when I was interviewing folks at that point. So I said, yeah, develop a go to market plan or a marketing plan for us. And back came like this 15 page Google doc of here's the go to market plan, and I think I still have a copy of it because we ended up working together for 12 years after that.

I still have a copy of it somewhere, which is like the classic case of. He got a direction. Now, it wasn't an interview questionnaire, so he couldn't really do a back and forth, and he just blew it out of the water. Right. The reality is we didn't end up using almost any of that because two things.

One, it was a startup, and two, we didn't have that collaborative conversation. Later on, he became extremely good. He's now making a career out of working for C-level execs or next to executive vice presidents, et cetera, high level senior level execs and saying, I heard you say this. And what he was doing by the time I worked on him through two startups.

By the second one, I would say something on a 30 minute call on a Friday. He wouldn't even ask me about it then, and he wouldn't do anything else with it other than he'd write it down and on our Monday morning call he'd say, I heard you mention this on Friday. What made you think about that? Like, why did you do that?

And so when I share these lessons with you, I'm actually, I'm sharing the lessons that he learned by working together with me. We learned by working together on two startups that he got better at not running with those things, and I got better at appreciating. I'm glad he didn't just run with it because that, I didn't even know enough to tell him at first, so.

Those are the anecdotes. I like the funny one. By the end of it, we had such a great working rhythm in that sense where I could trust him with extremely high level direction and then I would know he was gonna, we were gonna work it through together and then he would run and perform at a very high level.

But one last tip, if you do this, I think a lot of managers. Come from the wrong direction. What I mean is you start at the low level and you say, ah, I have this employee. I hired them to be an ic. They're a product manager or an entry-level product manager. I'm gonna give them this and I'm gonna see how they do, and then I'm gonna give 'em a little bit more and see how they do.

You're building up what you think is their capability level. That is a very slow path to discovering their ceiling, right?

Much faster is to challenge them with something where if they succeed, they have shown you that they are six levels bigger than you thought. And now you can meet them there, you have now leapt there.

The only risk is that they screw up that one task that you ask them to do. And again, you might discover this in a week, but how much better to discover in a week that they're capable of knocking something outta the park that you think they can't handle than to spend six months on this thing level and then six months on this level, and then six months level that's the slow path to discovering who your top performers are.

If you as a leader can find things that are challenging but low risk if they fail. Because what happens otherwise is they leave. You're like, oh, okay. They left. I didn't really think of them maybe as a top performer. Then they go join some company and they're like leading some huge initiative and completely crushing you go, what happened?

It's like they were always that person, you just didn't discover their ceiling and you can discover this. There's a lot of different ways to do that aren't necessarily live fire exercises. They're gonna cost your company a bunch of production costs, dollars, karma credit, et cetera. But I think it's the opposite direction that most people start because they think about the ladder.

I wanna make them climb the ladder. I would say I'd rather give them the chance to grab the top one of the higher rungs and if they can reach it, fantastic. You're looking for those kinds of people?

Hannah Clark: Yeah, absolutely. Well, at the very least, you've stretched that person and help them develop and create a trajectory for their development. Another one of those things that's it sounds like it should be so obvious, but we don't see that happen in practice.

Oh, Matt, this has been a phenomenal conversation. I've learned a lot. I appreciate your wisdom so much. Where can folks who are also appreciating your wisdom right now find you online?

Matthew Wensing: If I'm online at mattwensing.com is where I have a bunch of essays that I've written over the years. You can also find me on LinkedIn, @wensing is my handle. But you can just look for Matt Wensing there and I'd love for you to connect.

Hannah Clark: Awesome. Well, thank you so much for making the time and yeah, hope to talk to you soon.

Matthew Wensing: Thanks for having me.

Hannah Clark: Thanks for listening in. For more great insights, how-to guides and tool reviews, subscribe to our newsletter at theproductmanager.com/subscribe. You can hear more conversations like this by subscribing to The CPO Club wherever you get your podcasts.