An org-design masterclass from a Square GM | Saumil Mehta

Brett Berson: As we were just talking about a second ago , off camera, we have tons of stuff that we want to get into, but wanted to spend a decent chunk of time talking about org design. I find it's not, it's not something that's open sourced and discussed a lot. It's one of those things like when you're running a business at scale, that you have other friends that you're comparing notes who are running other large orgs.

Um, But it's a lot of one-on-one conversations and a lot of what we're trying to do with this is kind of open source, those, types of discussions And maybe just wanna start super broad and then we'll narrow as we go. But interested to get your kind of, sort of high level thinking to start around org design and maybe some of the stuff that you figured out in the context of Square that sort of drives the underpinnings in terms of what is the point of org design, what does it look like to do it well, and sort of those types of things.

Saumil Mehta: Yeah, it's interesting. I mean I had spent 10 years of my career, the first 10 years of my career working at small early stage startups and then spent the last seven kind of working at Square, watching it scale being a part of that scaling journey. And one of the things I learned along the way is that org design is effectively one among several tools in your management toolbox in order to drive change, in order to drive progress, in order to drive a roadmap, and in order to drive a P&L. and treat it no differently than a tool in the toolbox. Use it appropriately. And if you're gonna use it, use it well and use it properly. And one of the things I learned by talking to lots of friends, watching stuff get evolved internally doing several org design changes. Reorgs myself at Square is I realized that I had learned a lot of things from the folks around me, especially our CEO Alyssa.

But I needed to actually write it down in one place in order to make it more effective for myself or to make it more effective for the people that I manage who are going through their own org design conversations or peers who might be doing something similar. 

And I narrowed it down to six principles, right?

Which I think are helpful as a frame for how to go about org design successfully. So, lemme just quickly outline them and I'll give a high level summary and then we can dig into whichever ones you want. So in the first one, and it sounds obvious, but it isn't, in practice, is that the first one is you have to have absolute clarity of goals and clarity of problem statements.

So, if we agree that org design is a management tool meant to solve problems, then the logical first thing you have to agree to is, well, okay, you are doing something. What are your goals? What are your problem statements? And what happens is that an individual manager decides to engage in some org design change.

Sometimes it's small, it's a minor change. Sometimes it's significant involving hundreds of people, sometimes thousands of people, and it's surprising how often they start the process. If they don't have goals written down, then they involve two or three other people. It's a small group working together.

And the group may have, every individual in that group may have different goals or slightly different stack ranks on the same goals. And so you want it written down because if it's not written down, you will actually wind up in a bad place. So what are you looking to solve, right? I mean, do you have a new thing that you're trying to accelerate by forming multiple teams around some new initiatives?

Do you have two to three related things in a large organization that have evolved and they're related, but they've evolved to become more related to each other over time, just organically in response to customer feedback you're trying to bring them together to get some acceleration. Do you have a leadership change that you're trying to effectuate?

And so all of these things are potential goals and all of them are perfectly valid. But if you don't have them written down in one place and you don't have agreement, Across the board that these are the problems we're trying to solve. You can wind up in one of these infamous, poorly executed, poorly communicated reorgs, which are unfortunately all too common.

I think that's the first principle, be very clear about goals. 

Second principle is separate design considerations from human considerations, and start with design considerations. Iterate with human considerations. What happens is that a set of people, one person, two people, three people say, Hey, we wanna do an org change, we wanna do this org design thing. And we think that it could solve these problems. And then all of a sudden the people who are actually responsible for executing it start to think about all the people who could get impacted or would get impacted. Then all of a sudden they're like, well, but you know, like this person, boy, like they're not gonna like this change. So now let me actually like, figure out how to solve for that, or boy, this person doesn't really get along with this other person and they don't have a strong working relationship, so, okay, that can't work. Let me actually change that. And what you see over and over again after having gone through this for years is you end up in this model because you're not particularly clear about the human situations, which always have an emotional valence.

Because these are people who report to you, or these are people who you report to, or these are people you talk to and you are theoretically trying to help them in their career path. And they may have expressed aspirations, desires, frustrations, challenges, and you talk to them weekly, biweekly. And all of a sudden that can just overpower everything else.

And so our principle is the first iteration that I wanna see in an org design. It's only gonna have boxes and arrows. I don't want to have any people names on it, like no people name, period. Show me multiple options, but never show me people names. And then we will iterate to something that is less purist and accommodates all the human aspirations and considerations.

But we're not gonna start there 'cause otherwise we're just gonna muddle things. This is the second principle. Third one is, if you're gonna do org design, you gotta end up in a place where all of these teams in your completed structure have charters reasons for being, that are explainable, first of all. So, uh, what you see in org design is people will construct these teams and then you wind up with a set of teams that like, literally you can't explain why they exist.

Because again, you're fitting product initiatives, cross-functional work streams, human beings, annual roadmaps that you may have set six months prior. And you put all this stuff together and you wind up with, we have a term for it. It's like, you always wind up with that one team.

That's the junk drawer team where you put everything in it. That had no other place. So one of our kind of little rules here is don't end up with a junk drawer team. Because that team is gonna be miserable, right? And like the manager there is gonna be like, why did you like give me this junk drawer team?

And the PM is like, I don't wanna work on this thing. Uh, 'cause it's a junk drawer. And so, so our goal is produce explainable charters. That actually are mutually exclusive, but cumulatively exhaustive. And so you can look at it, you can say, okay, like, show me your roadmap roughly for the next 12 months.

I can look at it and be like, okay, this has some coherence attached and it's not a junk drawer. So that's one of our core principles. 

Next one down is design for durability. Uh, So again, one of the reasons why org design has and reorgs have like such a bad wrap, and it's mostly justifiable in my opinion, is because people do something and then six months later they change their mind.

They're like, oh, by the way, we're doing another one of these. And that just, that's a way to lose confidence. That's a way to lose credibility. And so you want something that's gonna last ideally 12 months, 18 months, maybe in perpetuity, then the final thing I'd tell you about is, and this may be the most important one, is uh, be very, very, very intentional about comms. And there's a whole set of principles just around comms that you could follow and should follow, because it is all too easy to get everything right and and then do the comms wrong.

and you pay the price for it a year down the road. And so those would be kind of my chapter headers, if you will, for org design and reorgs.

Brett Berson: How did you end up on those?

Saumil Mehta: So the comms one is interesting. Like we did a reorg a few years ago. I was in charge of it. I was the DRI. And it was well intentioned. It was well planned. It had clear goals. We'd done a lot of work on it. And then we didn't quite nail the comms.

And I distinctly remember, the level of pushback and frustration we got. And then we managed through it. We got out on the other side, but then that was a moment of significant reflection for me where I was like, everything was right. Why didn't this go well? And the answer is, well, we could have done more on comms and we could have done more to explain why we did what we did.

And we didn't do enough there. And so that's the comms piece.

As far as goals again, at this point my role is mostly helping other teams and my directs think through their work changes. And I distinctly remember this about a year ago. We had three folks that were working on an org change. They've been together a long time. They all had the right general idea of why they wanted to do what they wanted to do. And we're talking, we're looking at initial proposals. And about three weeks in, I realized, oh my God, we have not written down a stack ranked list of goals anywhere.

So I said, Hey, why don't you all write down your goals, and let's talk about it. Turns out the three folks that were working on this together, and they've been longtime partners, all had slightly different goals, and even when they had commonalities of goals, they had different stack ranks. And so essentially that's when the light bulb went off for me and I was like, Hey, anytime I do this again, I'm gonna insist on having written goals upfront.

And so just through multiple iterations of doing these myself, helping other people do these, watching them go well, watching them go less well, I arrived at a set of principles where I'm like, if you do all of these, you have something that approaches a playbook that will maximize your odds of success.

Brett Berson: In, in the example from a few years ago, what did it sound like or look like in terms of poor comms?

Saumil Mehta: Some of it was just not having a detailed why that is easily explainable to lots of people. So one of the things that we try to do around comms is, you get asked why do you wanna do this? Totally fair. And you proffer an explanation and then people ask you three levels of follow-up questions.

And by the way, if it's a large enough group of people, they may have one forum to ask me, which is an all hands, but guess what? Two days later, there's two people who are out on vacation. They come back, they go to a one-on-one with their manager, and they start firing questions at their manager saying, Hey, why did these changes happen?

Well, the manager was not really involved throughout the process and was brought in with a day to spare. And so if you didn't equip that manager with all the right why's and the right talking points and all the FAQs, now all of a sudden you've left that manager, you know, in an awkward spot. Where now they are basically guessing, filling in the blanks, and now all of a sudden you have this kind of chain of lost in translation across people.

And so the thing we could have done better is been much more detail oriented around why, in a way that was public, in a way that was written down and in a way that was repeatable across the management chain. So you get the same answer from me but you also get the same answer from some manager that was brought in with a day to spare.

You don't get slightly different answers or meaningfully different interpretations depending upon who you go talk to. And so that's a lesson we've taken really to heart, we are very detail oriented about writing everything down in one place and then sharing it with the entire management chain as we go.

Brett Berson: What's the ideal setup to kick off a reorg? Like what are the indications that it might be time.

Saumil Mehta: So I would say, what you observe is you've got a company level strategy or strategic priorities. So for Square it's, and going back several years, it's omnichannel, international, upmarket growth. And then we did some stuff, we added another priority this year in flight uh, around generative AI.

And so you look at those priorities and you're like, okay, like where are my choke points where I feel like I'm not making the pace of progress that I could? And then you look at those choke points and then you evaluate each of those on the merits unto itself, you say, okay, like what is the situation I'm dealing with here?

Like, do I have a leadership issue? Do I have a personnel issue? Do I have a funding issue? Do I just have a clarity problem tied to the fact that I've got this one organization that's doing four things that are semi-related to each other, and the thing that I really want progress on is one of these four things.

And it's getting lost in the shuffle. And so what I need to do is basically pull it out and elevate it and make it its own thing. And once I make it its own thing, everybody else will understand it better, it'll be more visible. you know, the, the progress will be more apparent or not. Uh, and all of that's a good thing.

And if I do that, then I have a shot. I've done a reorg where we had a functional structure that we converted into a GM led structure. You know, and Square's been a GM led structure for a long time, ever since I've been here really. Um, and we always tell people, and I always tell people, it's like, any org design, it's gonna have goals, it's gonna have trade-offs, and it's gonna have compensating mechanisms. And you just have to pick what you're gonna achieve and how you're gonna solve for the trade-offs that come with it.

Um, And so I just made this change uh, a couple months ago. And essentially in that realm I was like, Hey, the functional structure has gotten us this far. It's got a lot of these benefits. And now in 2023, the trade-offs are basically bigger than they were five years ago. And the value that I was getting five years ago, four years ago, three years ago, is less than I was getting.

So now the balance has shifted in the other direction. Time to make a change.

Brett Berson: I think a lot about that in the context of every aspect of building a company. And it seems like our brains struggle with the fact that by definition, every system has benefits and downsides. And normally what I think our brain likes to do is when you notice a downside, you fix the downside versus in some cases, maybe just saying it is a downside.

And we're fine with that. And I'd be interested in hearing more about how you think about, maybe even the difference between a downside you're willing to tolerate, because the benefits are so worth it in the context of an org design versus sort of the type of downsides that you think about. You have to, as you mentioned, sort of compensating factors or you have to solve for in some way.

Saumil Mehta: Yeah, and it's, it's actually one step further than that. There's the substantive downsides and then there's the perceived downsides amongst the kind of general, team, right? The broader team, which over time is hundreds of people, thousands of people. And it's all filtered through their perceptions and their histories, uh, because they've worked in a particular org design.

A new thing could be completely foreign or vice versa. And so it's also filtered through their perceptions. So I would say that for us, the way we thought about it is, okay, if you have a GM led structure, and at this point we're large enough that like we have multiple GMs rolling up to other GMs who've got multiple GMs under them, you are gonna achieve some set of goals and you're gonna have some trade offs. So what are the goals you're gonna achieve? You are gonna achieve customer intimacy. That's helpful because Square is building this ecosystem of interconnected products and services underpinned by a common platform. And each of those products is frequently a standalone company out in the world.

And so we sell a marketing product. There's plenty of SMB marketing products out there in the industry. We sell an invoicing product. There's plenty of those out there. Obviously, there's plenty of point of sale products out there too. And so you look at it and you're like, okay, like I need some set of people who are fully dedicated to this problem area, to this job to be done. And in order to do that, I'm better off with single threaded leadership than not. And so you get single threaded leadership in a narrow and focused area for the customer. And you get that in a way that we have seen repeatedly is better than the alternative, which is a purely functional system with lots of, with these huge functional teams, and each of the functional teams focuses on one or more products. So you get that, you get a shorter escalation path on decisions that are going to unblock product development, and to a certain extent go to market as well. So if you are the GM for Square point of sale, for example, everything that is more narrowly constrained to that space, the escalation path is very short.

 Because if you have a difference of opinion between product engineering, design, data science, in square point of sale, those can be resolved with one hop. And you don't need to get four functional leaders. And those leaders and those leaders, you don't have this like long escalation path tied to those products and those P&Ls and those businesses.

So you get that, what do you lose? You lose some level of efficiency. And like we know that there is some level of inefficiency baked into the system. Because sometimes you may not, have the most efficient staffing model if you have multiple GMs. Uh, whereas if you had a more centralized system, you could do a little bit more load balancing, you could do a little bit more ruthless prioritization, and you're gonna lose some of that.

When you think about these types of trade-offs and compensating for them, or just accepting that they're effectively the cost of doing business in a given model, is that done mainly via taste, or is it mechanized or quantified? 

I think it's mostly the former. And we've seen over and over that there's not much of a substitute for good judgment and good communication, and these are things that we've to some extent actually discovered about ourselves as we've gone along, and gotten deeper and deeper into the GM led model and put more remit and more responsibility and more accountability in the hands of these folks. As we've seen these folks or myself included, for that matter, grow and evolve and scale into their careers and demonstrate improved judgment through their work and also through the mistakes that they've made or I've made over the years. And then we've said, okay, like here's the input we're getting from our team. Here's how we respond to it. And it's born out of like hard one experience.

Brett Berson: Maybe before we, we kinda keep pushing down sort of this track, you could elaborate a little bit more on what the GM structure is in the context of Square, maybe how the org landed on it and give it a little bit more fidelity so people understand when you're talking about GM structure, kind of what you mean.

Saumil Mehta: So to step back and to talk to you about what Square has been up to for the last several years.

We are building an ecosystem of products and services for businesses of all sizes, all over the world, to help them start, run and grow their business. And over the years we have built, this ecosystem of 30 plus products, uh, depending upon how you count, uh, that you could see on our website that are sold to our millions of customers across our eight markets.

And about eight years ago, when we had the beginnings of several of these products, they were very nascent. Some of them hadn't even launched yet. Some of them were maybe six months post-launch. We converted to a GM led model where there were a handful of GMs, who were gonna run, product, engineering, data science, product marketing, product design. And then over time we also added the creative teams into the mix. And then have a P&L attached for that particular product or set of products that they manage. And now they are responsible. For that P&L, they are responsible for the success of that product and the growth of that product, and the way they achieve the success of that growth of that product.

And that P&L, is through leveraging the team that they have primarily, which is again, product engineering, design, data science, product product marketing, um, and creative. And then secondarily through collaboration with centralized go-to-market teams. So some of the classical kind of go-to-market teams are centralized, for intentional reasons.

And so sales is centralized, account management is centralized, marketing is centralized. And so you've got a set of GMs that own a P&L, that own a set of products that have these teams in their remit as direct managers. And then you have central go-to-market teams, sales, marketing, account management, and then all of them roll up to Alyssa, who's the CEO of Square.

So that's our GM led model. You got a set of GMs, you got a small handful of senior functional leaders reporting to Alyssa, and then there's a cross in between them.

Brett Berson: So talk more about the centralized go-to-market function and, uh, how you ended up with that model.

Saumil Mehta: Yeah, so it's this, it's this classical balance between how do you be product first as much as possible, or P&L first as much as possible, while also having your kind of Square first hat. And so, we've spent a lot of time thinking about and effectuating the right balance between those two. And so the reason I would argue that it makes sense for all the go-to-market teams to remain centralized is because they can be completely Square first and they can optimize for overall Square growth, um, in a way that is effectively neutral. And so if you are our CMO, she is primarily gonna anchor on how do I help Square grow? How do I get our brand, our products, our services in front of customers in all of these markets? How do I attract customers to square?

And how do I do it in a way that is the most Square first way? I shouldn't need to worry about individual products or individual P&Ls. I should just worry about Square and the same exact logic applies from a sales perspective, which is, Hey, how do I basically drive success for square through sales, through account management, and do it in a way that's relatively neutral.

 And on the flip side, if you are the GM of one of these areas, you are gonna wake up every day and say, how do I evangelize this P&L and this product to everybody around me? And how do I try to use the data I have, the influence that I have, the persuasive powers that I have, the work that we're doing, most importantly, in order to convince everybody around me that they should prioritize marketing my product, merchandising my product, selling my product. And that's great and we want that. You also want the functional go-to-market leaders to say, boy, that's great, but I'm gonna optimize for whatever's gonna drive the maximum value for our customers and the maximum value for Square.

That intentional tension results, we believe in the best possible outcome because you have the level of focus that you want attached to individual products or P&Ls, but you also have kinda the square first mentality, that you want when you are presenting to the customer. And when you're trying to attract customers, what you don't wanna do is in essence, ship the org chart to your customers as it shows up on your website or as it shows up in the hands of a salesperson, because that could create all the wrong incentives that leave the customers worse off.

Brett Berson: On that point, how do you get around this issue where, product pricing and packaging, distribution, et cetera, are at times kind of this delicate dance? Where they all kind of have to fit together as opposed to like tossing a widget over the wall to the go-to market team, and some of the intricacies there, or this dynamic of where you have a GM focused on the needs of the go-to market team instead of the needs of the customer.

Saumil Mehta: Yeah, I think the former is a very active and ongoing topic amongst that entire leadership group, whether you talk to a group of GMs or you talk to the go-to-market teams, one of the classical kind of topics, that we've debated, talked about progress on, worked on together for my entire tenure here is pricing and packaging.

And the complexity builds in a hurry. For example, what sorts of pricing decisions are coupled versus decoupled? So if product A, which has its own P&L, decides or wants to bundle product B, into product A, how do you go about doing that? And to make matters more interesting?

A and B might have their own P&L too, by the way. So, so what we have found repeatedly, and this is true not just in this area, but in other areas, is we try to get a small group of people working at the level of principles. And we say, go out and write down principles that we are gonna try to hold everybody accountable to.

And so when it comes to pricing, years ago, um, me and one of my colleagues wrote down, A set of pricing principles, and we said, these are the principles by which we think about product pricing, and here's all the concepts you need to know, and here's all the ways you can assemble the Lego blocks to produce pricing and packaging for your product.

And here's some concrete recommendations and best practices that we'd love for you to follow. And then that's a living document that's been around for years and that's been read by all sorts of people who work in and around pricing. And that tends to produce outcomes that are closely related to each other, even though.

In theory we're decoupled. So I think you see that working at the level of principles can help teams achieve outcomes that are relatively consistent, through these cultural norms called principles. So that's a lot of what we've done. The other thing we've done is really encouraged this culture of open and frequent escalations.

And so you see decisions getting made. You see a team putting together a proposal saying, Hey, here's what we're gonna do on pricing. And then you see kind of a sister team saying whoa, whoa, whoa. If you do X, it's gonna have impact, Y and Z. Some of it positive, some of it negative. I'm gonna have kind of an open and honest escalation about this.

We're gonna talk about it, we're gonna try to see if we can resolve it amongst ourselves, and if we have an impasse, we are gonna kick it up and turn it into an escalation. And then we have mechanisms for actually creating escalations. We have mechanisms for resolving escalations. And so we've used principles and we've used escalations to try to achieve something that feels.

Consistent or consistent-ish, without becoming a complete choose your own adventure, which would be unsustainable. While also not forcing a central committee to adjudicate, because in general I want to see avoidance of central committees that like are in a position of kind of adjudication.

We wanna push decision making. To be as decentralized as possible. We want to be, have decision making spread throughout the organization as much as possible. We don't want the, ivory tower committee that hands out down a decision from on high. And we want it as decentralized as possible, but as principled as possible.

And that's why it's important to have these principles written down, especially on media topics like pricing and packaging.

Brett Berson: Can you give a couple more examples of, of what principles are in the context of your org?

Saumil Mehta: Yeah so, another kind of classical set of principles can be applied to, span of control and org design. Actually looping back to the prior topic, so how do you evaluate? The goodness of an org design. And there's many ways to do that, but one of the ways you can evaluate the goodness, of the org design is to look at, as you lay it all out, what are the spans of control at the different layers, right?

Like the manager at the top of this organization, how many directs do they have? What their directs group, how many directs do each of those people have? What are the ratios between PM and engineering once you lay it all out in one place? And so you look at that and we have written principles on how we want span of control to work in the context of org design, how we want ratios to work in the context of org design. And we can test against those principles, and we can measure even against those principles. And we do I mean, you know, this like this year which I know has been pejoratively nicknamed the year of efficiency, right? In our world. And one of the things you've heard CEOs talk about is, hey, What we've seen through this crazy hiring spree over the last four years is that you've got kind of managers reporting to managers, reporting to managers, and like four levels of the management chain, you're gonna have two people reporting to each other. And you look at it on an org chart and you're like, wait a minute, like, how is a senior leader ending up with only two direct reports?

 What kind of management job is that if you have two directs. And then those two directs have two more directs each, and those two have like 15 each. Like that's a weird org design. And something went wrong along the way. And so we have principles for how you manage span of control.

Uh, We have principles for how you manage ratios, and we have principles around pricing.

Brett Berson: In terms of the GM structure that you were outlining, can you talk about how you figure out what each GM owns? It seems like it's not just buyer persona or customer oriented and like how do you think about the territories and what makes the most sense?

Saumil Mehta: So couple things. So, so we have two types of roles, actually, technically. So one is general managers who are people who own a P&L, and are responsible for the growth and improvement type of that P&L. And then we have, what we would call multidisciplinary leaders, MDLs, and I think this is a common term in the industry at this point as well, which is you may be leading multiple disciplines, but you don't necessarily have a P&L attached. So that's the canvas on which we work. And we try to cut it a couple of different ways, when we try to set these up. So one kind of classical mechanism is we are selling a set of SKUs and we want related SKUs to be closely aligned with each other. So we've got two products.

One is Square point of sale, which is this horizontal baseline free, easy to get started, small business, mobile point of sale. And then we've got the equivalent of that for the web, and it's called Virtual Terminal. And it's basically, same thing, but on a website, for people who don't necessarily need the equivalent of a mobile app. Those two things are thematically very close to each other, and so they roll up under the same GM.

Then you may have, an individual product that's quite large, as a P&L and it's growing really fast. It serves a particular type of audience. And that's thematically coherent. So that's a GM role. So the dimensions we evaluate on our product or platform, and if it's product oriented, then that looks like a GM role.

If it's gonna be a little bit more platform or product platform, is what I would characterize it, that looks like an MDL role. And so we'll cut it that way. We'll create MDL roles when we believe that there are product surfaces that are reusable and to be shared. So we've got four different points of sale that we offer in the market today.

And those are four mobile apps, and you can download any of them from the app store, but they have a lot of commonalities underneath and they have a lot of meaningful differences. And so, what are all the common surfaces between those four? Well, those should be together because you wanna build it in one place and then you wanna reuse it in multiple places.

And so that looks like an MDL role. So you can cut it by product or platform. You can cut it by closely related products to each other. And then the third dimension by which we can cut it is horizontal versus vertical. So is this a product type that is gonna serve. Lots of different types of customers, whether they're food and beverage or retail or professional services or beauty and personal care or so on, or is this a product meant to be deeply oriented towards a particular vertical audience?

And if so, let's make slightly different decisions. So we evaluate across those three dimensions and we end up in a place that feels reasonable.

Brett Berson: Can you give some examples of, of what the GM ownership looks like today?

Saumil Mehta: So we have a GM for invoices, uh, which is a standalone product. It's a significant product for us. We've had it for going on 10 years at this point. And it is usually attached to our customer base alongside one of our points of sale. And frequently is also used just on a standalone basis. It may be the only product they're using.

So, large product is both used standalone, but also in concert with other products, has its own GM. Uh, we have a GM for Square point of sale which is kind of the baseline point of sale that I referenced earlier. We have a GM for Square for restaurants. Which is our restaurants focused point of sale. We have a GM for Square for retail which is our retail focused point of sale.

We have a GM for appointments, which is our beauty and personal care focused point of sale. We have a GM for Square staff, which is again, talk about thematic connections, of multiple products that are closely related to each other. These are all the products that are built for Square customers who have employees.

And so it's payroll, it's team management, it's shifts, and shift scheduling. It's HR services, it's team communication. So all of that is combined under one remit called Square staff with its own GM. We have a GM for e-commerce. And so what happens if you want to take your entire catalog, publish it online and sell online, whether you're a food business or you are doing restaurant pickups and delivery, or you're a retailer and you're shipping finished goods all over the country.

You need an e-commerce site to do that. And so that is used either on a standalone basis or in concert with one of our points of sale. And so that's a GM role. So I think at this point we have in the neighborhood of 16 of these in total. And I'm sure I didn't cover all of them.

​Brett Berson: I'm not sure that kind of fully clicked for me when you went through each example. 'cause it, it seems outrageously complicated. In terms of what should one o-, one GM own versus another GM. And so can you, maybe explain the, the, the principles or give one example of one of the GMs that you discussed that brings to life basically the set of principles that decides like who owns this new widget, if you will?

Saumil Mehta: Yeah. So, you think about kind of thematic connection to each other, right? So I'll give you two examples of that. So, hey, we have a set of tools that we are building or have previously built, that are targeted at Square customers, current and future who have employees. And we have a lot of solopreneurs who have no employees and we have obviously very large customers who have thousands of employees.

And so you have this whole range of customers you're serving, and it makes logical sense that you would have all of those products. Basically under the same GM's remit because when they are under different remits, you may have cognitive dissonance in roadmaps, so put them all under one GM, so payroll team management shifts, scheduling, HR services.

All of them are targeted at employees and employers who have employees. That goes under one GM. So that's an example of kind of audience coherence, if you will. This is targeted at sellers, with employees and for those employees themselves. So that's one way that that principle gets applied. Another version of that principle is, Hey, we've got this like very horizontal point of sale.

Easy to get started, free to get started, and it's supposed to serve all sellers, not vertically oriented. And we've got a version of this for mobile, and we've got the version of this for the web. And so does it make sense to have these two separated under two GMs, or are you better off if they're combined under one GM?

The answer to us is, well, they're both horizontal. They're both free, easy to get started. They belong under one GM. So that's the kind of horizontal principle at play at some level.

 And then the last one is just, this is a standalone product in the industry at large, and there are large incumbent, behemoth companies out there that run this thing as a standalone product. And this is an entire company outside of Square. And so that should have its own GM it should have its own P&L. It's already material today, or it will be in the future. And so that should have its own GM.

 So, Square for restaurants has its own GM. Cause there are restaurants focused point of sale products out there. Same for retail, same for appointments. And so you kind of combine these three principles and you apply judgment beyond that to end up where we've ended up.

Brett Berson: In the case of many of the GMs sharing the same customer, in some cases they have different customers, some, some cases multiple GMs serve the same customer, is it that GTM function that sort of acts as the governor across those product surface areas?

Saumil Mehta: Combination, so, so it's the GTM folks who are obviously Square first in entirety. And so that's a natural governance mechanism because they will optimize for Square first as they should. Then you have, the product marketing teams that frequently also serve as the glue because product marketing teams sit in between GTM teams and the product development teams.

 And so they serve as a bridge between the GM and the GTM functions, but also between each other. So they can also serve as a bridge between GMs, and so the product marketing teams. Across all of these GMs are continually talking to each other to try to coordinate, and find problems and solutions.

So you've got that mechanism as well. The third mechanism, quite frankly, is just GM to GM kind of conversation and escalations, because we use that to also kind of continually resolve, problems, but also find opportunities. Where we could be pairing together to achieve more for the customer. And so the GM of e-Commerce has stakeholders in Square for restaurants and Square for retail and Square four appointments because customers that are buying one of our mobile points of sale are very frequently gonna say, by the way, what's my online store gonna look like? Show me. And so that pairing has to be very close. And we've set those up intentionally and also culturally.

And then finally, the final governance mechanism is Alyssa's core team cause Alyssa's core team is gonna be someone like me who sits across multiple GMs, one of my colleagues who sits across multiple GMs, and then the key go-to-market leaders for all of Square. And that forum is also used to basically solve things across Square.

Brett Berson: How has your thinking on this topic, or you as a leadership team, your thinking changed in the last seven or eight years as you've grown and the company's grown?

Saumil Mehta: Yeah, I mean, so one thing that we've continued to do is to try to push decision making down through the organization. As much decentralization as we can find it, within reason. And then one of the things we've tried to do is encourage all the various cultural norms and practices and processes that we can come up with.

To provide that plane of coordination, as a mechanism to get teams working together. So classical example is annual planning, it's one of those things that is like, internally thought of as, oh my God, like annual planning's coming. Like people treat it like, oh my God, it's, I'm gonna like, like, I won't go on vacation for those two months in the middle. Like I refuse to go on vacation for that two month window. And I know a lot of people like that who will not leave their desks for that two month period, because they need to get through annual planning because, that is our mechanism.

For aligning hundreds of teams and thousands of people, across billions of dollars in gross profit on a one year time window. And so it's one of these concentrated moments of pain that you have to take on in order to actually get teams to work together. So one of the things that we've gotten a lot better at and evolved on is how do you manage dependencies across all of these teams?

So five years ago we had a common issue. Where you'd have two teams that would say, great, we're gonna do this thing together next year. And then one team shows up at the other team's doorstep in March and says, let's go. And the other team's like, call me in October, and now all of a sudden you've got this mismatch.

And so what we've evolved on is. We're gonna use annual planning and we're gonna go through a lot of pain and trouble together to get all this stuff lined up across hundreds of teams. So we know that we are not gonna basically hurry up and wait a bunch of people, nor are we gonna be super disruptive to the other teams where they're like, wait a minute, like, I had this plan and now I'm getting this inbound request for this other thing that I never planned for, nor knew about.

And now you're telling me that I gotta upend all my plans and start on this other thing. So that's something that we've really evolved on and iterated on over the last seven years. So decentralization, pushing down decision making, annual planning and dependency management. Increasingly working from a place of principles so you can actually achieve decentralization.

And then finally trying to find that balance point between being very top down, which is bad. And also being very bottoms up, which is also bad. And so how do you kind of find those bridges in the middle? And, and achieve that to actually move teams forward.

Brett Berson: If you believe sort of the classic Charlie Munger idea of incentive rule, incentives rule the world, how do you think about incentive systems in the, in the context of this structure and or organizational design more broadly?

Saumil Mehta: It's a great question. And one we've spent a lot of time on over the years. I think that old, kind of old saw of culture eats strategy for breakfast really applies here, where you wanna have a culture that prizes finding the balance between Square first and P&L first at different levels of the organization in order to actually make the whole system work.

So the general principle for us is that the higher up in the organization you are and the broader your remit, the more square first we want you to be. And so I've got across the whatever, 800 odd folks, six P&Ls, seven or eight different organizations at loose count sometimes. And you know, each of those GMs is pushing every day to drive their P&L.

And it's obviously, my job to support them, to advocate for them, to push with them, to push on them, to drive those P&Ls. On the flip side, I take very seriously that in my role reporting to Alyssa, working with the go-to-market leaders under Alyssa, I have to largely, if not entirely, behave in Square first ways and be a check on my own GMs essentially.

And on the flip side, I want them to serve as a check on me. And so my messaging to them is, You worry about your product, you worry about your P&L. You push as hard as you can with everybody around you, and I will be your governance mechanism if I see that you are basically taking it in a direction that is tipping the balance in the wrong direction.

Let me worry about that. I'll be there for you. And I need you to worry about your P&L and your product and to push me in the other direction. And so we want that kind of counter pressure between me and my directs. Same is true for my colleagues. They have that counter pressure between them and their directs, and then there's 8, 7, 10 years of relationships between me and my peers, where we know that we have to behave and model behavior in a particular way, in order to achieve the right outcomes for the company. So I think that's a big piece of this. 

I think the other piece of it is, we've tried really hard, to actually, not take any of these things to a point of being unhealthy, if you've seen the old classical kind of cartoon about the different org structures and you've got the one, and I won't name the company, but you know, it's like the guns are pointing at each other. And you know, we kind of laugh about it internally because like it's been eight years in this model and we've never felt like we have even come within miles of getting to that point where it's adversarial to the point of unhelpful and unhealthy, and bad for customers. And I think every time we've seen stuff that could get down that path, we've said, no, we won't do that.

And yes, it is not the purest P&L model where you are effectively an island and a kingdom unto yourself. But we don't want that. We want these interconnections, we want this web of connections, and we want, people to advocate, but not become adversarial.

Brett Berson: Yeah, there's this kind of interesting idea. Let, let's say you want to have, for whatever reason, a very teamwork oriented company. You could potentially try to use the design of the company to create an incentive structure for that. The other is maybe you just hire lots of people who like working as a team and their normal base orientation is sort of teamwork.

And I think the answer that you're sort of getting at is you want sort of some balance of those things. Um, and probably one and not the other probably doesn't get you to the end. But you have humans and systems, the humans can kind of shape these orientations. Just like the system can kind of shape the orientation, I think.

Saumil Mehta: Exactly. And this is where I think leadership really matters. And so as somebody who's been in the company seven and a half years, and, you know, takes pride in advocating for the products in my remit and takes pride in pushing forward the P&Ls in my remit, I take very seriously my responsibility in creating a permission structure to behave in Square first ways and modeling square first behavior for myself and for everybody around me.

And so, one of the things that I'm very vocal about internally, is the importance of good escalations. Like I want good escalations to come to me from all over the company. Certainly folks in my purview, but also folks outside of my purview. So one of my colleagues direct reports may come to me and they do and say, Hey, I'd like to bring this escalation to you.

I think the way you all are going about this is causing negative impact. And I want you to like take a look at it. And at that moment I have this micro choice to make. Either I can blow 'em off and kind of say, ah, whatever. I don't really care. Take it up with your manager. Or I could choose to engage them in good faith and take their concerns extremely seriously, and go push on our own team and say, folks, what are we doing here?

Why does this, why does this not look right? And you have to let reason win the day. You have to let consistency win the day. Because if you behave inconsistently, if you behave, in ways where reason is not winning the day, there's uh, reputational costs, as there should be. There's credibility costs, as there should be.

There's trust capital costs, as there should be. And eventually you hopefully achieve something that finds the right balance.

Brett Berson: When you zoom out and you think about the topic of, of the GM structure that you all have developed. If another company is figuring out whether this structure might be right for them or some flavor of it, do you have thoughts on, what are the questions they could ask or the signs that maybe this structure might be optimal for them, or the signs or considerations that maybe some version of this structure probably wouldn't be the right fit for them?

Saumil Mehta: We hear stories from the industry about companies that have tried it. And then reversed course in 12 months, 18 months, two years. Um, and so while not having any access to specific insider knowledge the, the couple of places, where we've seen this go, right or go wrong, two signals.

One is fundamentally, are you in a single product structure? Or are you in a multi-product structure? And I think what we have seen, or observed, is companies that are fundamentally one product in the end, but have for whatever reason, caught up that one product into multiple GMs. And it eventually, by and large does not work.

 You have to recognize whether you are in this ecosystem portfolio, multi-product circumstance, or if you are in the single product circumstance. And too many companies take a single product system and try to run it as a GM led system and it doesn't work. So I think that's one. 

The other thing which is also interesting and cultural at some level is what's the kind of level of commitment or progressive commitment over time to evolve and iterate? Because this is a structure that Alyssa put in place right before I joined, and so that would've been summer of 2015. And we've iterated it, we've improved it, and we've worked on it and we're still working on it eight years in.

And what we've seen is, without kind of a long haul commitment, it just doesn't work. Because it's not a system that a lot of people in tech may be super familiar with. And as a result of that, it takes time and effort and patience and hiring and leadership coaching in order to get it and to build a remit that actually makes sense to build a remit that achieves the balance between advocacy and Square first behavior.

When I first started, you know, the only things that a GM was leading was product and engineering. And over time we've actually said, okay, well product design, okay, well product marketing. Okay, well creative, okay, yes also data science. Okay, here's this P&L that we've built out. Okay, here's the methodology behind that P&L.

Here's how we're gonna set your goals. Here's how we're gonna. Hold you accountable to decision making. Here's the decision making racy between you and the people around you. Here's how we want you to do org design. Looping back to the prior topic. So we've been at it for eight years, and we've evolved and learned along the way, but too many companies.

Never give it the time. And so I've heard so many examples where it's like, I'll talk to the CEO or I'll talk or I'll hear about it from somebody who's a leader. It's like, yeah, you know, we converted to a GM model and we're doing product and engineering, and one of my first questions is, great, when's the next two disciplines that are gonna come into the remit?

And sometimes the answer is never or boy, I can't do it because that's just not how this company's set up. And to me that's a private sign of worry because to me the signal is, are you truly committed for the long haul? And if you're not, then it's not gonna work.

Brett Berson: So I wanted to come back to the higher level topic of org design and the set of principles that you outlined at the beginning of the conversation. You started to touch on this in a variety of ways, but maybe from the last few years, you could walk through when you thought you all did a really good job with a reorg, in sort of bringing the steps to life sort of end to end. 

Saumil Mehta: Yeah, so we formed an organization last summer. So I won't go into the specifics, but we formed an organization last summer, and so I'll give you the example and walk you through it. 

So that reorganization was initiated by three close collaborators coming together. And so it was the head of product in that area and the head of engineering in that area and the head of design in that area.

And the three of them are longtime collaborators. They've worked in this area for years, they'd gone through multiple annual planning cycles, and they had seen what was working well and where there were major opportunities for improvement. Last summer, organically, the three of them started talking and saying, Hey, wouldn't it be helpful if we could actually, basically make a change form this new organization, by taking together various sub-teams within our remit, a couple of teams outside of our remit, and pulled 'em all together into one new organization. 

 So they started talking. They spent a couple of weeks talking about it. And then, they brought it to their leads and those three leads reported to me. So then all of a sudden we go from a group of three to a group of six or seven, and it's clear at this point that the RACI is, they are responsible, those three, and I'm the approver. And that's the other thing we've been very clear on, which is if there's an org design change, you need a clear approver. And in, in most cases historically, I've made myself the approver so I can actually inspect what's going on, and, and ask probing questions.

So step one, they spent a couple weeks talking through it. 

Step two, they brought it to me, as a very broad sketch of like, Hey, here's some stuff we wanna do. Here's how we might go about doing it. Here's some of the teams that could be involved. Say great. And so I said, okay, let's look at a proposal.

When you have it, another couple weeks go by, they bring me something more concrete. 

Brett Berson: What is the asset or artifact that they're bringing you?

Saumil Mehta: The artifact is, some set of boxes and arrows and so it's some sort of designed structure with team names, and some mechanism of team charter. So it could be, we've got these five teams that are gonna end up in this organization when everything's said and done, here's the names of those five teams. And for each of the five teams, we're gonna give you kind of a bullet pointed list of what's in that team's remit. What is effectively that team's reason for being? What is that team's charter? And so we'll give you a super summarized 3, 4, 5 bullet point view, maybe a couple of paragraphs if needed, that explains to you what this team is, why they exist, what they do, and what are they supposed to solve?

And you do that across all five teams. So you look at it, and that's option one. They may give me a couple of different options. They may gimme three different options, and then they just, the options are on the table. And now we're gonna go around banding around pros and cons and we're talk about okay, like, well, if you do it this way, what could go wrong?

Or if you do it that way, would it achieve this company priority that we're all aware of? Or does it deprioritize by accident, this big company priority that we know is important to all of us? So we go back and forth. 

​Saumil Mehta: 

and I realized that there's a slightly different stack rank that each of these three leaders has across what goals they wanna achieve. And so discovered that through conversation, sent back the proposal to get aligned on goals, or to basically bring the misalignment and let me pick the final set of goals and the stack rank of those goals that we were gonna solve for. And so team gets aligned. They say, okay, we've figured out how to navigate our differences, and we've now aligned on a set of stack ranked goals that we can all agree on. And based upon that, we're gonna once again give you two or three options.

In each of those options, there's gonna be boxes and arrows. There's gonna be a bullet point list of kind of charter slash remit for each of the teams. And we think this will work. So you look at that, you pick one and say, okay, this one seems the most promising.

Let's go now through all of our priorities in this area for the next 12 months. And ensure that each of these teams can successfully last for at least 12 months. Because again, you wanna design for durability. You want to know that the team doesn't have such a short runway of work that it is taking on something that is urgent, but short-lived.

And so this is where our annual planning becomes helpful cause we have a running spreadsheet, of items. And so we can go look at and figure out okay, we can put this stuff together.. It's gonna last for a while, if not multiple years. Okay, that's good. Um, then we look at that list and say, okay, does this list look coherent to you?

If you just took this list and showed it to somebody outside this small group, would they say, yeah, you know this list? Yeah, they're thematically connected to each other. Or does this look like the junk drawer, which I was referring to? And so you check for that. So that's your next check. Then you say, okay, this looks right. 

Now, go look at what it looks like when you put people into these boxes. And so what does that look like? So that looks like each of these teams is gonna have a PM, it's gonna have an eng manager or multiple eng managers. It's gonna have a product designer, it's gonna have a data scientist. 

And can you make all the mappings work now with people names attached?

And that's when we check for ratios. 

So do you have one PM with 20 engineers? . Do you have half a designer across 12 engineers? Well, that's not gonna work. Or sometimes you have the opposite problem where you have two designers or two data scientists that are working in a very closely related area, and now you've basically changed the scope of it.

You've combined it into one team, and now you have two data scientists in a team of seven engineers. It's like, well, that's not gonna work either. So you basically iterate through the ratios and you iterate with the people names in mind, and you try to figure out if you can make the span of control work, if you can make the mappings work.

So you do that. Then we're done with all of that. And at this point our in the know list is still very small. So it's still 5, 6, 7 people. HR is involved certainly by this point, but within the working team, it's a very small group of people. Then depending upon the nature of the ' cause, sometimes these changes are gonna have impact not just on the folks reporting to a given gm, but to all sorts of other GMs.

Some of whom report to me, some of whom don't. And so I might take it quietly to one of my peers, and say, Hey, this is what we're thinking about doing. Love to get your input. Would you be up to signing up for this, based upon your knowledge of how this would impact your directs. So he or she will look at it and say, okay, like, here are my concerns.

We'll take another turn. We'll try to figure out how to address it. Sometimes that could result in a meaningful change. Sometimes the concerns are so significant that we'll have to go all the way back to the drawing board and start over, because we missed a goal that was very important to one of our cross-functional stakeholders.

So we'll do that. We'll do another round. 

At some point, after multiple rounds of this, we've got something that works. We've narrowed an option. We've got an org design, we've got span of control, we've got mappings, we've got durability, we've got charters, or at least at a high level, we've got thematic coherence on a per team basis.

And we've got kind of coverage, it's cumulatively exhausting. It's mutually exclusive. There's good swim lanes. Got it. Okay, great. At that point, depending upon the size of the change, I'll take it, to Alyssa for approval or at least a heads up. And most of the time it's just a heads up.

And in very rare cases it's a, we're doing this, you have the option to basically pull the plug if you so choose. You could tell us now or, or we go. And once all those i's are dotted and t's are crossed, the next step is all the comms planning. And we spent a lot of time doing comms planning in this particular case.

So what do we do? We'll start out with a big doc where all the comms is laid out. So what's my email gonna say? And it's gonna be super detailed. What is the follow-up email gonna say from the eng leader to his eng team? What is the follow-up email gonna say from the product leader to our product team?

So we'll do all of that. We'll write down all of our emails in one place and we can check all the comms in one place. Then we'll build in most cases, A set of slides, which is okay, like we're gonna do an all hands. We're gonna walk everybody through this. It's gonna take 30 to 45 minutes and we'll field questions at the end of it.

So we'll build that artifact. Then we'll build, what we would call rude FAQs, we call them, which is what are all the spicy questions that people may ask or more importantly, people may not ask but still think. And we want all the spicy questions on the table in one place. And so we will crowdsource what we call rude FAQs.

And then we will write them down and, one of us or multiples of us will write down bullet point answers. So we'll write a full FAQ list. Then we will write, manager talking points because you have to recognize that if you're doing this across hundreds of people, a lot of the conversations aren't gonna be broadcast.

A lot of the conversations are gonna be small group conversations. They're gonna be one-on-one conversations and they're gonna be facilitated or fielded by people who are not originally in the know, and were not the original decision makers. So you want them to be equipped and armed with all the right context and all the right information.

And so we'll build manager talking points too. And so at the end of it, you've got three, four different comms artifacts that we've spent days pulling together. And once we're ready with all of that, 

the final step is actually execution and comms on a broad basis. And so our general principle there is communicate in concentric circles. So in this particular case, this is about a year ago, we pulled in a slightly bigger group of people with like, let's say 48 hours to spare. Then we pulled in another group of people with direct impact. And direct impact means you may be changing managers, you may be getting mapped to a new team as a PM, your scope may be expanding, your scope may be reducing.

So if you have direct impact, you are brought in the know one to two days in advance. Assuming you're a manager with direct impact attached to you. And then we'll get all that done with 24 hours to spare, and do a series of conversations, one-on-ones and group settings. Then the morning of, we'll start to actually communicate with individual teams and ICs and we'll say, here's what's changing, here's why we're doing it.

Your direct manager leads that conversation because that's a point of trust. And that's a point of psychological safety, one would hope, between the manager and their direct report. And so we allow for a series of those conversations to happen, both one-on-one and small group. Then we send the comms out after all those conversations are done. Then we hold an all hands, and then we do office hours, and then we do a round of skip level check-ins a week after the fact. 

Brett Berson: And so for the core rollout step one is expanding the inner circle, and maybe the last step is the office hours and then a week or two later you do check-ins. That, that's sort of first grouping. Are you trying to do that in 48 hours, five days, 24 hours? What's sort of the general heuristic?

Saumil Mehta: In terms of we are ready to go and we've announced it, to the whole company, if you will, that time window is usually in the neighborhood of 48 hours or less. And so we want it done in a very concentrated burst, because with so many people involved, despite everybody's best intentions, word starts to get around. And so the last thing you want is this kind of open secret where the rumor mill is in full flower and people's anxieties can get overrun and then, that's a negative situation to be in. So we want a very concentrated burst. And if you are in one of these situations, like in those two days, my calendar is mostly cleared out, and it's almost entirely focused on getting it done.

Brett Berson: Maybe in the context of the one or two week skip level check-in, or maybe more interestingly, a month or six months later, what are you looking for that gives you confidence that it's either working exceptionally well all the way through, eh, there's something broken, and either we need a minor or a major adjustment here.

Saumil Mehta: Yeah, and you know, it's funny because one of the consistent kind of communication practices for us on the day of, is to remind people to give this new setup the benefit of the doubt for some fixed time period. And that fixed time period is usually three months or six months. Because in three or six months, you know. And so what I'm looking for are a set of kind of indicators, if you will, that help us read the tea leaves.

So first is, hey, we set this up more frequently than not to get roadmap acceleration. So are we getting that, like the stuff that we wanted to get done, are we getting it done? We wanna see, if our cross-functional stakeholders, for example, our go-to-market stakeholders, are they telling us that, Hey, the prior setup was a little confusing.

This one is helping sales managers or marketing leaders do their jobs more effectively because we've changed the communication patterns, or we've changed the communication paradigms. We look for that. I think the third thing we look for is were we getting escalations, that have, magically kind of slowed down or stopped because we've either created a new point of escalation through the formation of a new org, or we've created a new kind of cross-functional communication system through the formation of a new org, maybe with an MDL or GM. And are you getting, issues get resolved at a point to point level. And they never get escalated to me. But previously, there's a kind of before and after compare and contrast, was I getting more frequent escalations and now I'm just getting less. Like that's another kind of checkpoint that we look for. And then of course there's the qualitative measure of, you know, I do a lot of kind of office hours.

I do a lot to check in with my skips or skip skips, uh, as best as I can. And in a hyper empowered company, with a huge degree of transparency like Square is, if something's going wrong, I will almost always hear about it. And if something is going, right. I may or may not hear about it.

 But you know, if it's going wrong, I will hear about it and I have ways of finding, uh, so, so if I don't hear anything, it's like, okay, I better go check. And then I'll find out if it's going well or really well. And if it's going badly, I'm getting signals within the first four weeks. And what we frequently find in our gray area world is that most things are going well, but there's two pockets of problems.

And now we have an isolated set of things that aren't quite working and boy, we're gonna get another bite at the apple in another 12 months or another nine months, and we'll take another bite at the apple to go clean up something that we didn't quite manage to get right the first time around.

Brett Berson: So I, I thought maybe we could end our time maybe talking a little bit about Alyssa and some of the things you've learned from her. And one of the reasons I was interested in, in sort of getting your thoughts is I feel like a lot of the ideas were inculcated by Alyssa, or at least that's my sense you can tell me if I'm wrong. And at the same time, I feel like, in technology she's not a loud, out there person relative to other people leading very large important companies. Um, and so I'm curious what comes to mind, like what are some of the big ideas that maybe we haven't touched on, maybe adjacent to what we're chatting about, that sort of, she's imparted and imparted on you and is sort of maybe a part of the way that you see the world now.

Saumil Mehta: Yeah, the list is long and consequential, at least from my vantage point. And it certainly is significantly responsible for my worldview and for executing and scaling the way that I have scaled and the way I've gone about doing things. Uh, so it's, again, speaking personally, hugely consequential.

And so in no particular order, some of the valuable and important lessons. I think one of them is just, the importance of patience and having a long-term outlook. And so, I, I said somewhere along in our conversation is like, commit for the long haul.

And I spent 10 years working at startups where, you know, like, if it's a startup that's let's say a hundred people or less, you're not gonna have a lot of in-depth conversations about annual planning. And you're gonna be very focused on achieving product market fit. You're gonna be very focused on what are we getting done the next 30 days?

How are we gonna be super responsive to competitors, customers, industry trends and so on. And so I think one of the big lessons for me personally, but also at large, is how do you invest with a multi-year timeframe in mind and how do you patiently keep investing to make things incrementally better every six months, every 12 months?

And how do you stay committed to a particular path which is a classical problem, which is there's a lot of herky jerkiness. And companies use exceptional product, market fit to paper over, what is herky jerky, impatient, distracted behavior, underneath the covers when you actually go talk to the leaders within those companies.

And so the importance of patience and long-term investing and just pure stick with itness. And so that's one big lesson. I think the other big lesson is just the importance of, maintaining high performance standards at all times.

And so what I've seen Alyssa do very consistently is to treat people and situations. And whether it's org design or something else, it's like we're gonna maintain, a consistent viewpoint that is defensible privately and publicly and it's performance oriented. And it is not over anchored on anything beyond the customer and the company. And so you culturally, the construct is put the customer first, put the company first, put your company hat on while recognizing that you're gonna advocate for your product or your P&L and show that you could do that over and over again.

And so the importance of maintaining kind of objectivity around performance. Objectivity around what is right for the customer and the company, and using that as your compass as opposed to if I do X person Y will be annoyed, and they're a high performer, so I'm not gonna do X, I'm gonna do Z instead.

And I think one of the big lessons for me is, no, no, no do X if it's right for the customer, if it's right for the company, do X and let reason and patience win the day. Because I've been on the business end of lots of conversations with my directs over the years where I knew that there would be, at least momentary, if not, medium term negativity attached to an outcome or decision.

And if there's a cultural construct around, yes, I accept that, but we're gonna do what's right for the company and the customer, first and foremost. And then opportunities will come. Human aspirations will get taken care of, but you may have to take it on a timescale that's not today. That leads to better outcomes in the long term.

So I think objectivity around performance and consistency of behavior and modeling that consistent behavior over and over again, over micro decisions and macro decisions. Going back years is the second big lesson. 

I think the third big lesson, is around progressively pushing decision making down.

And so the only way you scale is if over time you push better decision making through the organization. But it doesn't happen magically. It doesn't happen by just saying, well, this used to be my decision. Now it's your decision. Like that's just one piece of the puzzle, but you're gonna have to do other work around it.

So you're gonna have to say that, but then you're gonna have to teach. And how do you teach? You teach through principles. And so the kind of commitment to long-term and progressive, distributed decision making through principles and through clear, uh, kind of articulation of who gets to decide what and why, has been kind of a big lesson that I've learned and really taken to heart over the years.

I think number four would be, just have, a very clear customer orientation at all times. And I mentioned some of that in the second lesson. But in general, what are the cultural practices that you can inculcate to actually uh, make sure that the customer is put first? And so that could take many forms.

That could take a form of, we read a weekly update, from the sales and account management team, and we look at wins and losses. But we don't just celebrate the wins. We also look at the places where we lost an opportunity with a customer and we try to learn from it. So I think that's another big lesson.

 And then there's one more, which is, be in the work and the, the kind of internal kind of haha but not really funny thing that everybody knows is, Alyssa reads everything and I mean everything. Uh, And she's not above any real piece of work. And nothing is beneath her at some level.

Like if there is a material, a piece of material that is being put in front of her or is in her queue, she will get to it. It may not be overnight, it may take three weeks, but you'll hear back and you'll hear substantive critiques on something that sometimes people are like, wait, really? Like, I can't believe she read that.

And that is kind of passed along over the years. And so, like, I mean, folks that have worked with me for many years know that I am relatively similar. Like I'm not above, anything really, and I'm ready to review. Individual line items in a roadmap in one of my dozen plus teams. And I'm ready to look at a detailed model of how we're gonna change price, and packaging for this one SaaS product that we offer.

And that's an upside of $5 million to us that I'm gonna go look at that. And I'm gonna maintain this like very heavy orientation around yes, push decision making down, but don't, don't make yourself an ivory tower person. And I have like a deep level of familiarity with a lot of what's going on in my area, to an extent that might feel surprising.

And she is the same, but with a much broader remit.

Brett Berson: Great place to end. 

​