Subsurface LIVE Winter 2021
When People Are the Problem - Obstacles to a Data-Driven Culture
What do you do when technology isn’t enough? In nearly every company, the people part of the data equation is at least as challenging as the technology — in many cases, more so. Join Billy Bosworth as he discusses a career’s worth of insights into why some companies get it right, and others get it wrong. He will explore the most common obstacles you should expect to encounter, and strategies to overcome them. Also, and maybe most importantly, how not to lose your sanity in the process.
Billy Bosworth, Board Member at Tableau (2015-2019), Board Member at TransUnion, CEO, Dremio
Billy Bosworth joined Dremio as CEO in February 2020 after serving on its board of directors since June 2019. Prior to Dremio, he served on the board of directors at Tableau Software (NYSE:DATA) for nearly five years, through their acquisition by Salesforce.com (NYSE:CRM) — one of the biggest software acquisitions in history. Billy also served as CEO of DataStax from 2011-2019, propelling the company’s growth from sub-$1M in revenue and 25 employees to more than $100 million in revenue. He is a frequent speaker on the topics of data autonomy, hybrid cloud, AI and distributed workforces and was an active member of the Forbes Technology Council for many years.
Well, hello everybody and welcome to our session. A topic that maybe a lot of technologists don’t talk about, but what do we do when people are actually the problem? What if technology isn’t always the reason why our transformative projects fail? You’re undertaking some of the most significant and powerful transformations right now in [00:00:30] data analytics that we’ve seen in the past couple of decades. And that’s going to come with a lot of disruption and a lot of challenges, and those challenges aren’t always going to be technical. So for the next few minutes, that’s what I’d like to talk about. And I’d actually like to begin with a story.
Any of you that work on construction, or have had maybe some house remodeling done, perhaps you’re familiar with this power tool. This is called a circular saw, and that blade [00:01:00] has a series of very sharp, what they call teeth on the edges of it. And when you turn it on, it spins it something like, I don’t know, a million RPMs or something insane. And I personally don’t do construction very well. Never been very good at it, never really knew what I was doing too well. So I’m not sure exactly why I owned one of these, but I did. And about, I don’t know, 20, 30 years ago, I was young and had a little home project. And the home project was, [00:01:30] I was going to install some shelving. And this is very typical closet shelving, it’s metal with some plastic, a white coating around it. And the idea is quite simply that you just cut it to the right width and then you insert it and mount it on your wall. Sounds simple enough. I had the saw, I had the wire shelving and I was ready to go.
So I fired up the saw and it went all in its glory spinning like mad and I [00:02:00] start to try to cut through the shelving. And after about, I don’t know, two seconds, I sense a very weird sensation in my arms and it starts as a tangling and then it kind of goes into a burning. And as I look down, I see that my arms are covered in these red marks. And out of these red marks, blood starts to come and pour, and I’m looking at my arms and I’m bleeding from both arms and figure I better turn [00:02:30] off the saw as a starting point. And I realized what had happened was the blade that I was using evidently they are specialized and some blades are made for cutting wood, which it does extraordinarily effectively, and some are made for cutting, I guess, stone and others for metal.
Clearly I had no idea what I was talking about and I used a wood blade to try and cut metal. It ended up cutting me because the metal chipping off [00:03:00] those teeth at that very fast speed and ripping into my flesh. And so why do I tell you this grotesque story to begin? Well, I learned two super important lessons from that as a young person. One was don’t do that, that’s not what the saws are meant to do. They have much better equipment I’ve since learned to cut those. But the bigger overriding lesson that has always stuck with me is sometimes people are the problem. There was nothing wrong [00:03:30] with the saw. There was nothing wrong with the blade. I was misusing it in a very bad way, and I had very bad results. And as you embark now on these transformative projects inside of your company, there is a grim reality that you want to face.
And maybe it’s not quite as visually horrifying as the idea of a blade cutting into your skin, but it’s no less demoralizing. And that is that if you flipped a coin, [00:04:00] you would actually have a better chance of your transformative project being successful than not. And many agencies have studied this, many analyst firms have studied this and they say there’s about a 30% chance of transformative projects delivering everything that they were intended to deliver. Why are those odds so poor? Why do we have to be happy with 30%? I would argue that in analyzing all of these and looking at that from both sides [00:04:30] of the equation for myself over the years. I started out technical. I was writing applications for departments, then I moved into vendor roles and I’ve seen this implemented in hundreds of accounts over the years. And then as a board member, I’ve gotten to see it in a couple of companies as well.
And I would argue that at the core of many of these failures and in some cases just slow downs, the technology is only a small part of the problem. So we’re going to look at three [00:05:00] core areas that you can be mindful of to avoid these problems. You don’t want to waste time, and you definitely don’t want to feel that demoralization. When these things don’t go well, this is what happens. And it leads to a lot of challenges, not just for the immediate project, but people are betting their careers on this. And we’re going to come back to this point because it’s really important that when you put your career on the line, when you put your reputation on the line, [00:05:30] then the outcome matters on a personal level, as well as on a professional level. And it leads to that company failure, and nobody wants that on their resume.
Nobody wants that to happen for all the right reasons, but even for personal reasons, nobody wants to be associated with a project that just didn’t work. That didn’t get to the point of success that everybody had hoped in the beginning. And if you’re not careful, you’re going to find yourself in a situation where these feelings can start to get very contagious [00:06:00] and negativity can breed very, very fast. And you don’t want that to happen. You don’t want your organization to start feeling that there’s constant negativity around what are we doing with these projects? Why aren’t they successful? And so the three things we’re going to look at to mitigate this, come in these buckets. Number one, we want to do a really good job with communications, and we’re going to have a people talk right now, not a technology talk. [00:06:30] So when we think about things like communications, I think we take a lot for granted, and we’re going to talk about how maybe not to do that.
The second area is around setting the proper expectations. And also maybe unfortunately for you, inheriting expectations. Sometimes you’re going to encounter expectations that have been thrust upon you, that maybe you didn’t fully agree with in the beginning, but now you’re being asked to deliver. And then finally, [00:07:00] how do we accelerate time to impact? How can we start to show that we are gaining momentum and we are gaining successful implementation milestones very quickly once the project begins. And I would argue that each of you can affect this. I don’t believe you have to be an executive level person to affect this kind of change. And I absolutely am sure that you don’t need to be an executive person to feel the effects of this when it’s done right, or [00:07:30] when it’s done wrong. And so let’s dive in and look at each category beginning with communications.
Well, the first thing is you actually cannot communicate enough. This was true even when the world was a normal. You get in this situation with everybody being distributed, everybody being overloaded with digital communications, it becomes even more important to understand that [00:08:00] just sending a message out there doesn’t mean that it was received. You’re going to have to find creative ways to make sure that as you’re communicating what’s going on with the project, whether it be with other technical people or whether it be with business people that that communication is being received. And maybe the best way you can think about this is go back and think about how you handle technical communication protocols. Think about if you’ve ever been in networking or you’ve ever been in databases and [00:08:30] you issue something, you issue a commit, or you issue a packet to go across the network.
You don’t just assume that everything was going to be fine, that the other end is going to receive it. Now, if you’re responsible for building those protocols, your job is to make sure that what was sent is what was received. And that is more true with people I believe than it is with technology. This is at the root of so much heartache [00:09:00] and hardships and blown budgets and blown timelines. The inability to effectively communicate by making sure that people understand what you said in the right context that you said it. So let’s be really mindful of how we do that. The next one might be a little uncomfortable to you. And if you’re working on a truly transformative project inside of your company, somebody had to sell that concept [00:09:30] to get it funded. They had to sell it throughout the executive chain. They had to sell it at some point to the CEO, and most likely the CEO had to sell it to the board.
Now, when all that was happening, they have built frameworks, and marketecture graphics, and created a language to be able to communicate what changes are happening with these projects. I want to encourage you in the [00:10:00] strongest possible terms to continue to use that internal language when you’re talking about the project all throughout the company. This sounds like such a banal trivial thing. I can’t believe I’m listening to somebody tell me like what I’m supposed to use a graphic. Yeah, I need you to use the graphic because when you use the graphic, it starts reinforcing the same concepts and the same messaging all throughout the organization. And too often, the more technical we are, the less [00:10:30] likely we are to want to use those things that were created at a higher level to communicate things in the organization.
So try and leverage those to the best of your ability. And then finally be mindful of what I call the real org structure. Every organization has a proper org structure. You can go somewhere and some tool in your organization will allow you to find the departments, the teams in each department, [00:11:00] the heads of each department, the team leads. It looks really nice. And there’s value in this for certain things. There’s value in this for classic people management, and reviews, and reporting structures when there’s issues, but it’s not very good for really understanding how to get your idea communicated across the organization. For that, it looks more like a social network. Within your organization, [00:11:30] there’s an informal org chart. And the informal org chart is composed of a bunch of people that don’t make a lot of sense hierarchically, but some of them have a tremendous amount of influence and sway and have built up a lot of credibility and trust.
You want to find those people and you want to make sure that whether or not they’re in the formal reporting chain for something you’re trying to get done. You want to communicate to these people, even if they’re in a different department, [00:12:00] because they have such a tremendous impact behind the scenes. You don’t want to miss out on that. You really want to leverage that behind the scenes communications, because over time, these are the things that can make or break a project when it comes down to those stressful moments of implementation. The next bucket is setting the proper expectations. Now, I told you a moment ago that somebody in the organization, they did some selling [00:12:30] to get the project approved. That’s okay, they had to do that. Now in any form of selling, there becomes a certain… What should we call it? Optimism on what can be delivered, and what can be delivered in what timeframe.
And you might get a little excited when you’re putting together these presentations and you get everybody fired up. At some point, after the project is approved, [00:13:00] now we have to deliver it. This is why I said earlier sometimes what you might be asked to deliver might be a little different than what was sold, because now you have to start managing reality. And just understanding that should help calm you down a little bit, because a lot of technical people I know get very, very frustrated when they are told, “Well, so-and-so told me [00:13:30] that you were going to do X,” and you’re thinking in your mind, “Why is so-and-so allowed to be a citizen of this company? If they were that far off base of what I could deliver.” Just calm down, know that they had to do some hard selling to get the project approved and just understand the delivery piece is going to be a little messier than what was actually sold.
Nobody did anything intentionally to try and derail you or to make your life more miserable. [00:14:00] And so what you can do is you can keep selling, but you can start working with people to help them see the long-term benefits versus just the features. So let me give you an example. Many, many companies with whom we work at Dremio are implementing a very aggressive cloud transformation projects. And if you’re in an enterprise, odds are you have one or 10 of these projects going on at the moment. And they’re very big and they’re very visible, [00:14:30] but as you know, they’re also very, very complicated. They’re multifaceted. And so instead of getting people constantly focused on this or that feature, remind them why we’re doing this larger project. Ultimately, it’s going to be about business agility. Ultimately, it’s going to be about reacting faster, creating more scalable infrastructures, keep them focused on the long-term benefits.
And you will still talk about the individual features, but just know the selling [00:15:00] doesn’t stop after the project gets approved. In fact, that’s one of the things I see go wrong is once the project is approved, people think they have to quit selling the value, but you don’t. You want to keep talking about that over time. And then as I said, just when you’re doing that, just to reinforce this point, make sure you’re using the same collateral, so that you’re all speaking the same language as you’re going through it. And then finally you want to make sure that you’re providing visibility into what’s happening [00:15:30] and not transparency. So let me give you an example, because that may sound a little bit like, “Don’t we have here a difference without a distinction? This sounds like the same thing,” but it’s not. The example I give is my doctor.
So let’s say I go in for my annual physical to my doctor and she prescribes a normal battery of blood tests and it goes off to the lab, and now I come back and her name happens to be Teri. So I sit down with Teri and I say, “Okay, Teri, [00:16:00] how are we doing?” And she pushes across the table all the raw lab results, not the pretty app, but just all the lab results. And it’s in all this medical jargon, and biology jargon, and chemical jargon, I don’t understand any of it. And I say, “Well, Teri, how am I doing?” And she says, “Well, Billy I’m being transparent. You have all the information, don’t you? Like there it is. You have it all in front of you.” It’s not visible. [00:16:30] I can’t see anything that makes sense out of that. Now research actually backs this up.
What happens is we get metric happy when we have these projects. And so McKinsey did a really interesting study on transformative projects, and here’s what they found. That by the end of the project, only 29% of the metrics that were going to be the metrics that were going to be the master dashboard, or sorry, only 29% are [00:17:00] being used. So when you have 71% of the metrics that are not even being used, you’re cluttering people’s ability to understand what’s happening. So think very carefully about which metrics you want to use, and I will tell you fewer is better when you’re communicating broadly. And you can think about this like two triangles, but inverted. The smaller your audience, the more detailed you can be with metrics, but the bigger your audience, [00:17:30] the fewer metrics you want to have. You want to paint a very clear picture at a very high level.
This isn’t easy to do, but it will help you tremendously around expectations of how things are going. How is the implementation of that actual project proceeding? Okay and finally, we’re going to look at time to impact. What can we do to help make sure that these projects start to feel momentum very early? Because this is very important when this happens. [00:18:00] I want you to think about snowballing the early wins. Some of you may live in warm climates where you’ve never seen snow or got to play in snow, but you make a snowball by you grab a little bit of snow, you pack it together tightly, grab a little bit of more snow, pack it around it. All of a sudden, just adding that snow, the snowball gets bigger and bigger, then you put it on the ground and you roll it, and then it really starts to pick up steam.
That’s the mentality [00:18:30] we want to have with early wins for these transformative projects. We want to make sure that you are demonstrating very early on that you are capable of making progress and successful progress. Now, here, again, same study from McKinsey. This one, I have to say I’ve intuitively believed this for a long time. This was really helpful for me to see this done with [00:19:00] a solid methodology behind it. And what they did was they said, “Okay, let’s break the perceived value of a particular feature. Let’s break that perceived value into three buckets and we’ll call those boulders. And for boulders, we think this feature is going to have a greater than 5% value impact to the overall project.” The exact methodology, I don’t know, I’m not smart enough to work at McKinsey, but they just figured out a way to say, these are big impact [00:19:30] features.
Then they boiled it down, they said, “Okay, let’s talk about pebbles. And pebbles are going to be 0.5 to 5% impact on the project.” And then finally little tiny grains of sand, less than 0.5% impact on the project. And you would think that the boulders would be the ones that by the end of the project, that everybody was just in awe over how spectacular they were and what a difference it made, but it turns out [00:20:00] actually the opposite effect. The value of those boulders erode over time, because generally those features are so big and so complicated. And they take so long that the ones that were executed well that were smaller, end up getting more impact because they get revved faster. They have fast feedback loops, they get the minimum viable products out there, and then they tweak it and change it, and you end up [00:20:30] with happier users at the end.
So you have about 50% of the perceived value, but at the end of the project were just those little tiny grains of sand. And about 45% of the value of the project is those little pebbles and only 5% are those giant boulders. And there’s a corollary mistake that can happen here if you focus too much on those giant features in the beginning. And that is you end up in this state of heroism. [00:21:00] On your teams, just by virtue of probably experience or background. You’re most likely going to have one, two, three people, depending on how big your team is, who really understands what needs to be done at a deeper level than the rest of the team. And they got to bring the rest of the team up to speed. There’s a lot of information sharing and education that you want to have happen as these projects progress.
If you’re not careful, what ends up happening is you take those best people [00:21:30] and you put them on those big boulders that you think are going to have that biggest impact. But we just saw that the boulders erode over time, they don’t often make it to the finish line. So your best people they’re drowning. They’re frustrated. They feel like they’re wasting time all back to that first slide that I talked about, and you don’t want that to happen. You don’t want to burn out the people that you need the most. And so think [00:22:00] about as you’re assigning responsibilities early on in the project, maybe sounds a little counterintuitive, but take some of your best resources and maybe put them on some of the smallest implementations. Some of the stuff that you may not think has tremendous amounts of business impact, but watch what happens when you start delivering those small things quickly and you get fast feedback and you start making changes, and then your end user starts seeing that value.
Everybody’s confidence goes up [00:22:30] in the project. And I think you also have the potential to share information faster across the implementation team, the technical team. And then the next one here is as I said, these projects are disruptive. Don’t bother people until you’re ready for them to be bothered. And I mean that just the way it reads. You are going to bother people. Now, I know we want to believe that the project we’re working on [00:23:00] is the most amazing project in the galaxy and it’s just going to blow everybody’s doors off. And fact is the business should be coming and prostrating themselves in front of us because they’re so happy at what we’re building for them. The reality is you’re rocking their world. There’s control shifts that are happening. There’s budget shifts that are happening. There’s resource shifts that are happening and you’re making people nervous with the project.
[00:23:30] And so once the initial project is approved, try not to bother so many different people in the business side until you absolutely have to, until you’re ready to bring them in. Then even better, what if you could take some of the early wins that you’ve accumulated with maybe one of the business areas, and when you go to bother the next one, you say, “Oh, by the way, here’s what we accomplished in the last six weeks over here in the other side of the company.” That gives that [00:24:00] person much more confidence, that why they’re being bothered is for a really good reason. Now don’t get me wrong, you may think, “Not in my company, my company everybody’s bought in.” I’ve been doing this long enough to know the gray hair has given me a few wisdom nuggets over the years. And one of them is that when executives say they’re bought into the project, intellectually assenting to that is one thing, but emotionally buying into it is something different.
So you are going to rattle cages with these projects. [00:24:30] If you’re not the project, probably isn’t transformative anyway. So just be aware of it and think carefully about how you do it. So I want to wind up now, as we think about those three categories. You’re going to be able to communicate more effectively. You’re going to be able to really set expectations in a more meaningful way. You’re going to be able to think about that time to impact and how to accelerate that and make that as quick as possible. But I also now want to end with even more personally, [00:25:00] what does it really mean to you as an individual? Because hopefully you’re very happy with where you work and hopefully you’re very excited about that company being successful, but at the end of the day, once again, we’re all human and we all have our individual aspirations.
So what does this mean to you in your career? One thing I want you to think about is when people get really busy and embedded in these projects, sometimes they get very myopic and they get into these echo chambers of hearing just what’s going on in their company. [00:25:30] Please try to stay connected with a broader network of your peers. This conference is a fantastic way to do that. This community now has over 10,000 members. We have Slack channels and videos you can go back and watch. But look, whether or not it’s this conference, just find some way to stay plugged in to people because it will help you in two ways. One, you’ll start hearing the problems everybody else has and you’ll realize you’re not alone. Everybody’s facing the same problems. [00:26:00] And two, you’re going to pick up really good nuggets of information, maybe somebody solve something quicker than you did and you can bring it back to your company and implement it there.
So stay connected as you’re going through these projects, because they’re hard and they do take their toll on people. The next one is I want you to consider how you can become maybe a hub in some of those informal networks inside the company. What would it take for you to be the one they trust, maybe a little extra communication, [00:26:30] maybe a little extra empathy that you understand it’s affecting their role, maybe a few extra hours in a month to go grab a Zoom call with somebody on a different team. But how can you elevate your status? You don’t need to move on a formal org chart to significantly advance your career. In fact, I’ll tell you sometimes moving internally in an org chart is actually hard and counterproductive because everybody thinks like, “Oh, well I know her. She [00:27:00] used to just be this and now she thinks she’s…”
The way to really get ahead is to increase your status in that informal network. So give some thought to that on how you could do that. Some of it’s just a willingness and just spending a little extra time. The next one is you’re going to learn a lot and that learning is going to make you incredibly valuable to the market. So I want you to really think about what goes well on these projects, but I also want you to think about what goes wrong on these projects. And when [00:27:30] that happens, jot it down, throw it in your favorite text editor or note taker or whatever, put a date on it and put what you’re feeling a little bit about why something went wrong. And here’s why when you’re being interviewed later for a different opportunity. It could be an opportunity in your same company, a different department, maybe on your same team, maybe a different company, it doesn’t matter.
When you’re being interviewed, here’s what we want to see. I’ve hired a lot of people over the years. Here’s what I want to see. Of course, [00:28:00] I need technical acumen. Of course, that’s a no-brainer. And the better you are technically, obviously the more I’m going to want you on the team. But if you want to elevate yourself into elite status, bring that technical knowledge, but bring a little bit of business knowledge along with it. So when I ask you, and I say, let’s say it’s one of these cloud transformation projects. And I say, “Have you ever been through one of these projects?” And you say, “Yes, I have.” [00:28:30] Okay, that’s great. I’m glad, I’m glad you got the expertise. But imagine if you said, “Yes, I have and let me tell you, Billy, I can tell you about some things that went right, that I’m eager to try again, but I can tell you about four or five things that went wrong that whether or not you hire me, you’re going to want to avoid.”
Now you start talking to me like that and you bring that technical ability with you to that conversation, but you tell me that you understand how this business [00:29:00] thing works and how these projects are hard, your stock just went through the roof. And so think about how you can learn every step. And by doing that, hopefully it gives you a little encouragement, even when things are going bad. That’s not always a bad thing for you personally, because you’re learning. So if you take it and apply it going forward, it can be a really powerful thing. And then finally, and I’ll leave you with this one. Remember careers are often at stake, including yours. So I want you to think about [00:29:30] these projects, not as just something great for your company, which they are, and not as just something great for your customers, which they are, but these projects are awesome for you.
Yeah, they’re hard. They’re complicated. They’re going to come with a lot of problems and you know what? Sometimes somebody is going to take your product and they’re going to try and use it the wrong way and the teeth are going to come off those blades and some people are going to get cut up and that’s okay. It’s going to happen, but just have some empathy [00:30:00] for people when they’re going through the emotion of it and give yourself a break too, have some empathy for yourself. So hopefully by remembering these things, you can understand how to have greater impact on all your projects when people are the problem, not to technology. Please have a great rest of the conference and look forward to seeing you soon.