Host Jesse Anderson takes the guest seat to discuss diagnosing and fixing the common problems encountered when building your data dream team.
We’ve turned the tables and placed Natasha in as host and put Jesse in the guest seat, to talk about his favorite chapter in his book. Jesse will share how to diagnose and fix the common challenges and misconceptions that can arise, on the journey to building high-performing and functional data teams.
Welcome to the Soda Podcast. We're talking about the Data Dream team with Jesse Anderson. There's a new approach needed to align how the organization, the team, the people are structured and organized around data, new roles shifted, accountability, breaking silos, and forging new channels of collaboration. The lineup of guests is fantastic. We're excited for everyone to listen, learn and like.
Greetings everyone. I'm Natasha, and we're turning the tables around for one show only. I am going to be asking our host Jesse Anderson, all of the questions. That's right, and here's why. When Jesse wrote Data Teams, the book, his favorite chapter was 13 titled, Diagnosing and Fixing Problems. And we thought that would be a great conversation to hear from the years of experience. Jesse has built up consulting and building data teams.
We're going to be talking about common solutions for common problems that occur when you are building, managing, and growing your data dream team. So, Jesse, to get us started, could you give us just a brief introduction of your background in building data teams?
Sure. So my background is I'm a consultant and I'm a consultant who's brought in to deal with sometimes the worst of the worst problems and sometimes the companies who are trying to head off the problems. So in that sense, I've seen the worst of the worst where when somebody comes up to me says, I'm/are we the worst? Probably aren't because I've dealt with the worst. So I've been able to go through and help companies establish their data teams from the very beginning or to go through and actually fix a data team.
Super. Now, a Spider-Man once said, with great power comes great responsibility. So tell me, Jesse, is it true that with big data comes big problems?
Oh, it's definitely true, and it's because companies will often either misunderstand or not really comprehend the change that they're going to go through with big data. They think that it's maybe a little bit different than software engineering or perhaps that data science is all you need. And this is when they get into big problems, not realizing the difference and not really accounting for that difference in their product plans or their company plans.
So could you give me the top three common challenges or issues or problems that you've encountered whilst working with data teams of all types and sizes?
The top three are definitely the ones I've written the most about. And one of those is thinking you can do everything with data scientists. That's a big problem. The next one is taking their data warehousing team and saying they're the data engineering or big data team. That's another big problem. And perhaps the third one is the management at the top not really buying into or not really wanting to spend the money or time to do this the right way. So they've heard something, let's say from some CIO magazine or some CXO magazine, but in that CXO magazine, they don't say, in order to attain that value, we had to do X, Y, Z. Those are the three most common problems I've seen.
So interesting. It's around some of that sort of role accountability, responsibility and understanding where people fit within the team. Right? And it doesn't fall just on one part of the team. You need all of those parts working together.
Yeah, and I'd also add that it's not just youyou may have expected to hear me say, here's this technical issue. Well, it isn't a bunch of technical issues, usually. It may eventually become technical issues, but it all starts with people issues and organizational issues.
I've known you for long enough, Jesse, I knew you weren't gonna talk about technical issues and focus on the people. So in this chapter 13, diagnosing and fixing problems in data teams, you break it down into six areas, sort of six umbrella areas: stuck teams, underperforming teams, the skills and abilities gap out of whack ratios, project failures, and silver bullets. And lastly, the holy grail. So I'd love to go through each one and break it down. Give us, you know, a key takeaway for each one. You have several examples in the book, which people should of course go and get. But where are the common problems occurring and what have you found to be the best solution that you've applied to help organizations and their teams overcome these challenges? So let's kick it off with stuck teams.
So stuck teams are important because your team, you may have hit a point or a level where the team cannot get past that complexity. So the key issue there is, looking at the team, seeing who you have on the team and do you have the right people on the team? And that's usually the issue with stuck teams. You have the wrong people on the team, you misunderstood what you needed and you need to solve that.
Underperforming teams.
Yeah, stuck teams and underperforming teams may sound like the same thing. In fact, when I was writing this, the editors pushed back on that and said, isn't this the same thing? They're not. So with underperforming teams, they're always at least getting something done, but it's never at the level that you think or that it's never at the level that you'd expect. So with underperforming teams, they're getting things done, but they're still not able to get to the levels of complexity or the levels of value that you are reading about. The solution for this one is the same. You more than likely have the wrong people on the team. And it's a team issue that you need to fix.
Okay. The skills and ability gap?
Sometimes when companies embark on their big data project, they forget that there's brand new skills and they're thinking, well, we can just buy some books. We can do some cheap online learning, some MOOCs or something like that, and people will just soak this up. It's not always the case. You need some pretty smart people to start out with that. So that's a definitely issue. You, you need to make sure that you are giving your people the resources. And then there's ability gap. And what ability gap means is, the people on their best day, even with all the help, even if I personally were to sit with them in a class, help them, still not going to be able to get this. And this is where it takes some real honesty with yourself to say, oh wow, this person just is not ever going to get it. And you're going to have to deal with that in a different way.
Okay, now moving on to out of whack ratios.
In these cases we have companies where they started off with very data science heavy. So they may have a ratio of one data scientist to zero data engineers, basically an infinite number of them, in their ratio. So we have a significant imbalance, or we may have, let's say five data data scientists to one data engineer. That's not the way you want your ratio to be. What you want your ratio to be is between three to five data engineers per data scientist. That's key. It's the inverse of that. And so these out of whack ratios, you will see various problems if your team's in this. And so your solution, in general there, is to hire more data engineers.
Project failures?
Project failures are important because sometimes companies go from project failure to project failure and never really learn. They say, oh, it was that technology, this cloud thing didn't work or whatever didn't work well. And it's harder to look internally and say, oh wow, we really messed these things up and we just come in and we don't do them right. So we really want to have our project failures. We want to have good, sane goals, good sane things that we're trying to do. Otherwise the team is behind the eight ball from the very beginning. And that's not where you want your data team.
All right, almost there. Silver bullets.
Silver bullets are when the company, and this is usually management, has read something and some CXO magazine and they've said, oh, this data science thing is going to save the company. And it probably isn't because they're just looking for silver bullets or they're just thinking, Hey, this big data thing, I hear about it, want to do it, don't really know it, but I know it's going to save the company. When you're in management and you hear that, you think, oh my goodness, they really don't understand it. We're never really going to find the value and we're just going to strive after another thing that doesn't work.
All right. And then lastly, but not least, the holy grail. So this was the technical holy grail, right? When it comes to big data.
Yes. This is the technical holy grail where somebody sat in the audience of one of the big companies, one of the Apple’s, Google’s, and they went through their architecture and the usually CXOs sometimes architect says, oh, I'm taking a picture of that and I'm going to send that to the team. And that's what we're going to replicate. And that's one of the worst things you can do. As we heard in even Holden's interview. I actually, she's worked at Google, she's worked at Apple, and I asked her this question, should you replicate these? No. The reason is they're solving very different problems than when you're trying to do, if you just drive after a holy grail, you'll more than likely fail. Not just because it's technically really, really difficult, but because you'll be solving problems that either you don't have or solve problems that you have that grail architecture won't even solve or deal with.
What I love when I see these sort of key areas, Jesse, is that they're all sort of linked together, right? And it sort of shows you how well coordinated you have to be when looking at your team because you might have the greatest technical architecture, but if you don't have the right ratio of roles across the team or the right skill sets across the team, it's gonna fail, right? You're gonna have a problem there and, and not meet your, your challenges.
Definitely.
Okay, so tell me if we could look at this list from another angle, what would be the six areas for the fastest time to value? So really getting that ROI on your business case.
You're starting out with some of these areas, and then quite honestly, some of these other parts will just fall out of that. They'll fix themselves by doing this the right way. So it's kind of foundational here. So your foundation is to get your ratios right, then make sure, or perhaps at the same time figure out any skills gap and ability gaps. And then if you do that right, you may have some underperforming teams, but you've actually set them up with a better foundation. But these underperforming teams, this is important because underperforming teams and stuck teams do not fix themselves. You'll likely have to get outside help in order to figure out why they're stuck and to get them unstuck. So that would be where you'd want to have some ROI there. From there, if you are looking for silver bullets, hopefully you haven't done that, the silver bullets are not what you want to be looking for. And likely, maybe you do choose a holy grail for some reason. Maybe you can attain that with the right team, maybe not, and then out of that, if you've done all this the right way, then you could have your, you'd be avoiding those project failures. Your key ROI starts with the right ratios and the right people with the right skills.
And I remember, I think in Jordan Morrow's episode on data literacy, he talked about having that map, right? It was specific to the skills matrix that he had, but really knowing and understanding your team, and like you said, sort of mapping it out, seeing where your, your strengths, your weaknesses, your gaps are will help overcome some of these for sure.
Yeah, and I talk about doing that in the book as well, as creating an assessment. So I go through how to do that assessment in the book so that you can see what skills are missing, what skills you have very strong. And what's key here is honesty. It is incredibly important for the managers to be as honest with themselves as well as with their upper management of what's possible.
Great. So during this Data Dream Team series, we've talked about the different roles on a data team, asking our guests to share their favorite roles. And of course people were very hesitant because nobody likes to choose their favorite child or their favorite pet or their favorite color, but it was the roles that they admire. And the data engineer, it comes up high there, right? We're not yet at the episode where we get to reminisce, but I must say the flag flew really high for the data engineer throughout. So which role, if any, is often caught in the crossfire of these common problems that you see when teams are stuck, they're malfunctioning, underperforming, whatever it might be?
I think each team, depending on the situation, will get some amount of crossfire. But if I were to choose one getting the most crossfire, I think it's the data engineer. Because what you'll often get is there is one data engineer with five, ten data scientists all giving them work. So if you think there's a lot of crossfire, just imagine if you have 10 people vying for your time with all sorts of different requests, and the inability to do that, that's a really tough position to be in. It frankly isn't fair to that person, and they will leave. And it's of your own doing, frankly.
So you've talked to some fantastic guests in this season. I remember when we did your first interview way back in episode one or two, and I was, I still envy the roll call of guests that you got to speak to. And even though we're not done yet, tell me, if you were writing edition two of Data Teams, what would you add, change, or remove in this chapter based on the insights you've gathered and the conversations that you've had? Are there any new approaches or frameworks that would influence this for you?
I think it would be getting Holden to write a section because sometimes people will say, Jesse, you didn't work at Google, you didn't work at Apple. And so I would say, Holden, would you write a section for me that just says, listen to Jesse or even say don't do, don't do this…
What Jesse said.
…this is actually. Yeah. Or maybe we would change the book to be more like a bunch of plus ones. So it's a chat and there'd be a bunch of likes around certain parts and who liked it?
As you open up a chat, did these thumbs just come flowing up out of there?
Yes. And it would be from each person saying, yeah, this, I especially like this and here's why. And that was kind of the way I originally envisioned the contributions that I have in the book. I wanted people to read what I said and then - oh, here's, actually what I think about that. And here's what I want to say about that too. And I think it was successful in that I, but I think it would be adding even more of those people saying - oh, yeah, hit that, here's what you should be doing.
So there's a shout out to Holden to get ready for Data Teams’ edition two, and any of our other guests who can help endorse some of those messages and key points that Jesse brings across. I love it. So, Jesse, remind me, what is the theme tune for diagnosing and fixing problems when it comes to your team?
At the beginning of every chapter, there's the tune. And the tune for this chapter is Daft Punk’s harder, better, faster, stronger. And if that isn't playing in your mind stronger, then you've never heard the song, but it's Daft Punk saying that over and over again.
It's a good one, work it harder, make it better. Has ever a true word been spoken for data? Jessie, what would be your go-to advice when you get stuck when your teams aren't performing well? When you are looking to resolve those out of whack ratios, project failures, catch those silver bullets and get your grip around the holy grill, what have you found the most valuable go-to?
Your go-to is honesty. It starts with honesty. It's looking at the problem honestly, and not just saying - well, we've got this, or the team can get themselves out of this, or whatever excuse instead of attacking the problem. So my advice, my go-to advice is these problems don't work themselves out. I've talked to teams, I've talked to managers, I've talked to CXOs where they thought this, you know, a year later looking back, they look back and see they're doing the same thing as they were last year. So the go-to advice is honesty, and this doesn't work itself out. You may need help, but you have to do a concerted effort to fix these things.
Great. So I have a hard question for you. It's somewhat mean because I think it's really hard to answer, but I'm gonna give you a go. What does good look like? What does it smell or feel like? I mean, you wonder, is it ever tangible? I joke a little there, but in this strive for data dream teams and that data glitterati status, how long do we persevere to be able to really realize the value, the data value in our hands?
Well, for our clients, you're looking at, with concerted help with good motivated people, you're looking at a six month to twelve month process to get that value into people's hands. It's even longer if it's more complicated or you're not getting as much help or you have less motivated people. But I also want to point out that, as much as you see, there's some sort of inception point or there's some sort of, at this point, we gain value. I wanna stress this is an ongoing process, so it's an increase in velocity as I talk about in the book. It's a gradual increase in value. So the answer that I give to this question is it's more like a breakeven point in value where the amount we're investing, we're starting to hit that breakeven point where now we can hit that hockey stick of value creation based on our data.
That makes sense. So Jesse, I would love it if you could read to our listeners two of your favorite excerpts from this chapter, diagnosing and fixing problems.
One of my favorites is this one: Is there any simple way or shortcuts to these problems? I'd often get that from management who'd grow impatient and say, let's press the easy button somehow. Here it is. Yeah, sometimes there could be more straightforward solutions to problems. Finding simpler solutions to problems is a crucial place where your veteran skill comes into play. The value of the veteran’s skill is to keep the team, especially new data engineering teams, from doing something stupid. This could be solved by finding a more straightforward way to do the same thing. Also note that the simple is relative, and there won't be a time where management is marveling at how simple things are. Some teams and organizations will try to do everything and all at once, no matter how difficult the implementation is. I highly recommend breaking down projects into more manageable and more straightforward steps, namely, crawl, walk, run.
By breaking down much more extensive and long-term tasks into shorter, more attainable tasks, a team will be able to create the velocity necessary to accomplish the challenging parts. Teams that are brand new to distributed systems or big data can easily get overwhelmed. It can look incredibly convoluted from the outside when the team members start to look at what's required. Teams can't go from zero small data to one hundred big data with ease or without growing pains. Your veterans should be there to help the team break down the complexity into more manageable parts and guide them through without overwhelming the feelings.
And the second one is: We followed everything our vendor told us to do, and we're still not successful. The sad truth is that many vendors are in it for themselves and not their clients. The vendors will tell their clients whatever they need to, to hear to make the sale.
The salespeople are more worried about losing a deal than keeping a long-term client during a sales cycle. They will tell you how their product solves a problem rather than selling the right tool to solve the problem. The salespeople are also blinded by the need to map every technical issue to their solutions, no matter how poor a fit the technology is for the use case, or how poor a job the vendor did at implementing the technology. Sadly, some clients depend on outside vendors to give them advice about technology. When the vendor considers it the client's duty to make the right choice for themselves. Other vendors are in a fishing expedition to find someone, anyone to use their products. This is especially true for new products that a vendor creates. They're more interested in adoption numbers than real client success with a product. This leaves the client holding the bag when the product is ultimately unsuccessful.
Superb. Thank you. You read your book well, Jesse. Well done.
Thank you. Now I just need a future Shakespearean accent and I'm ready to go.
I think so, I think so, our final question for you, Jesse. You know, data teams will continue to evolve as data will keep growing and systems and technologies advance. How do you see these challenges?
I see these challenges increasing, getting more difficult, and in some cases standardizing around certain architectures. So what I mean by that is some parts are pretty standardized. You could say that ETL is going to be the same between one industry and another, and we'll eventually see solutions, and we are seeing solutions that handle that. However, ETL is not your biggest difficulty, frankly. Your biggest difficulty is taking that data and making it useful, creating value with it. That's where it's difficult. That's not where we're going to see the standardization. That's where we're going to keep on using these general purpose systems to create value. And that's the difficult part. That's why you need smart people with good heads on their shoulders and being motivated.
That's fantastic. Thank you, Jesse. Thank you for your time. I think my biggest takeaway from today that I'm left with is your insights into - start in an honest place, be realistic about where you are. And I think that applies to really tackling and being able to solve some of the biggest problems or overcome some of the big hurdles that people may have. So thank you.
Well, Natasha, thanks again. It's nice to be on this side of the microphone where now I get to talk ad nauseum about my thinking and instead of asking the questions and coming up with witticisms every so often.
Well, you did well and I'm glad you enjoyed it. So that's it listeners. What's next? We're reaching the end of the season, season one of the Data Dream Team series. Our next episode will feature Soda’s CEO Maarten Masschelein, looking back at almost 800 minutes of data team talk with Jesse. They'll be reminiscing on some of those golden nuggets that we've picked up throughout the season and selecting their favorite stories from our fantastic guests. To stay connected, until that episode drops, visit dreamteam.soda.io and catch up on all the conversations that have taken place. You'll also get an easy and quick link to get access to Jesse's book. We'll see you back here soon at the Soda Podcast.
