Breaking Down Organizational Silos - Podcast Transcript
Kumar Dattatreyan: Hey, everyone. Kumar Dattatreyan here with the Meridian Point. Here's a stat that might blow your mind—it definitely blew mine. The average company spends 21% of its time—that's one full day every week—in meetings trying to get different departments to talk to each other.
I can walk into any organization and within 30 minutes tell you exactly where their silos are. I've been doing this for a long time: tech startup, manufacturing plant, hospital—it doesn't matter. The silo pattern is universal. Why is that? That's what Glenn and I are going to examine today.
But here's what's fascinating: while silos form everywhere, how they break down is completely different based on the industry. So let me bring Glenn on and we'll talk about this in a little bit more detail.
Glenn, when you walk into an organization, what's the first silo pattern you look for that tells you how the transformation may or may not unfold?
Glenn: A lot of times I start with the IT department, and in terms of software, it's totally a no-brainer: continuous integration, continuous deployment—wasting massive, massive amounts of time on that. A colleague of mine actually had a quote. I won't name the organization—it's a very large bank, one of the top 50 banks in North America. And he calculated that they spend 85% of their budget moving software from one environment to another.
He mentioned that in a meeting with some senior people, and it was actually called out: "No, no, that's wrong." "I've actually measured it. It's 90%." It's like, wow. So when you think about it, it's madness. And that kind of relates to talking to different departments. But when you consider getting a sign-off, running through this test suite, running through that test suite manually—I think, let's be conservative, a majority of the IT budget in large traditional organizations is spent there, which is just staggering.
Kumar Dattatreyan: Yeah, you mentioned banking, and banking typically requires—I mean, it involves more regulation, right? And more audit control and things like that. So in a bank or a financial institution, how do you enable collaboration? I have some thoughts, but I'd love to hear your thoughts, especially from your experience.
Glenn: I was at a conference—an Agile conference—and there was actually an auditor there, and he gave a talk that I've never forgotten. There were a lot of financial people there. And he says, "Look, guys, you guys make these huge massive things for audit. Everybody's scared of audit, and you send us a whole pile of garbage and stuff, and we have to look through it. And then we don't like it. We know you hate making it. We hate reading it. Why don't we just work together?
There are things that need to be neutrally looked at from an arm's length. But if you can sort of open the kimono and show us a robust audit trail, which of course we'll have to verify, it'll save everybody's time." So what I drew from that was, "Oh, put them on the team."
Kumar Dattatreyan: You know, it's interesting because in the company that I'm supporting now, they're going through a big audit process—not financial related, but still it points to some of the same challenges, right? It's a very siloed, very hierarchical organization. And a lot of the problems that they're facing now could have been avoided had these silos been talking to each other more effectively in terms of how they communicated, how they maintain the standards that the audit is requiring them to maintain. But because they're so behind, it's causing a lot of disruption, a lot of extra work, and so on and so forth.
And I'm wondering, you know, so silos—where do they even come from? Why? How do they arise in the first place, right? How can we be aware of those reasons?
Glenn: Can I just back up for a second to audit? The point about audit is, you know, we have to do these things—they're very important, and it's a regulatory thing, so we're going to be checking. So please do this. And everybody goes, "Yeah, yeah, we'll do it," and "I'll be coming to check at the end of the year."
But if you had that up front and you made a point of incorporating that up front with proof, look how much time you'd save. Instead, you have an adversarial thing and disconnection and silos like you were saying. But if you just work together, bridge the audit and whatever you're working on departments through a bridge—you can still have the silos, but at least you need a bridge between them. You'd save so much time.
Kumar Dattatreyan: Yeah. I mean, but I guess I'm back to my original question: How do they arise in the first place, these silos, right? So what's the benefit of a siloed organization? Because it's so prevalent. Anywhere you go, there are silos. And you and I, and the work that we do, we're coaching these organizations to be less siloed, right? Start talking to each other. Departments need to have established communication patterns and so on. Share the knowledge so that you don't have these types of—a day a week spent in meetings trying to get departments to talk to one another. How do they arise? What's the benefit of a silo?
Glenn: I've been thinking about this, and here's what I think happens. And tell me what you think. A company, a new company, a startup—they're small, they move quickly. Everybody knows everybody. They have some specialists that are doing something very special because that's the reason they're there. And they have a bunch of more generalist people—they may even outsource—that are doing sort of the general admin stuff: legal, finance, that kind of stuff, customer support. But they have kind of a niche of something that they know deeply.
But they're small, so everybody knows everybody, and they can just do stuff. As you're successful and you grow, you get bigger, and eventually the "everybody knows everything" model doesn't work, or somebody screws up badly, and you go, "Whoops, that was bad. We need to make sure that doesn't happen again." And if it's very painful, the typical response from humans—and I don't mean this as a criticism—is we try and control it. We put process and stuff around it to make sure it doesn't happen again.
Kumar Dattatreyan: I guess what I'm getting from what you're saying is that it's almost inevitable that as an organization grows, you need hierarchy for various reasons to be more efficient and so on and so forth. It starts out being for those reasons, but then it actually leads to inefficiency and waste. As organizations get bigger and bigger, the hierarchy grows stronger and stronger. The silos get more impermeable to other parts of the organization. And that impermeability causes conflicts, communication breakdowns, learning breakdowns, things like that.
Glenn: I think it's even more fundamental than that. I think humans' natural reaction is to control when you have something bad. "Okay, we better put some process around that, make sure that doesn't happen again." I don't think that's actually the best approach. I think the best approach is to say, "Let's look at what happened and let's educate the people and come up with a lightweight process that will make sure that doesn't happen again."
Now it might involve having an auditor—we've been talking about audit, which is kind of like the audit department, but they're more advisory and more after-the-fact monitoring as opposed to a separate department. But unless we think—unless we have a culture and a mindset of growth and training and working together in a cross-functional team—the natural instinct is, "Okay, let's make a new department called audit." When really you should say, "Let's get somebody who's representing the audit function, wearing the audit hat, and have them on the team as much as is needed."
Kumar Dattatreyan: Yeah, right. I'm curious what your thoughts are on this. You know, this is Conway's Law, right? That an organization's products, if you will, mirror how the organization is designed, right? So if you have an organization that's less siloed, the products will be more attuned to what their customers need—you know, what the organization was created for in the first place, right, to deliver value and all those things. And the more siloed an organization, the products are less likely to delight their customers.
So the premise that Conway's Law—where the organizational design systems mirror their communication structure—is that inevitable, like as an organization grows? Or what are your thoughts?
Glenn: I think it's a natural artifact of the hierarchy where the silos are, as you said, relatively impermeable and thick. And I have a—I don't know if I'm getting too detailed here, but I have a strong example from auto manufacturing. This one is from Tesla—Tesla the car company, not Elon Musk. We had a spirited conversation about this the other day. I admire Elon from his Tesla side—that's all he is.
The battery division was in a separate group and not adjacent to the—I think the power electronics and the batteries are a really big deal in an electric car. They need to charge quickly. They need to be cooled, and they need to be protected from stuff coming up from underneath the car and puncturing it. They're enclosed in a steel cage. And so there's a bunch of stuff that goes around with that. And there was a separate department because that's kind of a big deal. There was a separate department at Tesla to handle that. But that wasn't that well—that was in a separate area away from the power electronics folks.
And I guess when they came to integrate it, there were some difficulties and some overly complex interfaces that they made. And Tesla does a good job of looking for ways to improve. And so they realized, "Well, how come you guys didn't talk to these guys? This is a pain. If you just talk, blah, blah, blah." So there's a perfect example. And so then they relocated the battery folks beside the powertrain electronics folks so that didn't happen again. Simple. But this is natural.
Kumar Dattatreyan: It is. However, you have to take into account the leadership there, right? So Elon Musk—not Elon Musk the politician, but Elon Musk the engineering genius, the mind right behind these companies. He's always stressed visibility, transparency in the communication process. So there have been several articles written about his memos to employees saying, "Hey, if you encounter an issue, any kind of an issue, you don't have to go to your manager to fix it. Go to where the issue originates. Go to that person. Bypass the hierarchy, bypass the silos, go talk to the person where it originated so you can bypass all that stuff, all that red tape, and fix the problem at the source."
So that came from the top, right? And that would be one silo-busting strategy: to empower people to take decision-making, if you will, into their own hands and go find where the problem arises and go fix it.
Glenn: I would position that slightly differently. I view that as a very strong bridge. So they're tunneling into one side, tunneling into the other side, and having this conduit so they can go back and forth easily. But you still would have the silo. Let's say a person in silo one talks to silo two directly, going back and forth. They go, "Yeah, yeah, you're right, man"—or woman—"I totally get it. We have to fix that. That's on us. No problem. We'll fix it."
But that's going to require a big expenditure, and they're going to have to get approval for that. So then they're going to have to go up the hierarchy a little bit because it's $100 million and get approval. So the hierarchy is still there. It's just that the back-and-forth communication is there in addition.
Kumar Dattatreyan: Yeah, I see that. I mean, certainly having bridges or tunnels between silos could be, you know, at least marginally effective—maybe more than marginally effective. I almost think that in certain industries, you can't get rid of silos. Finance, whatever, because they're designed to protect data that needs to be protected. Fine. And so you need to make these silos permeable just to whatever extent is necessary to ensure that communication still flows, learning still flows, decisions can be made, and so on and so forth. But I can't see any other reason why you'd want to have silos. I mean, unless there's—like you said—bridges that exist that allow for information to flow freely.
Glenn: Let's pick finance. Let's go into finance because finance is a tough one. We could also use regulatory or legal or whatever, but finance is a good one. Finance has a reason for their existence, just like any hierarchy—they have a purpose, and that purpose needs to be honored.
The way that organizations typically choose to honor that purpose is by making a silo and appointing somebody: "You are responsible for finance," and you need that. In terms of finance—we're talking, let's use engineering projects, which we're most familiar with—finance needs to authorize the work, and they are accountable for, "Is this a good use of funds?" And that's great, and that's important, and that's the purpose that the finance silo needs to honor.
But at the same time, in an engineering context, you need to make stuff to delight the customer. So that means that that really is your ultimate purpose. But finance helps keep the lights on by making sure you don't run out of money. But if finance doesn't give out any money, you'll be bankrupt. You need to produce product so the customers will buy. So when you have something that customers truly want, you better get finance in there, giving them some money pretty darn quickly.
So I submit that finance—just like there should be a bridge over to finance—and we have some new work coming down the pipe. Call up finance: "Hey, we've got some new work. We think it's going to make a huge pile of money. Come on down." So they come on down. "Wow, that is great. I agree. But by the way, we just bought this $50 million machine. So our cash flow is really tight right now. So we'll be sure and do that in the next quarter. But you got to chill a bit for now. But you can absolutely get started. I'll give you enough money to get started."
And then you've had a conversation, and it's not adversarial, and they're part of the team. And the engineering team, in this case, would of course say, "Oh, wow, I didn't know that. Of course, we can't be short of cash. No problem. We'll slice it in such a way that we'll back-load the expense."
Kumar Dattatreyan: Yeah. I think maybe that's one approach. It's probably the less radical, I suppose, less disruptive approach: to build these bridges and tunnels that allow people to collaborate as needed. I mean, there are maybe more disruptive approaches like ING Bank's transformation. In that transformation, they literally reorganized their entire business focus—products that they serve, that they created, and the people that supported the creation and engineering of those products, if you will—into these cross-functional tribes that were organized around customer journeys.
Same thing with Amazon's, you know, the two-pizza team model that you, I'm sure you've heard about, and many of our listeners have heard about. Essentially, before this was a thing with Amazon, they were these large cross-functional teams with really unclear ownership and unclear vision, mission, whatever. And they reorganized into these two-pizza teams, if you will—small autonomous teams that owned entire customer journeys.
And there seems to be a sort of a familiar ring between different industries like ING—a bank, a financial institution. Amazon—totally different. It's e-commerce and much more. Haier—they build all sorts of appliances, and they certainly are probably the most extreme example of the inverted pyramid model where leadership sort of inhabits the lower rung, if you will, and they support thousands of autonomous teams that are designed almost like an organism. They have specific purposes that do specific things, but they're connected in this network, if you will, that allows them to operate very efficiently.
So where am I going with this? I think there are probably places where the model that you're talking about in financial services—like where Sarbanes-Oxley or regulatory requirements are really important, where you need to have separation between certain functions. However, you need to make the boundaries permeable to a certain extent and have bridges that allow collaboration and communication to exist. Meaningful collaboration and communication.
Glenn: Okay, two things. People say this, but I've never accepted it: "If you're regulatory, you have to have a lot of hierarchy." I completely do not accept that. Regulatory means certain things have to be done, period. Certain documents need to be produced. Certain regulators need to endorse certain things. Maybe you need independent—if you're pharmaceutical, maybe you need an independent lab to randomly inspect whatever. And you certainly need an audit trail in pharmaceuticals of double-blind clinical trials, very rigorously captured data. But that's just an output. How you get there is up to you.
And there's an expectation that the organization is going to do this efficiently and effectively. And the way to do it is exactly like you said—when it's taken to its logical conclusion, a Haier-type model generally is an optimal model. But I submit that with work, any organization can fit into that model, but we don't want to go and be prescriptive. The organization should be like an ecosystem evolving to whatever makes sense in a given context.
And I've had discussions with colleagues about this. I don't think there's a lot of need for hierarchy, but there will be some time because it's not as efficient as going direct—make the hierarchy as small as possible and as short as possible. But absolutely, if you have an emergency, you need to have a bit of hierarchy. Somebody needs to be there to call the shots. For example, COVID—when we had organizations shutting down, I guarantee you there was a hierarchy of senior people in there: "You're going to be responsible for this. You're going to be responsible for that." They had to get remote logins up really quickly, and they did that. That was a pretty amazing accomplishment, I thought, for a lot of very traditional organizations.
Kumar Dattatreyan: Yeah. I want to go a little deeper into this whole silo thing, and maybe it's a natural evolution of human organizational systems—how humans organize into groups. The whole notion of Dunbar's number being sort of this—I know it's not a fixed number; it really depends on context and many different things—but the theory that humans form into groups of no more than or around 150 people. That's an efficient size group. And I'm just wondering if maybe it's an inevitable thing. If silos aren't a bug, they're a feature. But how we organize silos should be more intentional. What are your thoughts?
Glenn: Maybe we're saying the same thing. I think there needs to be certain functions—business functions—particularly as an organization grows. You know, audit, legal, finance. When you're small, you know, there's just one person doing all of that, probably. But when you get big, it's too much work for one person, so you have to hire different people—maybe a couple of lawyers, maybe a couple of auditors. Well, wouldn't it be kind of good if there's somebody who understood legal and audit that kind of oversaw that department? And there you go, and that makes sense.
Kumar Dattatreyan: I want to interject there. I mean, so you know, legal and HR and so on and so forth—those are functions that are needed by most—say, for instance, a company produces many different products or product lines or services. I would argue that legal and HR and marketing and finance can't be separate departments. They need to be embedded in each of those product lines, right?
Glenn: I'm in vigorous agreement, but I was approaching it slightly differently. If you're a large company, you have 20 lawyers—you probably want to have them reporting to somebody.
Kumar Dattatreyan: I see. So you sort of like—okay, they're embedded within the customer journey or the service organization, whatever part of it is, and that becomes your silo. It's cross-functional. It includes everything that you need. However, the skilled roles—they report in or they form a smaller subset, a group that where they coalesce into the work that they do, the standards that they maintain to excel in their field, whatever that might be, whether they're an engineering cadre or a cadre of lawyers or HR generalists or specialists or whatever that might be. Is that where you're getting at?
Glenn: Sort of. Let's use lawyers. And let's say we're in a business that's highly regulated that lawyers need to consult with the teams. Let's say you're pharmaceuticals and you're making stuff—lawyers, or maybe aerospace would be another example, but anyway, something which has a lot of legal work, and they need to consult a lot with the teams. We're talking engineering here that are making stuff. So you want that—you literally, you absolutely want the lawyers to be on the team proportional to the amount of time that they need. "Hey, we need a half lawyer for the next six months." "No problem. Here's half lawyer, and the other half you go work on something else."
But the legal department is a specialty, and there's helping everybody with their legal stuff, but there's also improving their skill and talking to their other legal colleagues and maybe being aware of some new legislation that is coming down that they need to—
Kumar Dattatreyan: You're really kind of talking about quality circles, aren't you?
Glenn: I'm saying in terms of who the lawyers report to, I think they would report to the general counsel of the company.
Kumar Dattatreyan: Sure. Yeah. I mean, I get that. Yeah. And engineers might have their own quality circle—they sort of discuss their goals and their best practices and so on and so forth.
Glenn: Yeah, that's more supporting their growth, right? And also supporting the company's growth.
Kumar Dattatreyan: Okay, so here's the bottom line. Who should the lawyers report to? General counsel or product?
Glenn: I think it's—I don't know. I'm going to give you what I'm thinking right now: that the lawyers need to support the product and the product vision and the product mission and so on and so forth. And so they have a responsibility to their product line. Who do they report to? That's a really good question. I don't know. I have to think about it. I suppose they could report to the general counsel as long as the C-suite, whatever you want to call it, is supporting the overall organizational goals.
Glenn: Let me just throw this out there. I think they have to because there's legal stuff that the legal department simply is responsible for, and they have to honor that.
Kumar Dattatreyan: Yeah, that's true. They have to sign off on that.
Glenn: So when they're wearing their lawyer hat, they're representing the legal department and general counsel, but they're absolutely embedded in the team so that their communication can be as efficient and as effective as possible.
Kumar Dattatreyan: Yeah, that makes sense. Coming back to the Tesla thing about "go direct"—the team would go call directly to the lawyer they last worked with and say, "Hey buddy, can you come over and work with some bunch of stuff? We don't get it." And I would say, "Sure. If it's quick," or "Wow, you got a lot of stuff. I'll have to go and make sure that you've got half a lawyer for the next six months." But there should be that direct communication. But at the end of the day, the CEO wants to be sure that that legal checkbox can be checked off. He's going to go to the general counsel who's going to go to the various lawyers.
Glenn: Yeah, otherwise, you're right. Otherwise, each product line or service line sort of forms into their own identity, right? There's no commonality that sort of binds this organization together. I get it.
Kumar Dattatreyan: So I want to go in another direction. We're at about the 25-minute mark or so. So I want to—I'm with you in the conversation that you just had. I wanted to ask something specific about servant leadership. How do you think that specifically breaks down silos, or does it?
Glenn: Can I just throw in something here? I don't want to disrupt the flow here, but I want to make a comment and then we can park it. The critical thing with silos is that it's sort of an easy thing to happen. And pretty much every organization has them. Haier does not. And they went to a lot of trouble to get rid of them. I think that's the nub: How do you get rid of them once they're there or make them start a process that will make them more efficient and more effective? And the big bang transformation approach—I am not a fan of, but how we fix this—that might even be another podcast. But you can absolutely get from here to there, but that's a big one.
Kumar Dattatreyan: I don't know that Haier doesn't have silos. Maybe the silos that they have are more permeable and smaller—the groups are smaller. I mean, I don't think they have a group that's more than 50 people in size. And so, you know, if Dunbar's number is 150, so their silos are smaller. But I don't know. I mean, I would—if you want to characterize them as silos, because to me, it's still a group of people that have a common purpose, a common mission, a common vision. However, at Haier, these smaller groups still interact and integrate with other groups that have similar spaces?
Glenn: I think the idea is if you can do it quickly yourself, just do it quickly yourself. If you need a team and it's going to be long-lived, make a permanent cross-functional team. But have the structures that you need appear organically quickly with low overhead—do whatever you need to do. And then when that no longer is effective and efficient—pretty effective—you seamlessly morph into something else. You don't ask permission. You just do it. And as long as you're honoring your objective—and presumably somebody has an objective to make appliance 1042, whatever that is—so they gather a bunch of people together and they go and do it.
But there's an objective, and people are tasked or choose to pick up that objective and go off and do it. And there's absolutely audit on this: "Hey, you've been working on that for two and a half years. What's going on?" Trust me, they're working on that. So there's an audit function to make sure that they're progressing. And there's an expectation that they reach out for help if they need help. So all that stuff is there. Just let it work however it makes sense, and it morphs and adapts in real time, just like a natural ecosystem.
Kumar Dattatreyan: Yeah, I'm actually reading some reference material on Haier, and they actually did, to your point earlier, go through an anti-silo transformation. And so they are organized that way as small—4,000 teams—small teams that have profit and loss accountability with support from leadership. So that inverted triangle model where leadership provides support—it's a servant leadership model—was sort of the basis of my next question, right? How does servant leadership specifically help break down silos?
Glenn: Well, Haier is a perfect example of that. Teams operate almost like small mini companies within the larger ecosystem. And it is an ecosystem. They're all sort of in some way dependent on each other. And so their profit and loss depends on some other team supporting them and them supporting others. So it's an interesting model. Of course, it may not be—I mean, they spent a lot of time going through that transformation.
Kumar Dattatreyan: Right. I'm curious, you know, like if there was—I came up with these three questions that companies can ask in terms of getting a sense of, "Are they siloed and what to do about it?" And I would love to get your thoughts. So the three questions are: Can any employee easily get the information they need to serve a customer? If the answer is no, then maybe you have information silos. I'm going to read these and then I'd love for you to maybe one at a time. So the first one: Can any employee easily get the information they need to serve a customer? If the answer is no, you have information silos. Reaction?
Glenn: Yes, although some obviously need to be sensitive about some personal details and so on. And there's regulation around that.
Kumar Dattatreyan: Okay. And what would you do to bust that silo if you could?
Glenn: Have—talk to the people who have that data and explain that this is important data. We need this to service the customer. Of course, they would push back: "Yeah, but we can't disclose credit card numbers. There's legislation against that." "Yeah, no problem. Encode them." But otherwise we need to see this information, and we want to have this appropriately distributed—maybe not, maybe even to the call center.
Every—let me back up a bit. Does every person in the company need that customer data? Does engineering need it? Probably not. You know, I mean, I guess it depends. The context is important there, of course. But the fact that information silos exist at all does lower productivity significantly. Companies spend so much time coordinating across departments because information is locked in silos. And I'm saying there's a tension between openness and security. You need to find that appropriate balance. And for high-sensitivity data, you need additional security. But you make a reasonable business case as to why you need that data—you should just get it. Now, if we're talking sensitive data, there might be a bit of a protocol around that, but—
Kumar Dattatreyan: You have to establish the protocols as to who needs it, why do they need it, and so on and so forth. But for most information, there should be some mechanism to allow people to get access to the information they need for their job. Do you agree?
Glenn: Absolutely. I mean, some examples of a weak yes, you know—if you said yes, "Can people get information?" It might be a yes, but, right? "Yes, but they have to submit this form to whatever." Or "We have the information, but it's in some other system. And so people have to go and figure out how to get access to the system." That, of course, is a time waster and at least inefficiency. Or "Yes, but they need manager approval to get that information." That's a lack of empowerment for them to be able to get the information to do their job.
Here's a good example. At Sun, we had one of the applications that we got new people to do was—as if they were somewhat new or trying out a new technology or whatever—Sun had a program called Name Tool. Everybody's name, their phone number, and their address. It was fed by HR, but it was available to everybody anywhere in the company without having to ask for permission. So that's an example of something that's a strong yes. That would be a strong yes. People have access to this information within—you know, it's easy. It's there. There's a dashboard built for it. And of course, things have moved on since I was at Sun. They have HR systems that everybody gets access to, and that has all that stuff in it. But this is before that. And besides, it was kind of an engineering thing.
Kumar Dattatreyan: What would be some other examples of strong yeses to that question? Can any employee access information they need to serve a customer? From your experience or just thinking of examples? I mean, to me, we worked with a company using the disruptor method, and it would be something like customer service can instantly see what marketing promised and what products were delivered, right? So that was something that happened through working with this company and making sure that marketing, engineering, and product and manufacturing all were aligned, and they had access to the information that they needed.
Glenn: A great example. Let's continue with that. Finance—they got to be a little careful. If you're publicly traded, there's regulations around disclosing financial results. So that's a wrinkle. You might want to let—are you going to let people see invoices and revenue? It is a good idea. Open book management. But if you're publicly traded, there are some rules around that. And yeah, you simply—I believe it's legislation. You can't know right before they're officially released. That's against the law.
Kumar Dattatreyan: That's right. So there are some limits to it. But as long as the information is there for people to allow them to do their job and do their job well, I think that should be sort of the standard to drive towards, right? For that first question.
All right, let's go to the second question.
Glenn: Okay. There might be some more juice to unpack with—but in the interest of time, we'll have to come back to that in a future episode.
Kumar Dattatreyan: Okay. Do decisions get made by the people closest to the impact? So what would be a—closest to the impact or closest to the information? Closest to the impact. So if I need to make a decision, a good example of this is Disney, right? So I interviewed someone who used to work at Disney, and he said that everyone had at their disposal up to $1,000 that they were authorized to spend to solve a customer problem. You don't have to ask anyone any permission. They could spend it. So, you know, if a customer's disgruntled, they come to the counter and they're like, whatever the complaint was, that person was authorized to resolve the issue up to $1,000, you know—give them a free hotel room, a free night stay, or a free dinner, or whatever it might be. Anything to make that customer happy.
Glenn: Good practice. And I'm sure they audit it, and I'm sure they have to go and provide receipts and everything. And if somebody was doing it excessively, I'm sure they would have a little discussion around training. But I think that's an excellent policy.
Kumar Dattatreyan: Yeah. And the no answer would be if you say no, people closest to the impact don't have that authority. Like, say, a customer service rep—do they have the authority to issue a refund? No, they don't. Okay, then you may have an authority silo, right? You have to go get permission to do something, to do your job.
Glenn: Yep. Your job is to satisfy the customer, but you can't because you have to get permission. That is an authority silo. Part of satisfying a customer is addressing their concern in a timely manner. And if you have to go off and get permission, there's a timing issue.
Kumar Dattatreyan: Yeah, right. I mean, and so there are sort of like, you know, soft yeses or soft nos. You know, could be "We don't blame anyone, but we know whose department is really responsible for this issue, this impact." So while they may take care of the problem, they're leaving maybe a bad impression for the customer by saying, "Oh, it's not our fault. It's somebody else's fault."
Glenn: Terrible idea. And customer service should be able to go talk to any department and say, "Hey, we're getting plenty of complaints about this thing. Is something broken? Did you guys just change your software? What's going on here?" And, you know, rather than put a ticket and throw it into the queue, just call a person directly. "Yeah, you have to put in a ticket because we need to track this. But yeah, I'll get on that right away. Text me the ticket number when you got it." But you want these low-friction, direct connections at all times with whatever you need to do your job.
Kumar Dattatreyan: I think friction is a really good word to use here, you know, in terms of silo busting, if you want to call it that. I like to call it that, even though silos are features and not bugs necessarily. But I like to think of providing the customer, you know, whether in whatever form the customer manifests, as friction-free an environment to purchase your products, purchase your services, enjoy your services, delight them in—again, whatever your business is, whatever the organization provides. And these questions help you determine how much friction there is in allowing that to happen. If there's less friction, you probably are organized in a way where there are fewer silos, or at least there are bridges between silos that allow information to flow, authority to be pushed to the decision-makers that are closest to the customers.
Glenn: I would put it even more strongly. Delighting customers means every contact point with the customer has to result in—you know, and it's kind of hard if you're an electric company providing electrons, but whenever you touch the customer—think about it. If for an electric company, I get my bill and it looks wrong and I call someone and I have to go through menu after menu after menu of automated voice response systems before I get to a human. And the human puts me on hold because they don't have the authority to look at my bill. They have to get a manager to look at it. That is a very friction-full experience.
There are claims—I don't know if this is true or not, but I'll soften this a bit. There have been companies that have made some questionable decisions in this space, and they've gone and looked at, "Wow, our customer service budget—rather, expense—is through the roof. This is incredible. We need to knock that down." So they introduce things like monitoring the length of calls. So you have to shorten the length of call. Well, yeah, I guess that would work in a very narrow sense, but that is a—
Kumar Dattatreyan: It's not the right metric to measure.
Glenn: That's a dreadful metric, a dreadful metric.
Kumar Dattatreyan: Yeah. If you're spending a lot of time and people are spending a lot of time in customer service, what are they calling about? What are they calling about? Why don't we—they don't have to call customer service. And absolutely. When you call customer service, this phone nightmare thing—that's just customer obnoxious. I'm sorry.
Glenn: Yeah, I agree. So that was question two. Do decisions get made by people closest to the impact? And so ask yourself that, people that are watching this, the leaders that are leading departments, and think of the yes answers, what they might look like and what the no answers might look like. You know, weak answers might be things like, "Yeah, they can decide small things, but anything important needs review." Well, question that, right? Why? Why does it need review? So the last question—
Glenn: Sorry. It could be review after the fact, but give them the authority and the guidelines. And if there's an issue, train them and guide them in the right direction, but don't put obstacles in the way.
Kumar Dattatreyan: Yeah. That's why Disney's called the happiest place on earth, right? Because people are happy there, and it's a friction-free environment for the customer, for the people that visit their parks, because whatever is wrong, everyone is empowered to fix it. The people cleaning up the cigarette butts off the walkways in the parks and so on—they have the authority to at least get you to the right person to fix your problem.
And I want to get to the last question here because we are way long here. When something goes wrong, do teams blame each other or blame other departments, or work together to solve it? What do you think there?
Glenn: Sadly, blame is common, but it's absolutely the wrong approach. Here's how I would position that. Nothing is ever perfect. Mistakes are going to happen. They need to be viewed as a learning opportunity. People should not be penalized. When it happens, look for it—look at it as an opportunity to improve. And as long as you do that, you'll be continuing to improve, and you are going to have mistakes. And if you blame or bury them, you're avoiding the learning that was there.
Kumar Dattatreyan: Yeah, so strong yeses may sound like "When problems arise, the first thing we do is work together to solve it." That would be a strong yes. "Department heads jointly own customer satisfaction." That's a strong yes.
Glenn: I would say everybody owns customer satisfaction.
Kumar Dattatreyan: Everyone does. You're right. And kind of weak yeses or nos would be, "We don't blame. We just identify which department needs to fix it." Wrong. Wrong answer. Or "We collaborate after figuring out who was responsible." I mean, why the blame game, right? So I mean, you and I are both used to this in the companies that we serve. It's a strong blame culture out there. And it shouldn't be that way. It's very indicative of silos—unhealthy silos. Silos exist everywhere, to your point earlier. And the unhealthy ones exhibit those types of behaviors. But this kind of comes full circle—if we had people, departments collaborating strongly together, you wouldn't—"It's that department." "No, no, they're on our team, man." The notion of blaming a department goes away when you have bridges between the silos.
Glenn: That's right.
Kumar Dattatreyan: All right. We're at the 45-ish minute mark, so I'm going to say we should probably end this one here. What do you say?
Glenn: I think so. This turned out to be kind of bigger and deeper than I thought. I think there's a lot of juice here, and I think we absolutely need to go back to perhaps another podcast. Wherever you are today, how do you get to—start making some steps to get to where Haier is without blowing the whole place up, without doing a massive, expensive, dangerous, risky transformation. I think there's definitely a topic there.
Kumar Dattatreyan: Yeah. And I've got a company that's—I'm going to broadcast with a blog post and a little diagnostic, the three-question diagnostic, and maybe one a little longer. So just look for that in the show notes below, because that can help you at least get started, have the conversation. The three-question diagnostic—look, we spent 20 minutes talking about those three questions. And I bet you if you talk to your teams and just ask those three questions, you can have a really frank conversation about where the problems exist in your department, division, company, and what steps you might want to take to bust your silos.
All right, with that, thanks for watching, and we'll see you next time. Thanks, Glenn, for joining me.
Glenn: Thanks, Kumar.
Kumar Dattatreyan: All right, bye-bye.
