In this episode of Experiencing Data, I speak with Jesse Anderson, who is Managing Director of the Big Data Institute and author of a new book
titled, Data Teams: A Unified Management Model for Successful Data-Focused Teams. Jesse opens up about why teams often run into trouble in their efforts to build data products, and what can be done to drive better outcomes.
In our chat, we covered:
“I have a sneaking suspicion that leads and even individual contributors will want to read this book, but it’s more [to provide] suggestions for middle,upper management, and executive management.” – Jesse
“With data engineering, we can’t make v1 and v2 of data products. We actually have to make sure that our data products can be changed and evolve, otherwise we will be constantly shooting ourselves in the foot. And this is where the experience or the difference between a data engineer and software engineer comes into place.” – Jesse
“I think there’s high value in lots of interfacing between the tech leads and whoever the frontline customers are…” – Brian
“In my opinion-and this is what I talked about in some of the chapters-the business should be directly interacting with the data teams.” – Jesse
“[The reason] I advocate so strongly for having skilled product management in [a product design] group is because they need to be shielding teams that are doing implementation from the thrashing that may be going on upstairs.” – Brian
“One of the most difficult things of data teams is actually bringing together parts of the company that never talk to each other.” – Jesse
Brian: Hello, everyone, welcome back to Experiencing Data. This is Brian T. O’Neill, and today I have Jesse Anderson on the line, the managing director of the Big Data Institute. Jesse, what’s going on?
Jesse: Not much. Great to be here. Thank you for inviting me.
Brian: Yeah. So, you have a new book out, this is not your first text. So, first of all, congratulations on that. I know, it’s always a slog getting through a book, at least that’s what everyone says that writes books. So, why do we need a book about data teams?
Jesse: you need a book about data teams because I wanted to bring the other teams into the picture. And instead of just focusing on the data science team, I saw the need to bring in the data engineering team and the operations team and really educate managers on saying, “Well, you need more than just data science to do this right, and here’s why.”
Brian: So, there was a premise that being successful with big data means go get a data science team; done. Is that kind of the premise?
Jesse: That’s kind of the premise right now. And it isn’t just a, “Here’s what I think is happening,” I’ve actually dealt with the companies where they went out and hired that data science team and started scratching their head of, “Why are we having problems? Why are we not getting the value that we saw when we sat in that audience at the conference talk, and the person said, ‘Oh, my goodness, we just [00:01:49 unintelligible] a checkbook,’ or, ‘we were just bringing in the cash.'” this is why.
Brian: Got it. Got it. So, the text, by the way, is called Data Teams: A Unified Management Model for Successful Data-Focused Teams. So, why did you feel like this needs to come out now? Why not two years ago? Why not, you know, in a couple years from now? What prompted the need for this right now?
Jesse: To be honest, it would have come out last year. [laugh].
Brian: [laugh].
Jesse: Besides logistical reasons, it’s really time for us to understand from a manager’s point of view what we needed to do. I think this is timely information. I think it-some companies will obviously have a team in place, and it will help them understand why it’s either underperforming or maybe if they’re really lucky, why it’s performing so well. Maybe they don’t have the words or the experience to say, “Hey, this is it.” In general, what I’ve always tried to do is share my experience and knowledge.
I think for me, I brought a different level of experience than most people have. Instead of writing about my one company, since I’m a consultant and I’ve done this for so long, I have all that experience to bring to bear. And I went a step further. I went and started talking to other people. In the book, there’s interviews with other companies, so that you just don’t hear my point of view, I want to bring other people’s points of view, what problems they had, what successes they had, and really create a compendium of knowledge.
Brian: Yeah. I did see that I wanted to compliment you on something else, format-wise, which I thought was really compelling in the text. The text is not long-read format. You’ve broken it up; there’s a lot of section headings.
So, imagine chapters with lots of subtitles in them. You’ve collected some of these around problem statements, like, “My team shipped something and nobody liked it and used it,” and then you have a section about that. And so I thought that was very problem-oriented because it’s very easy to scan the text table of contents and say, “Well, that stands out to me. I know that. I feel that. Let me jump into that.” So, I thought that was an interesting approach. How did you come up with that? Or where did that inspiration come from?
Jesse: It came from seeing the same problems over and over again. And the people, as I’ve both talked to people and done some of these interviews, it’s more of a therapy session than it is a sharing of knowledge sometimes, where people want to know, “Were the problems that I was having similar to other people’s?” And this is what I’m trying to show in the book is, “Hey, if you’re having this problem, not only are you not unique, so many other people have had this problem that I wrote a subheading in the chapter because it’s all experienced-based. I hit this several times. I hit it enough to go through, write a section about this so that you can know about this.” Let me share what I did when I wrote the table of contents. I spent about a month just kind of brainstorming and going back through experiences at all these companies and just writing it down, what I saw, and then bringing that together into here’s what I wanted in that chapter.
Brian: Got it. So, I want to step back one more time to who is this for?
Jesse: This is primarily for management. I have a sneaking suspicion that leads and even individual contributors will want to read this book, but it’s more to be able to say, “Hey, look. This is why-you know, give this to my boss. Give some suggestions to, kind of, manage upwards.” But this is definitely primarily written for middle and upper management, executive management.
Brian: We’re talking about analytics, data science, on the technical side, software engineering, these disciplines?
Jesse: those sorts of disciplines then, where they may be at the point they’re going to start a team, they’re trying to fix that existing team. Various possibilities there.
Brian: Got it. Got it. So, first of all, let’s talk about data products for a second. So, what is a data product to you? I want to set that stage, and then I want to dig into this a little bit. What is a data product? And you make a distinction here about what a software product is, and a data product. So, help me understand your distinction there?
Jesse: Sure. And you bring up a very valid distinction that’s, I think, is important for management to understand. A software product is usually, “Here, I’m deploying a piece of software out there, a REST API, something like that, where the end product is putting something into production that serves whatever we need.” API, for example.
Data products, when we’re in a company, and we have a data product, we have a product that is data. That is what we actually get out the door. It isn’t software. Software, obviously, creates that data product, but the data product is what we deliver. And that’s a different thinking, whereas we compare that to, let’s say, software engineering. And if we have a REST API for example, and we want to change that, we can just do v1, v2, v whatever.
Well, with data engineering, we can’t make v1 and v2 of data products. We actually have to make sure that our data products can be changed and evolve, otherwise, we will be constantly shooting ourselves in the foot. And this is where the experience or the difference between a data engineer and software engineer comes into place. The data engineer needs to have the experience and knowledge to be able to say, “This is how things will change.” Or, for example, on a data scientist, as a data scientist consumes that data product, how is that data product going to be exposed in such a way that it’s useful to not just data scientists, but to analysts, and to the rest of the organization? It’s a key metric that we look at to make sure that we are using the right things, we’re exposing the right things.
Brian: So, the distinction you’re making here, I want to understand if this is important primarily to a technical audience. Like, who is it important to make this distinction to because I’m going to argue that it’s a distinction without a difference to someone who’s on the receiving end of where the value is supposed to happen because no one interfaces directly with data; we interface with data through some type of interface of some kind, whether it’s Excel, or it’s an application, or a Tableau, or whatever the heck it is, there’s an interface at the very end that happens. And I understand that there are sometimes non-interface facing deliverables within engineering, but who cares about that distinction, I guess I would say, why is that important to make?
Jesse: It’s important to make, and you’re completely right. If you are making the business consumer care about this distinction, you’ve lost.
Brian: [laugh]. Okay, good. So, we’re on the same-because I don’t think they care, to be honest.
Jesse: No, and they shouldn’t. What they do care about is manifestations of problems in your data product. For example, let’s say you use the wrong technologies, or you can’t scale, or you don’t have operational excellence, then the business cares that your data product is not usable. That’s kind of a binary thing for the business people; “I can either use this or I can’t.” And the various reasons I can’t use this, usually stem back to a problem in the data teams of three examples I just gave.
One is, if there’s no operational excellence, the business cannot rely on that. If there isn’t sound infrastructure behind it and sound usage of technologies, then we’re missing our data engineering team, and for data science, if we aren’t using the right models, then they can’t use that either because we have a problem of, let’s say prediction, whatever is happening, clustering, it’s not using the right thing.
Brian: So, I think there’s high value and lots of interfacing between the tech leads-maybe not the entire team, and all the data engineers, software engineers, but especially the tech leads-being involved with whoever the frontline customers are, whether it’s an internal customer or external customer, that interfacing is so important to know, what needs to be build? What does a small value look like? How do we ship something that’s useful, as opposed to boiling the ocean and creating these giant data projects that put out large-scale infrastructure that often doesn’t produce any value in the near term? And I’m not saying that there’s not infrastructure work that can’t happen in tandem with what I’m going to just call product development work, which is the solution piece that people interface with in the last mile. There’s not a strong product management component to the book or a design component.
So, I guess my question is, whose job is it to figure out what needs to be built what needs to be plumbed such that we know what all this work is that matters, and it’s not just guessing, and it’s not just saying, “Well, let’s just assemble all these different pipelines here, in case somebody needs this.” And I understand there’s some more laboratory-oriented, research-oriented work where you don’t always know-especially in the data science field, you may not know exactly what you need to bake your cake. You might have to bake 20 cakes before you figure out which recipe is going to work. I get that there’s some variability there. I think sometimes though, we’re building a lot of infrastructure without focusing a lot on the last mile.
So, when is it time to define the last mile at the beginning of the project such that we’re focused on the minimum amount of stuff to make in the data team. And then they feel like it’s a win because someone said, “Wow, this is great. Wow, I want to use this give me more.” That was something I didn’t feel like that was dug into as much in the text.
Jesse: Yeah, and you’re completely right on that I didn’t dig into who should be creating the actual, let’s say, specs, and who should be that interface to the business. In my opinion-and this is what I talked about in some of the chapters-the business should be directly interacting with the data teams. You could go so far as to having a business person, a representative in a daily Scrum, maybe be not every day, but on a daily basis. You could get to that level of interaction between the business or-by the business, we’re talking about this end consumer of the product.
And you’re completely right; one of the actual problems I’ve seen, too, is that the data engineering team will haul off and create massive amounts of infrastructure, with no end in sight, but more importantly, no business objective in sight. And this is a failure of the data engineering team to interface with the business. So, what I talk about in the book is being very close to the business, that the business’s interaction does not stop at the point where we have a data strategy in place. That’s just the beginning of the project. We’ve created a strategy, but we have not actually done something, we have not actually created something that’s ready to go. So, this is a key thing.
So, back to your original question of who, you could say it’s the team leads. I think that the interaction-is in the book, I talk about, you could go so far as to say that there’s four teams, that there’s a BizOps teams that’s needed. And that BizOps team is needed to make sure that what the data teams is creating is business appropriate and solving business problems. And you may have on that team your project managers, your product managers. One other thing that I came out of the book thinking about, both from the interviews I did as well as the extensive reading I did, is DataOps.
If you’ve read those case studies, one of the most, I think, highest and best usage, and most productive teams is actually having a cross-functional team where the product owner is actually embedded on that team. And this way, there is no resource allocation issue; there is no mismatch of requirements that the product owner is actually running that team, and every piece of data scientists, operations, data engineering is right there to be able to create that. There is now no excuse to have something that doesn’t meet business needs.
Brian: This latter thing you just talked about with this product owner being involved, are you saying that’s an alternative way to do it? I guess that the universe that I come-
Jesse: [00:14:24 crosstalk]-
Brian: What’s that?
Jesse: It’s an advanced way of doing it. So, I see that as if you’re just starting out with data teams and trying to do this, I don’t believe that you can go to DataOps, yet. I think what you have to do is you have to get good practices, get the right teams in place, and then once you get to a level of friction-and usually that’s the word I use in there, in the book is-once you get to a level of friction where the problems that you’re having are not team-related, they’re usually about resource-related, and communication-of-goals-related. That’s when your friction is a different story. By bringing those together, you’ll either eliminate or dramatically reduce those levels of friction.
And there’s two case studies that are in the book; one is from Moneysupermarket with Harvinder Atwal, and the other one is from [00:15:10 Mickey O’Braun], where we talked about if you’re familiar with the Spotify model with guilds, and chapters, and that, they actually brought that to data teams, and as a direct result, were able to remove a great deal of friction.
Brian: So, I want to hear if I got this right. Are you saying that having a dedicated, what I’m going to use the term ‘data product manager,’ involved to help these teams be successful delivering value in the last mile, are you saying that’s more of an advanced thing that you don’t need at the beginning of the journey? Bring that role in later? Is that what you said, or did I misinterpret that?
Jesse: It’s not that you don’t need it, it’s that if you make too many changes all at once, you could find yourself just crawling consistently if you’ve made so many organizational changes and so many technical changes, you just can’t get anywhere. So, it’s more about getting you some focus initially, that you have a north star that you’re getting to.
Brian: So, without that person, and again, I don’t care whether or not it’s a separate body, a separate human, I’m talking about the role, the hat that’s worn, so if they’re not there then, what is the chance that we deliver something that’s great? Whose job is it to be the product owner because it feels fairly unmanaged to me if we don’t have a central hub with all the spokes-
Jesse: Let me clarify something, I think that I’m-I think you’re misunderstanding. It’s not that that person, that product manager doesn’t exist initially. It’s that the team structure, they’re not actually embedded on a team, initially, for structure. Yeah. Definitely from the beginning, if you’re an enterprise company, and you have your data engineering team, your data science, and operations, you definitely need some kind of either product manager or project manager in place.
Another piece that I neglected to mention is the data architect, and I have an entire section on what that data architect is, where that data architect’s role is to translate the business need into something that’s actually usable while making sure that we don’t spend three years, four years on nothing. And then, at the fourth year, we have something. We need to be creating value initially. Does that make more sense?
Brian: Well, were you talking about the reporting structure? Like, they don’t need to be on the team? Are you saying it’s like, well, they’re a resource that doesn’t report literally into the product? I guess I didn’t understand the distinction.
Jesse: Yeah, the reporting structure, they may be part of, let’s say, data engineering; they may not. I haven’t seen any specific one to point to and say, “This is how you be successful initially, and this is where I’ve seen the best way to put those project managers.” They may be part of the PM organization, I’ve seen that before. I’ve seen them be part of a data science org, the data science team. But suffice it to say they are within that organization.
Brian: Mm-hm. I want to be clear, too: I’m talking about product and not project, and I think those are very different roles; one’s about looking down the pipeline of what the value is that needs to be created, what are the increments and iterations of work to get there? What should be worked on first, second, third, et cetera? The other one is about hitting the milestones and making sure that the ship is cruising at the right speed the whole time, delivering on expectation.
Often that can be one role, but it’s a very distinctly different one to me. And I think almost the product side is more critical right now because a good data architect, or a good-at least in my experience-a good tech lead can kind of be the project manager if they have disciplined engineering practices in place. They may not need a separate project manager overseeing everything because they have a rigor. I don’t-maybe you have a different take. I’m not technical, but I’m just-know who I’ve worked with and seen, and the really good architects are kind of a cop on the project side, as well, or someone. There’s a tech lead that’s aware of the milestones, and if they’re doing agile, then they’re aware of how many points they can eat in a sprint, stuff like that. What’s your take?
Jesse: I would agree with you on that. Definitely your definitions of product versus project. Sometimes companies are trying to start up a team, and if you tell them you have to start up a team with 20 people, or 10 people, they may not be able to initially. And so what you have to do is you’ll have to have, perhaps initially, your manager wearing several hats, and one of those would be a product manager hat, at least initially. And so, they’re going out and doing some of that interfacing with the business to make sure that they’re working on the right thing.
As the team grows, then that can be a separate person. So, that’s actually a progression that we made at one of my clients of, there was no product manager initially. And what we realized as we tried to triage and deal with all the-we had an initial set of what the data engineering and data science needed to do, but the issue was, what order do we do them in? How do we start getting some requirements in place so that once they’re ready, that we’re ready to rock on that? That’s what that product manager was doing for us initially, but he wasn’t done initial hire. He was a later hire, but it wasn’t super late.
It was more probably from establishing the team, it was probably a year in. Not making a specific recommendation there, it was more, to understand that that initial progression of-in that case, the director of data science was acting as product manager. That then got passed to the data engineering manager that we hired, and then that got passed to an actual product manager once we hired that person.
Brian: Mm-hm.
Jesse: Does that make more sense?
Brian: Yeah. No, I understand. And I’m not saying there’s a fixed recipe either. I think you can either look at it as an insurance hire, where it’s like, this role is going to help provide insurance for your team that they don’t spend a lot of time building the wrong stuff, and at some point the business loses trust in their ability to deliver value because everything takes forever, no one’s clear about what they get at the end, and you end up with just, apparently, a lot of stuff was done, but someone at the end, at the last mile, is not feeling like a lot of stuff got done.
They’re just like, “What? This isn’t the right thing.” So, whoever does the work, regardless of how many human bodies there are, I think someone needs to own that process, just like I think design matters, too, even if it’s not a designer-with and E-R at the end of it-the design of the final last mile of experiences has a lot to do with informing the technical work that needs to happen. Not entirely, there are always security, and audit trails, and all this kind of stuff, you need to have all that in there and it’s not necessarily a user-facing requirement most of the time until it becomes a problem, and then you do need to go back and audit. So, there’s definitely engineering work that’s not part of the last mile product piece.
But I want to talk about this thing. So, talk to me about building the wrong product. And you say in your text, in the book, there’s a shared blame going on here. So, whose fault is this? Not that this is a fault, but where does this problem stem from? What are we supposed to do about building the wrong thing?
Jesse: usually building the wrong thing comes from two potential issues. And one of those starts with the business side, where it’s a political issue, where maybe the teams don’t like each other; they’ve never worked well together; the two managers hate each other. I’ve seen those firsthand. That can be just a complete non-starter, and as a direct result, they will just never really work well enough together to create that correct data product.
Brian: Wait, which sides hate each other? And where did that come from, though?
Jesse: one of the most difficult things of data teams is actually bringing together parts of the company that never talk to each other. That you’re having to bring in analytics, and often analytics has never dealt with the engineering people. And then you bring in software engineering-who should have been dealing with the business people all along, but often don’t, even know it’s part of agile; you’re supposed to do this-and then you have operations who just receive the problems of everybody, and so they’re holed up in this prisoner’s [laugh] prisoner mentality. Sometimes it’s just the sheer effort of bringing those three teams together because usually, they’re part of a different-a separate part of the company that you’re having now to bring together, and have them work consistently together. And then latch business on to that, it can be this recipe for, “Oh, I always hated that person. I never had to deal with them. I’d see them in a meeting once every so often, but I hated them.” So, I’ve seen that before. Does that make more sense?
Brian: Yeah. I mean, there’s always a reason where this stuff comes from. I generally don’t think it’s just personality or something like that. There’s probably been some professional reason why something didn’t work out, a project failed, or somebody let somebody down, something like this. And part of the reason I’m asking this question is a big role of product design is facilitating getting the right people in the room to get aligned around a customer outcome that we want.
This is nuts and bolts product design; it doesn’t happen in isolation, and so you need to pull in these teams. And part of that is to drive empathy for the last mile, to drive a relentless focus on whatever the definition of value is, and making that uber clear to the entire team, even if your part is just to work on this one aspect of some pipeline or whatever it may be, you know how your piece fits into the big picture, as opposed to, like, “I have no idea where this ship is going, but you know what? At this point, I don’t care. I got my repo, I’m checking in my stuff, on to the next JIRA ticket.” To me, that checkout mentality, it’s like, that’s when you’re you better be worried. When everyone’s kind of like, at this point, no one has a vision, the strategy is unclear, I worry there. [laugh] do you agree that this is where stuff comes from?
Jesse: I mean, I’ve seen that before. In fact, what I’ve seen is that the company strategy changes so often, that they don’t even bother implementing it. They’ll sit in the room, they’ll talk, but when it goes to implementing, they know that it’s going to change in a month, so they don’t even bother doing it. And yes, I’ve seen those companies. It’s an unfortunate thing that could put your product manager in the unenviable position of trying to herd cats that don’t want to be herded, or that you’re herding them to Group A, now over to Objective B, and then back over to Objective C, relatively shortly after that. This usually happens-I’ve seen-at financial institutions, or companies without strong leadership, where they’re, kind of, on to the next, shall we say, the next silver bullet.
Brian: Sure. And I mean, this is, again, why I advocate so strongly for having skilled product management in this group is because they need to be shielding teams that are doing implementation from the thrashing that may be going on upstairs. And not only that, they’re also helping the executive team figure out what the strategy should be, and then they manage down. So, I kind of see them as this, like, defensive and offensive layer that sits and manages both up and down to try to keep the team insulated from the nonsense that can happen upstairs, when the strategy is unclear, or it’s shifting, or whatever may be going on. I think they can really help with that role.
And then the practice of getting the right people in the room, that is a design activity: when we’re talking about delivering the value in the last mile and getting people aligned around that aspect, that is a design activity. It doesn’t have to be a designer that does it, but the practice, the skill, the activities there, it matters because if there’s no empathy for the people using this stuff in the last mile, you’re going to check out and go native because you just don’t really know how your work fits into anything. You don’t care, either-[laugh] or you just-it turns into a job. It’s like, check in, check out. And that’s where I think teams go to die. [laugh]. Where value goes to die with all this stuff.
Because these are really complicated systems, and if you don’t know how your stuff fits in, you don’t know how it’s going to provide value. I don’t know, I don’t think people like working on stuff that doesn’t get used. But maybe I’m wrong. [laugh]. I mean what do you-don’t you feel like people get a lot more satisfaction out of their work when they’re like, “We hit a home run.” Or even a base hit. Like, “Accounting was really happy with this thing that we did, the reporting that came out the other end, it’s in real-time now. They’re stoked.” Like, that feels better; it energizes the team. I don’t know what-tell me about-I mean, what are your-what do you think?
Jesse: I talk about that in several different ways. I talked about the team getting velocity, and the way that you get velocity is not just with experience of I now understand Spark-let’s say-better, it’s also getting velocity of, “Oh, wow. My product went into production, and it was used by accounting.” That’s a win for the team. So, it’s structuring your team around wins.
And maybe that’s the engineering manager initially, that does that, maybe that’s the product manager that does that, but you’re structuring things around, “How do I get a win for the team?” One of the things you don’t want to do is create that project I was mentioning of, four years from now we get something into people’s hands. That’s another way for it to go nowhere because inevitably the strategy will change. We also want to make sure that we’re doing the right thing for the business. So, in that sense, if we have the connection with the business that we should-maybe that’s the BizOps, maybe that’s the product owner being in the scrum, or making sure that that data product gets in front of them consistently for feedback-that makes sure that we are actually creating something that is usable, that once we go live, they continue to use it.
Brian: on this topic of usable, or usability in the noun form, designers and user experience isn’t mentioned a ton of the text, so talk to me about whose jobs to own usability of the final result. And have you seen teams working with designers and user experience professionals? How do they evaluate usability, if it’s even evaluated at all? Is it, kind of just, put it out and hope it gets used, and then on to the next thing? Or is there a cycle of iteration improvement that’s not just like, “I hate this go back?” And it’s like, “I don’t know. Well, let’s try this instead.” It’s a guess. What’s your experience there with both formal designers or untrained design, or no design, user experiences? Does this factor in at all?
Jesse: It depends on what the structure of the data teams are. Are they creating something that is used, or has a UI that’s being interacted with, and what is the nature of that UI? So, if you’re doing something that’s customer-facing, hey, one of the things I talk about in the book is that your data engineering team is cross-functional. You may actually have a front-end engineer, you may have a front-end designer, and you may have an actual UI acceptance team, for example, as part of that. Usually, the data engineering aren’t the ones creating that sort of user interface. Usually they’re more focused on the data product.
So, how do we make sure that the-ensure the usability of our data product? We may have those designers on the team, we may have data modelers on the team, that’s a possibility, though, in my experience, the data modeling is usually not the most difficult part of the data engineering roadmap; a data engineer should be able to do that data modeling. Once we go to the data science side, I’ve actually seen some of those data science teams actually have front end engineers embedded on them, so that they can write something that is a prettier, more usable, that goes through, maybe, some kind of user acceptance testing.
Brian: Mm-hm. If I read this book, what do you hope someone gets out of it in terms of activities that they can go put into play immediately? Are there a few things that you can pull out-and I know this kind of a crappy question, right? “Could you distill your whole book down into three easy bullets for me?” But are there a couple things you’re like, “Repeatedly over, and over, and over this happens. I see this all the time: this kind of team with this kind of problem, if you would just go do X, Y, and Z, you’re going to make a dent?” Are there some takeaways like that, or are there too many different small problems that it’s not that simple?
Jesse: There’s one chapter I’m especially proud of, in that respect of, I wrote this chapter, it was basically debugging teams. I can’t remember the name of the exact chapter. But it was this troubleshooting guide of here’s various troubles, where it’s a problem statement of, “We’re not getting enough value. We’re not doing this, we’re not doing that.” And so, I go through those sorts of statements and say, “Here’s the possible reasons.”
And it isn’t, “Here’s the hypothetical reasons that might happen,” it was, “No, this is my experience on when this happens, this is usually the culprit here.” So, that’s one of the things that if you are having problems with your current team, it’s kind of a debugging guide, and you can go through and figure out, “Oh, if I’m always talking about technical debt and that, probably missing a data engineering team; probably missing the right data engineers,” for example, there’s a listing there that shows that. Other actionable things, I’d say, are the case studies. I tried to hit people at various stages of their journey. I have an entire chapter for starting a team; that’s one set of people.
And then I have that chapter on debugging, and then I have the chapters on case studies where these aren’t just, here is s-I’ve been running a team for a year, and here’s my thoughts. Some of those people have been running teams for 10-plus years. For example, I interviewed Dmitriy Ryaboy from Twitter. He started Twitter’s data teams and data engineering. There aren’t many companies doing data engineering for as long as that. So, I was able to get a really long point of view from him that should be really helpful to people to see what are the sorts of problems that happen over the long term?
Brian: Cool, cool. I want to give you the last word on the book, which again, is called Data Teams: A Unified Management Model for Successful Data-Focused Teams. Jesse, it’s been great getting your stuff, but before I give you the last word on whatever you would like to close with, I’m curious-and you just mentioned Twitter here-is there any meaningful distinction in the text here, or in your mindset, about the way software companies make software and data products versus traditional companies because, as you may know, there’s-[laugh] the non-digital natives are sometimes worried about the tech companies coming in and eating their lunch, but what I find is that a lot of them don’t copy the way software teams-and I come more out of the software-native industry-they don’t copy everything about how they make products. [laugh] they leave roles out, they don’t have the same processes in place, they don’t interface with the right cross-departmental teams, and things like this. Is there any meaningful distinction there, or is it like, that’s an unnecessary distinction in the world of data science and engineering from your perspective?
Jesse: No, it’s a completely valid point. In fact, I go so far as to say, “Is this your core competency?” Let’s start even there. If you’re, let’s say, a manufacturing company, and you have no software engineering pedigree, and you have no data science, and maybe you have rudimentary analytics, you need to ask yourself the question as management, is this our core competency? Should we be using some kind of consumer off-the-shelf product? Should we be even farming this out to a consultancy?
Those are very valid questions that I’ve seen the end result of the company not asking that question of themselves, and then coming out the other side of this really half-assed product, or not just product, but team, where we hodgepodge the team together to not 100 percent of what we need, but what that person thought that they’d need. They never really went anywhere relative to the spend. So, their ROI, pretty terrible, pretty in the weeds, not going to go anywhere. And what they didn’t do is they didn’t copy what companies with a good, solid, strong software engineering background do of, we have the right tools, and we do this, and we do that. And that sets us up with a solid foundation.
Brian: Cool. Well, thanks for coming and sharing all this. Where can people find the text? And do you have any closing thoughts for our listeners that you would like to share about your book?
Jesse: I guess one of the reasons I wanted to be on this podcast is I know you have this more product manager oriented focus. So, when I originally pitch this to you, that was what I wanted to really talk about, and think through. Where do product managers fit on this? Because you’re right, I don’t talk about it in the book. And I wanted companies who really want to know about this to have a resource that I can point them to and say, “Go listen to this product-podcast. Brian and I talk about it.”
Brian: ‘Prodcast?’
Jesse: [laugh].
Brian: I think you just came up with so-[laugh].
Jesse: Okay, well, I said it, so I’m copywriting it.
Brian: There’s something there. You, like, getting the domain right now.
Jesse: It’s my, it’s my copyright.
Brian: [laugh]. That’s awesome.
Jesse: The other thing I’d say, is the book’s website is datateams.io, and I recorded a series of videos on it; there’s about 40 minutes of videos that cover things that either I wanted to compliment the book with, or were easier in a video than with a book. So, I talk about that debugging teams in one of the videos. I talk about hiring: how do you actually hire? I’ve seen it for individuals where we say here are the buzzwords you need to put in your resume, but I haven’t seen anybody say, from a management point of view, what is this process of hiring look like?
Another one I talk about is setting goals. It’s probably something after your own heart, of maybe that’s what your product designer would have done-or your product manager would have done. But what I try to do, if you take just a few things out of this podcast, one is, you’d be laser-focused. You don’t go after ten things, you don’t go after twenty things, you go after one to three things.
And if you get that focus, then you can execute, but if you don’t have that focus, it’d be like some of the other teams that I’ve seen, where yeah, you can execute things at once, but the problem is that you’ve taken your resources, you don’t divide them evenly amongst twenty things; you divide them against twenty things with some overhead. So, now you execute twenty things, but it takes, now, five years because you’re executing so slowly, and you never get any velocity there. So, I encourage people to watch those videos, it’s up on datateams.io, and I’d have to say that’s the end of it. I really appreciate it, Brian. Thank you.
Brian: Yeah, Jesse. It’s been great coming on, and good luck with the continued launch of the text. And I’m sure there’ll be a good one coming out number four, right? That’ll be your-this is three right? Number three?
Jesse: This is number three.
Brian: All right. So, maybe we’ll have you back on number four and see where that goes.
Jesse: Excellent. Thank you again, Brian.
Brian: All right, cool. Cheers.
The job of many internally-facing data scientists in business settings is to discover,explore, interpret, and share data, turning it into actionable insight that can...
In Episode #003, I talked to Mark Madsen of Teradata on the common interests of analytics software architecture and product design. Mark spent most...
Joost Zeeuw is a data scientist and product owner at Pacmed, a data-driven healthcare and AI startup in Amsterdam that combines medical expertise and...
