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

 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.

 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.

 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.

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

 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.

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

 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.

 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.

 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.

 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.

 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.

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

 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.

 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.

 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.

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

 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.

 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?

 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.

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

 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.

 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?

 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.

64f0b4691afea976131a1d18

Saumil Mehta is the GM of Square’s flagship point-of-sale business, as well as CRM, Square Staff, and Square Online. Saumil has overseen many complex re-orgs and these experiences have shaped him into an all-around org-design expert. 