Show Notes
What is the right way to have dev and ops work together? Is that different for data science? We look into ways these different specialities can be organised to foster collaboration. Development and operations has a lot of literature from the DevOps movement that gives us guidance for how to structure teams but data science has less written about it. Still, we have found some articles that shed light on things, and those articles appear to be based on reality, which we discover as we talk about our experience of working with data science and operations.
Opening quote from ”The Uncanny Valley of a Functional Organization” by Ben Thompson.
References
- The Emerging Role of Data Scientists on Software Development Teams
- DevOps Team Structures: Characterization and Implications
- Adopting Continuous Delivery and Deployment: Impacts on Team Structures, Collaboration and Responsibilities
- Considering three software development team archetypes and their implications.
Transcript
Andy: Collaboration is one of those buzzwords that will get you wasted in a drinking game. It’s on the lips of every innovation consultant thought leader and CEO. The concept working together to make something great. Seems straightforward, but the fact it’s always the proposed cure is evidence enough. It’s hard to achieve.
Welcome to another episode of the TTL podcast. On this episode, Mon-Chaio and I actually have a request from a listener. It’s a new experience for us and we’re gonna give it our best shot. And this listener is actually someone I know in person. He was listening to the podcast. He said he’s really enjoying it.
He found it an excellent thing to fall asleep to while going somewhere on an
airplane, which I actually take. I don’t know if Mon-Chaio, if you do, I take it as a great compliment that we are soothing enough that he can listen to us and just drift to sleep and, and, and he’s happy. So I thought that was great.
andy_1_10-11-2023_202223: Yeah, maybe we can branch out into the sleep hygiene world,
Andy: All All right. But the question that we got, he knows the way that his team works and , he deals with the data science team that’s in an organization that has data science as well as software engineering. He knows how his team and how his company works and how they’re structured, but he was wondering what other options are there?
How do other teams organize, how do other teams organize around? Software engineering around data science, around testing, around qa uh, around operations. How, how do the different companies organize? And I think that’s a really interesting question ’cause it kind of gets to this fundamental thing of how do you as a manager, as a technical leader, think about your team working together and your team working with other teams.
Because maybe you are the software engineering lead and you need to work with data science. How should you organize your groups? And so starting from that as the basic idea. How do we organize? Let’s see where this takes us. So Mon-Chaio, let’s just kind of start out, what, what, when, when you hear that question, what comes into your mind?
Mon-Chaio: What comes into my mind is I feel like we talk a lot about how engineering teams organize and what we might call their primary counterpart product, how they, how we organize and interact and collaborate with them. So I feel like a lot of discussion has been had around that, and a lot has been written and maybe even podcasted.
I feel like a lot less has been discussed around what you were talking about, Andy, this concept of, well, what about the people that release the software? How do they organize? Are there different ways that we interact with them? What about the data science groups? What about stuff like bi.
engineers or data engineers, or what about the security group?
And I do think it’d be interesting to say, Hey, what have we seen in our career? Is there any literature that talks about maybe best practices? And perhaps what can we advise for our listeners about how they should think about interacting with these groups given the context that they themselves are working in?
Andy: Yeah, Yeah and I think context is key. In our discussion, we’ll probably be referencing a few different things. Most of these end up being about like how Dev interacts with ops, because DevOps was a really big thing, and so that got a lot of research. There’s some about how like dev talks works with data science or just how data science operates.
But do you think Mon-Chaio, that the lessons from one of these disciplines, like how those groups interact with other groups, apply to other disciplines, or is each, do we need to take each one separately?
Mon-Chaio: I certainly think there’s some frameworks that we can use to think about just general collaboration, which would cross disciplines. One, for example, might be handoffs. When should you think about handing stuff off versus when should you think about working more collaboratively?
What are the pros and cons and trade-offs to doing handoffs? I think that’s one thing. Another thing could be something around business value. How valuable is that particular discipline to your business in the particular context? You know, if you are, say Uber, perhaps security engineering is very, very important to you given the regulatory environment that you operate in or if you’re a bank or something.
But perhaps if you’re rover.com or you’re a dog walking service, something like that. Maybe security doesn’t play as big a role, and so your context is different. Right. But I do think that there are some central things like handoffs that possibly we could use to frame it across the disciplines instead of saying every discipline is unique.
Andy: Yeah. I agree with you. I think that there’s a lot of patterns that exist out there for how groups organize, and they, there’s nothing all that specific to the particular disciplines. The pattern you choose really comes down to how those disciplines need to interact for the context of that particular business.
I was gonna start going into one of those patterns right now, which is a very, very high level one, which has been talked about for a long time. And that’s in the, are you organizing yourselves functionally, or you are organizing yourselves, divisionally, the functional organization. Which doesn’t mean that the organization works.
You don’t have a functional organization versus a dysfunctional organization. Although that is another axis. It’s not what functional means in this case. Functional in this case means are you organized by essentially job function, job role, or are you organized by division? And for a lot of us in software, we would probably call this more product.
So are you organized around your product or are you organized around your function? a classic functionally organized company is a small software company. You, you generally have your software team, you have a testing team, you have a product team.
You have a marketing team, you maybe you have an operations team one IT person who would probably be called a DevOps. As much as I hate the use of the term for that, that is what they’re being called now. And, and what it is, is that the expectation is in a functional organization is that they, they, they’re in their functions and then they just kind of, they work it out among those functions to get the work done.
So the product person will have whatever they’re working on, and then they’ll go and work with the devs, and then the devs will, will work on their stuff and they’ll work with the operations group to figure out how to deploy it and the monitoring and all of that. But their, their reporting structures are still very much along their function.
A divisional organization is organized around their products. So the classic example of this is . Well ge, the, the behemoth of manufacturing, ge, which does so many things that most of us probably don’t know what they do. We know that they make washing machines and we know that they make airplane engines.
And so they’re not organized functionally. And you can imagine how terrible it would be for them to try to organize functionally if you had like the metal engineers or, or, or what is it, machinists, sorry, If, if the machinists that work on the washing machines were also the same group of machinists in the same reporting structure as the ones trying to build the jet engines, you’d be like, that just doesn’t seem right.
So a, a divisional organization is going to separate itself up into these different kind of product areas and work within those. So that’s one way of thinking about it. But of course, internal to a divisional, you, you could be functional.
Mon-Chaio: Mm-hmm.
Mm-hmm
Andy: at some point it might start turning back into that, but at that, at that high level, you kind of have to think what is your overall strategy for, you should say, dividing people up.
What is their way of reporting and getting that coaching and mentoring that that line management. Is it based on their role or is it based on their product?
Mon-Chaio: It is a pretty tricky business sometimes to even decide whether you’re divisional or functional, not just between your layers, but even within a specific layer. So I have an example, perhaps Andy, I, I will foist upon you, get your thoughts on it. At Meta, for example, if you think about, and I know we’re not talking about product and engineering because we want to talk about things like data science but let me use a well known example from product and engineering because everybody understands it. You might have a product person. Aligned with some engineering teams in a func, or sorry, in a divisional sense, they’re working on, say, developing water bottles or whatever, right? That’s their, that’s their job. Now, that product person has a lot of leeway in terms of figuring out all the AAA stuff with regard to building this water bottle.
Man, why did I use water bottle when I said specifically, this was a meta example. was never
Andy: maybe, maybe meta is getting into the exercise equipment space and I just wasn’t aware of it.
Mon-Chaio: I’ve never worked in newsfeed, so, but I’ll use newsfeed. So I don’t uh, you know, step on anybody’s toes here. This product person is working on newsfeed and they have a lot of AAA about which features are coming down the pike, all of that stuff, and they work
Closely with engineers. So you might say, well, that’s a very divisional organization. However, they still report up through product. So on the reporting chain structure, that’s a very product, that’s a very functional organization.
Andy: Mm-hmm.
Mon-Chaio: They get mentored through that reporting structure. So you would say that’s a functional organization.
And interestingly enough, that structure, they also get feedback around their divisional responsibilities. So it’s not just a, how can you become a better product manager? It’s also, let’s think about these types of features in your area and what we could do to massage and, oh, can we put another product manager on it in order to surge from a different area? So is that divisional? Is that functional? Is that both? Is there a different name for it? What do we think about that?
Andy: My way of thinking about it is that the test, now, of course, there’s mixtures allowed here. You can do some sort of mixture, some sort of hybrid. But to me, the test for are you functional or are you divisional is if you’re going to start a new product, what do you do unrelated to your other products?
You have this idea, I wanna start a new product. Is that a whole new group that needs to be created or is it just a kind of changing who’s interacting with whom?
Mon-Chaio: Hmm.
Andy: If, if it’s a whole new group needs to be created, you’re very much a divisional organization. Now you may pull those people from elsewhere, but you kind of have this idea, we have to create a new group. But if you say, actually no, like we’re gonna just pull a few people from this team and get that product manager working with them part-time, and then they’ll, they’ll get some help on their previous assignment as well to kind of backfill for that. Like, yeah, we’re gonna get those people interacting.
Then I would say you’re functional, you’re thinking about it from the standpoint of those those different specialties. And how to pull the resources together to, to do this new product versus saying, actually we need to whole create a whole new organization around this.
Mon-Chaio: Interesting. I was about to ask whether you think there’s a difference between . Explore products, new explore products versus new extract products to use our explore, expand, extract. But I don’t think that’s as interesting. I think there is a difference there. But I think the last thing that you mentioned there really resonates with me, which is what is your default in your mind about resourcing something new?
Andy: Yeah. Yeah So I’ve, I’ve, I’ve worked on groups where their default was, they said, if you want to try out a new product, the first thing you need to do is hire a product manager, hire five engineers and one tester.
Mon-Chaio: Hmm. Very divisional, right?
Andy: Very divisional thinking, very, a very divisional way of thinking about it. But that, that same organization shifted to saying, actually, if we want to try a new product, what we’re saying is we wanna put a little less effort into that product and a little more into this experiment. And so we’re just gonna move some people around.
Mon-Chaio: Interesting. A lot to think about there. I’m thinking about my experiences at Uber and Meta and other places and trying to, and, and I see it both ways. I, I, I’m trying to figure out whether those companies would call themselves functional or divisional if they had to choose one. Obviously there’s always a mix, but maybe we could start to get into the meat of it.
I do think divisional and functional is a great way and framework to start to think about these collaborative organizations. So which one do we think we want to start with? So we have engineering. Maybe we could start with how engineering interacts with ops, perhaps maybe that’s a good place to start.
Andy: I think that’s a good place
Mon-Chaio: our software,
Andy: Yeah, it’s a good place to start because there’s a lot more written about it, but it’s also a good place to start because as you just said, the software has to be released somehow and operations is generally the way you get it released.
Mon-Chaio: Mm-hmm.
Mm-hmm.
Andy: That said when I worked at Puppet, we didn’t really have ops.
Which was interesting, being a a, a classic DevOps company, we didn’t really have operations . What we had instead was release management because we packaged up software and shipped it out. But it was a very similar kind of idea though, which is how do you interact with this other group that has a different specialty about how you get your software out into the world.
Mon-Chaio: Mm-hmm.
Mm-hmm
Andy: Okay. So I actually did some research for this show. We, we say that we’re, we’re, we’re based in scientific research and we try to make that true.
We don’t always have papers. This time. I have papers and this was a paper from a Grounded Theory research, which I could geek out right now and go into what grounded theory is, but I will stay away from it other than to say it is a qualitative research method that tries to produce theories. It’s not trying to test a theory, it’s trying to produce a theory.
They had interviews with various people and from that they tried to come up with kind of what are the structures that Dev and ops interact. And I think we can use this as a way of thinking about, well, how can other teams interact as well? And they came up with four ways that dev and ops seems to be structured.
The one that I think a lot of us think of the most is one of theirs, but actually it was the least common in, in their research. And that was that there’s no visible ops team. Everyone just takes it on and it’s, you build it, you run it. There’s no ops team. They, they just all are independent in running their stuff.
They only found that in 17% of the groups that they talked to. Tied with that though. Is another structure that they found also in 17% which is that you create separate dev and ops teams, but then you have some other people who act as facilitators who kind of bridge those teams and try to bring them together.
And you can think, well, why would you wanna do that? Well, you might want to keep them separate. If you are in, for instance, as Mon-Chaio noted before Uber or, or a bank, a highly regulated environment where there’s a lot of controls about who can have access to what. And so you, you might find yourself still needing to have a separate team in order to be able to show the proper control over the flow of information or access.
Same kind of thing could happen with data science. If data science team has access to particular kinds of data that no one else should see, well, they might have to stay fairly separate from the rest of your group. So that, that’s, the second pattern that they found. Another pattern was a small ops team and a dev team that was kind of slowly taking more responsibility.
You could kind of see this as a, a coaching step, possibly a coaching step towards that first one that I mentioned where there’s no more ops team visible anymore. And in this case that small ops team acts as coaches for the development teams as they learn how to do things. And this could be not only a stepping stone, but it could be your final state as well, if your operational environment is very complicated.
Which it’s not really possible for everyone to know it intimately. And so you need that small group of actual complete experts to go and help people out sometimes. And so they can support a bunch of teams to do that. And then the, the last one, and this is the one that they found most often. In fact, 35% of their respondents had this as in some form in their description, which is separate teams, but just culturally, dynamically, they interacted a lot.
They didn’t need that facilitator. They could be very fluid amongst each other. They interacted a lot back and forth. And I would also say Mon-Chaio, when we worked together it was long before DevOps, but that’s how we interacted with our operations team. I remember lots back and forth and lots of like pairing on, on issues and trying to understand things and sitting down and looking at cacti graphs,
Mon-Chaio: Uhhuh
Andy: That kind of stuff.
And so that, that’s, that’s kind of the four interactions that they found, which is two separate teams interacting just very highly collaborative ways. Small team coaching, the other teams separate teams with a facilitator role in between. And just one team. There is no separation.
Mon-Chaio: I think that sounds all very familiar to me. There’s obviously some nuance here. In my experience, I’ve definitely seen that number one, that 35% respondents the separate dev and ops team with high collaboration. I think I would note that high collaboration doesn’t mean successful collaboration. It just means high.
It just means they speak. When I was at Microsoft back in 2010, I was in the ads organization and the way we released software there, there was definitely a dev team and an ops team. And the ops team was responsible for releasing software. Again, a highly regulated environment, perhaps. Definitely subject to Sarbanes-Oxley SOX compliance, which small tangent here, go read SOX instead of just listening to the consultants.
Because what the consultants tell you you need to do is not what it says in the SOX documentation.
Andy: That’s true for almost any of these frameworks. The, the things that people believe that you have to do. Like actually DevOps quite often deals with the ITIL stuff.
Mon-Chaio: mm, mm-hmm.
Andy: ITIL does not require all sorts of insane processes
Mon-Chaio: or HIPAA
Another one, right, where people will search out HIPAA compliant tools where yes, HIPAA is a little bit vague and a little bit difficult to grok, but you don’t need a HIPAA compliant tool that’s not like this amazing thing that somebody is able to do through compliance checks and original programming or whatnot.
But back to back to the separate dev and ops teams at Microsoft, there was people who released software and they had the keys to production systems. The engineers did not have passwords or anything to get into production systems. Well, we, to them were packages, zip files or whatnot, de deployable packages that then they would deploy, and we wrote deployment steps for them. In a deployment doc, at one point we tried to automate our deployment strategy by giving them a script instead of a deployment doc. And they really did not like that because they were afraid of what the script might do. Whereas when they deployed, they would check 800 things between every step or whatnot in order to make sure things were going well.
So there’s an example of separate dev and ops teams with high collaboration. I wouldn’t say successful collaboration.
Andy: I would say that a way to make collaboration between those kinds of groups much more successful is to automate it. And this is, this is why DevOps often seems to get confused with tooling,
Mon-Chaio: Mm-hmm.
Mm-hmm
Andy: automation of some of these processes is a way of easing those collaborations.
So for instance, in a release, if you have standards about the release contract, what it means for a service to be running, what it means to shut it down what a rollout looks like, then your deployment shouldn’t be a big, complicated special case affair where they’re having to look at everything or where the dev team is giving the ops team some mystery script that they don’t trust because they’re like, wait, what are you about to do on my server? If instead they come up with, this is the contract, this is the way we do deployments, and if you need a new deployment mechanism because it’s not working for you, let’s talk about that. That, that kind of automation and that kind of offering it as a product. Quite often you’ll see that kind of separation where the operations team, when they’re really successful, will think about what they’re offering as a product.
Their, their internal customers are the development teams that want to run and deploy software. And so they think about what’s the product we offer? And you could say, this is why cloud systems actually became such a big thing. Well, one of the reasons, there are many reasons, but one reason is because they gave that standardized, this is how you deploy.
Mon-Chaio: Mm-hmm. Mm-hmm and that actually leads well into the second example, which I actually think is probably closer to the no visible ops team example. But maybe I’m wrong because it also has flavors of what you were talking about. And this example is there is a team that wouldn’t call themselves ops, but what they do is they create, I, I would say they generally call themselves at companies dev experience teams.
So parts of that organization might create, you know, IDE extensions, parts of that organization might create platforms of some sort, maybe a data storage platform or some sort of graph platform, graph storage platform, that sort of a thing. But also within that organization is somebody that creates a deployment platform, which often includes things like CI tools and other things like that. The interesting thing is about those teams, I rarely hear themselves call themselves ops. And they also don’t worry about what I would consider some of the traditional things that ops worries about. Hey, are the services operating correctly? Is the site up? They see it themselves as more of a macro sense, right?
Like, are we able to deploy at all?
Andy: Yeah.
Mon-Chaio: And as long as we’re able to deploy at all, and as long as CI is running at all, everything else is the dev team’s responsibility. I have given them the tools. I’m not sure if that’s closer to the separate dev and ops team model or whether that’s closer to the no visible ops team model, or is it something that’s missing and different from what the survey found out?
Andy: I think, I think that one is closer to the small ops team with dev teams taking more responsibility. I’ve seen, I’ve seen that as in my experience, they get called a platform team.
Mon-Chaio: Mm-hmm.
Andy: they’re building up the infrastructure platform that everyone’s gonna be working on. So they’ll they’ll create Terraform modules and they’ll be like, this is the standard.
You could do something else. But you’re gonna be on your own if, if a team is having issues and they’re like, I can’t get I can’t get my Lambdas to deploy, I can’t understand what’s going wrong, Terraform is failing with this message, they’ll step in and they’ll help out and they’ll say, okay, let’s understand what’s happening here.
Mon-Chaio: Mm-hmm.
Mm-hmm.
Andy: I would consider them more along that line, that kind of, that kind of i, there they’re not quite taking control or they’re really not taking control.
They’re giving all of the tools and they’re giving their expertise, but they’re not controlling the deployment anymore.
Mon-Chaio: That That makes a lot of sense. Okay. I could get behind that. I think it’s interesting, these the survey that found out these four different models, I feel like now that we’ve talked through it, through our experiences, feels fairly complete.
Andy: Yeah. A client that I’m working with they have no visible ops team.
Mon-Chaio: mm-hmm.
Mm-hmm.
Andy: This is the first time I’ve actually encountered this. So I can believe that it’s 17% of respondents had it. It’s not as common as the other things. And the way they work is each group comes up with how they’re going to deploy, how they’re going to monitor.
There is some expectation from the group that you’re gonna be in Google Cloud in this case, but there’s, there’s no ops team visible anywhere.
Mon-Chaio: Mm-hmm.
Andy: is someone called the infrastructure champion. and that person is not even necessarily the most expert in the company in it. It’s just that they are going to be the one kind of thinking about it, bringing it up in meetings, bringing it up in planning.
If you do have a problem, they would be the first one you’d go to and they might be able to point you in the right direction. So they kind of act as a bit of support internally, but they would not be called that kind of small ops team.
Mon-Chaio: So what do we think? Do we feel like we’ve talked through some examples, we have some, a little bit of a framework of these four separate ways that Ops and Dev can organize. What do we think about tactics? Should ops teams be more functional? Should they be more divisional? Is there one of these four that we would recommend, or are there frameworks that we can say, based on your context, you should pick one of these four given specific aspects of your company?
Andy: I, I would go back to actually something that you mentioned before, the functional in divisional the handoffs.
Mon-Chaio: Mm-hmm.
Andy: Think about the handoffs that are going to have to happen in your organization as these two different specialties need to work together and think about how critical a separation is. So, as we mentioned, if you’re in a compliance in a very compliance driven environment, that that separation may be critical for being able to evidence that you’re in compliance.
But if you don’t have that kind of thing or if you can come up with another way of evidencing it without the separation, without the handoff, in many cases, you’ll be better off if you can get away without a handoff. And I think the other one is to think about then, when you do still have a handoff in that interaction how much of that can you standardize? How can you make it so that that interaction is not ad hoc all the time like you were describing at the Microsoft, about doing a deployment Because that will make that interaction much more able to be anticipated by both sides.
Mon-Chaio: I like that. I think that makes a lot of sense to me. I will add a couple more things on this topic. One, I do think that if you had to pick one, an ops team tends, I think, to fit more towards the functional model
Andy: Yes.
Mon-Chaio: simply because it’s rare that a company will have different deployment methodology needs for different products within their organization. It it, it’s just simply rare that a company will say, oh, well I have to deploy a shipped burned piece of software on a cd. I mean, you use a CDs anymore. What is it? A binary that you post to a website.
Andy: AOL must send out CDs still,
i, yes, we should try to find an a o l cd. I wonder what’s on it,
I, I actually don’t remember what’s on
Mon-Chaio: Mail or something? But it’s rare that you’ll say, Hey, I have to ship some piece of, of binary software, and then I also deploy to the cloud. And then I also have, I don’t know, shared services or, or, or whatever that does custom development and deployment to customer sites. I, I just don’t think that, like there are many companies where their deployment methodologies are so different across, across their different products.
And so I think it does fit well within the functional model. I think that the expertise that lies With an ops person generally these days, I think probably should be closer to that of the platform engineers that we talked about. So for most companies, I would absolutely advocate whether you’re deploy into the cloud or on-prem, to have a group of ops engineers that focus more on the larger sense tooling around deployment of software. I’d mentioned things like ci and you had mentioned things like Terraform and whatnot, right?
Andy: Yeah.
Mon-Chaio: The other stuff, I don’t think that’s expertise that should be removed from engineering, so as much as possible. And also to reduce handoffs, you should put that into engineering as much as you can. The last thing I’ll mention around this is touching back on what I said about things like socks and hipaa, even in those highly regulated environments. You should really try to put deployment in engineering’s hands. It means you do need more tooling and more guardrails in the platform itself. But I think putting guardrails in individual teams hands or in individual people’s hands is not the right way to go, even in those environments.
Andy: Right, Mancho. So let’s move on from DevOps or dev and ops to data science. How does it change for data science? And for that, I found another paper.
Mon-Chaio: Yes.
Andy: I found another paper talking about models of how data science is organized. And in that it’s, it’s a much smaller research set that they used. It was only 16 interviews, but what I thought was fascinating is across 16 interviews, they found five different models for how data science was organized.
Mon-Chaio: Oh my goodness.
Andy: So it kind of tells us there, there might be a bit more going on here as people figure it out. But I have also seen a few of these models myself. So one of those models was the triangle model they called it, and that’s where a team of data scientists, data engineers, and what they call data collectors or I called it data collectors because they had this long, long-winded explanation of people who go out and find the data where they work as kind of a small group, a small hit team, could say.
Then they had the hub and spoke model, and that’s where they have a central team that collects data. So you could say that they’re probably doing data warehousing. They’re creating point in time data stores of history of events or things. And then these spokes are teams that builds product specific models.
And on that one, it already starts giving me a picture of how might data science interact with other groups is, well, one option is maybe, maybe you have this kind of like central data. And then the data science itself is done off in other product groups. And then they had what they called the consulting model.
This one is starting to sound a little bit like the DevOps one with the small ops team that consults to the dev teams. And in this one they had a team of data scientists, consults with internal and external teams to produce custom models and solve data problems. So they have some amount of expertise and they will go to where the problem lies.
And then they had the individual contributor. So there is some larger team. Depending on the company, it could be a, so a software team, it could be a marketing team, it could be something else. But the data scientist is an individual contributor, just embedded in that team. And then they had the virtual team, which is basically there’s a whole bunch of individual contributors and they come together into a virtual team, a team across all of those others that shares their knowledge, shares their tooling, and tries to get things going.
That one, going back to the divisional versus functional, that one sounds very much like a functional way of thinking about it. Whereas, for instance, the hub and spoke is very much a divisional way of thinking about it.
Mon-Chaio: And in the individual contributor one, I don’t think they’re saying it’s a single engineer embedded with a dev team. Right. It might be many . Data scientists, sorry. It’s not a single data scientist embedded in a engineering team. It might be many data scientists forming a small team, but that small team is embedded within the engineering organization or the development organization.
Would you read that the same way, or would you say that that’s different?
Andy: I, I think, I think that it’s actually the people are embedded on the other team. So they, there, there is no, you would say there’s no data science team, there are simply data scientists.
Mon-Chaio: Mm-hmm.
Andy: but you do bring up another one, which would be, you simply have a data science team. I think that would fit the triangle team.
’cause generally when I’ve worked with a data science team, it, it really looked like what they described as the data is the triangle team. I, I was the lead on a team of data scientists data engineers, and then various other people to support it for quality and data correction and that kind of thing.
Mon-Chaio: Mm-hmm. and the triangle. There would, the triangle would be a divisional model where every product would have its own triangle team.
Andy: In this, in the case that I was in, they were trying to do kind of a divisional, but kind of a functional model. We were supposed to be autonomous, controlling our own kind of component and a bit of our own product, but they realized that in order to build any products it needed, Some information from the team that I was on, some information from another team, some UI capabilities from a third team.
And so the idea was okay, this is the architecture and so we are going to have you all responsible for your area, and then you’ll work out how to interact and send the data around and implement the behavior.
Mon-Chaio: Well, Well and I think that makes a lot of sense that data science tends to be more tied toward the architecture because they have to go get data, right? And data is collected by software systems that are already built. So that, that makes sense in my mind as well.
Andy: Or sometimes data’s collected by hundreds of humans.
Mon-Chaio: Sure have, have you seen that data that’s collected by hundreds of humans?
Andy: Oh, yeah. Oh yeah. That’s, that’s . Well actually that’s where a place that we worked together one time. It was healthcare data collected by hundreds of humans around the globe. And this place as well that, that I’m thinking of. It was also lots of data. A lot of the data that they had was collected by humans as they read as they read company webpages to understand what companies exist or as they read investment documents to understand like what bonds were just issued and what were the terms on it.
Mon-Chaio: it’s funny, I, the healthcare one, I wouldn’t have considered those people to be part of a data team or data science team, but perhaps I should change my thinking on that.
Andy: They, they entered all the data that, all of that, that the company sold
Mon-Chaio: They, they did. They did. Okay, so that’s, so 16 interviews, five different models. What do we have to say about that? You’ve mentioned some of your experience working, you’ve worked in a triangle model before.
think you said you’ve worked in an IC model before, or you’ve worked at companies with a IC model.
Andy: I’ve worked in, I’ve worked in the triangle model. I’ve, I’ve worked with the IC model as well. That one was that one was one where also another mode of that company operating was more of the consulting model
Mon-Chaio: Mm-hmm.
Mm-hmm
Andy: also at times the hub and spoke model.
Mon-Chaio: Mm-hmm.
Andy: So that’s, I think another thing to take away from this is you can allow your structure to morph and shape as your needs change.
So, for instance, that company that where we had all those different models kind of playing out, the individual contributor model was used for what we called the commando team. That was, we wanna go off and explore a problem. So we took a principal engineer and we took a data scientist and we said, Hey guys, go off and look into this.
The data scientists needed the support of the developer to get the data to get it manipulated into a fashion that was more readily usable for the data science and to investigate why certain things were showing up in there, which might involve going into the code and understanding like, okay, what has the system done to produce that kind of a pattern in this data?
Then the consulting was also used there. There was one time in this company it was all financial data that there was a lot of investigation into changing from one data set to another one vendor data to another.
And so there was investigation into what kind of impact that would have on the product that we produced. And since that was kind of a data question, a data sciencey question, they got consulting help from the data science team, which was actually quite useful because it trained a bunch of the engineers on some of these techniques.
And so from that point on, as, as that continued like the, it became a fairly normal thing for the engineering team to open up Jupyter Notebooks and start like pulling in data and analyzing it in different ways and looking at it, we never did anything complicated. It would be like do a scatterplot or maybe pull up a co a correlation coefficient of something.
But it was enough that we got better at basics of data science and the data science team didn’t need to be pulled in all the time. And then the hub and spoke I think came about with, well, the engineering team spent a huge amount of its time pulling all of the data together.
And then that data was used by the data science team on all of these different projects that they would work on sometimes with sales or marketing, sometimes with product engineering. Sometimes with just some like the CEO’s interest in a question or something like that. And so we would, we would
Pull all of that together. And so it was this very fluid model in how we would work and the kind of exact structure would change depending on the situation of the company and the team at the time.
Mon-Chaio: I love hearing all of those experiences because I think it does contrast in my mind with the development and ops that we had talked about earlier. For the tactics for that, at least for me, I gave some tactics where I said, listen, there’s kind of a very specific way you should think about focusing regardless of whether you’re regulated or not.
Regardless of whether you deploy into the cloud or on-prem, there’s some good practices around handoffs. There’s some good practices around what I mentioned was having a platform team and then moving as much as possible into eng. I’m not sure I believe that for data science, I think data science spans a much larger scope of what you wanna do with that data.
You can use that data for internal company bi. The models could be a central part of the product because they, you know, are behavior models that determine how you do recommendations. They could be used for figuring out which parts of the code are taking up more CPU or memory, right? You can model in that.
So I think data can be used in so many different ways. I don’t think there’s a one size fits all model that I would say like I recommend it for development and operations. Maybe I’m hearing that from your side too, Andy.
Andy: I think that’s a good insight. I, I hadn’t thought of it that way before, but you’re right. The data science, the data science role, you can say, is to be inquisitive, to take interesting questions and to find ways of answering those questions. Which means if you, if you kind of think of it that way, it makes sense that it’ll be very dynamic and there’ll be different ways that you’ll need to do it at different times because, well, the questions can pop up anywhere and kind of need support from all sorts of different data.
So you, you’re gonna find yourself having to kind of move around a lot.
We, we’ve been talking very much with an engineering centric view. We’re both engineers. That’s our background. So we unfortunately have that bias, but I’m going to acknowledge that bias right now and say if your organization is not software focused, your central function may be something else. It may be operations, or it may be data science, in which case the engineers are the ones kind of off on the edges.
Mon-Chaio: Mm-hmm. Ugh. That could be a whole nother episode. This concept that maybe some engineering teams, many, maybe many engineering teams need to not be engineering teams,
Andy: Mm,
Mon-Chaio: and that their businesses would be a whole lot better if engineering were more towards the edges. But I think we’re out of time. We didn’t even touch on testing
Andy: no
Mon-Chaio: or security compliance, or design, which I know a lot of people have questions about too.
So if that’s something that you all want us to talk more about definitely drop us a line. Let us know what you think hosts@thettlpodcast.com or any other feedback you have, even if that feedback is, please have made this episode two hours so that we could talk about that. I don’t think we’re gonna get any emails about that though, Andy.
So we hoped you’d enjoyed this, our first listener sponsored, if you will, episode If you are also a listener and have have something you would like us to cover, drop us a line Also, again, hosts@thettlpodcast.com. Until next time, be kind and stay curious.
Leave a Reply