Data Science Hangout | Alan Schussman, W. L. Gore & Associates | Data science is not one thing

Hi, everybody, welcome back to the Data Science Hangout. If you're joining us for the very first time today, this is an open space for the whole data science community to connect and chat about data science leadership, questions you're facing and getting to learn about what's going on in the world of data science at different companies across different industries. And these sessions are recorded, and they are shared to the Posit YouTube, which is the first time I'm referring to something as, as Posit, which is exciting too. So you can always go back and rewatch or find helpful resources there as well.

Together, we're all dedicated to creating a welcoming environment for everyone. And we love when everybody can participate. And we can hear from everyone, no matter your level of experience or area of work. So there's always three ways that you can ask questions today. And also provide your perspective, it doesn't just have to be questions, you can jump in by raising your hand on zoom, you could put questions into the zoom chat. And feel free to just put a little star there if you want me to read it out loud instead. And then we also have our Slido link where you can ask questions anonymously to if you prefer to ask there.

But yes, going back to going back to the normal spiel. We do also have a LinkedIn group for the hangout. So if it helps you connect with people or you want to continue a discussion, you can do so there as well. And our team will share that in the chat in just a second. But for today, I'm so excited to be joined by my co host and our friend from the hangout here. Alan Schussman. Alan is data science and engineering team leader at WL Gore and associates. And Alan, I know you've been here with us quite a few weeks, but I'd love to have you introduce yourself and share a little bit about your role and maybe something you like to do outside of work too.

Sure. Yeah. So I'm sure we'll get into like lots of details about the role. So I won't like deep dive into that quite yet. But yeah, I work for WL Gore and associates. Gore is the company that folks probably know from Gore-Tex. In Flagstaff, we in Arizona, Gore, researches and designs and manufactures medical devices, primarily endovascularly implanted devices for a variety of cardiovascular diseases. And I work, I have landed for the last handful of years in this role as a debut team leader. Lots of trajectory of change of that team in the role over the last handful of years. I've been in Flagstaff about 17 years now. Prior to coming to Gore, I did a PhD in sociology, and then thought about, okay, what now what do I want to do with my life? And so so here I am.

Yeah, you know, our it's so dry here. Every time I walk the dog in the woods a lot. I like to take pictures. I a whole bunch of my hobby time is, is our coding in the service of doing things that are sometimes useful with the destiny to API. That's a lot of my my hobby time is video game plus data. And yeah, that's fun.

About the team at WL Gore

Cool. Well, I know you have a little bit of a different title and some of the leaders we've had on before and you manage both data science and engineering teams. And I was just curious to learn a little bit about that experience and kind of what your team looks like to.

Yeah, sure. So my team, the work that my team primarily does is data engineering. We are part of and I guess this is, you know, sort of primer on the on the team in general. In the past year and a half, we've switched from being a sales and marketing oriented analytics team to being a divisionally facing team. And so in that time, we've taken on a ton of the the broad team of which we're a part has grown tremendously, and my team has grown a bunch. I think the way to understand my team is that my team is like pragmatic data engineering along a very broad continuum. So there's some there is some of what I think we would think of as data science in in that work, insofar as we're asked to do some things around segmentation and do some some modeling. But a lot of those things are for us, kind of applications and methodologies that are waiting for the right business cases to really put them to use.

And so we are really heavily focused on getting data to a broad team of analysts who need to do all kinds of different things with it. And we have both brought up and also sort of inherited as teams have come to us a really broad set of applications to do that with of platforms and technologies. And so we are both. So when I say we're, you know, this is pragmatic data engineering, we are solving problems as fast as we can, we're gaining credibility as we do that. As we do that, the team gets to grow. And we get to think about where do we want to strategically go? How do we want to be strategic about our platforms and things, while still being really, really heavily focused on getting data stuff done for our really, really diverse set of customers and constituents.

And so the folks on my team are, some of them have formal data science training in terms of accreditations and and degrees. There's a mix of folks who come from different kinds of software engineering backgrounds, and see who else is on the team. And folks who come from from more business facing sort of sort of backgrounds, who came into analytics by virtue of kind of being analysts and developing in really technical directions. So it's a really broad team. And we're all focused on different kinds of, of applications and solutions of making data available, sometimes through a bunch of really complex mechanics, for our set of end users, who again, are, are going to do all kinds of different things with it.

And so we're sort of at the crux of this operation of, of data problem solving. And it's really exciting. And as I said, as we're, as we're growing, we're getting some opportunity that we haven't had in the past, to try to be more strategic about how do we want to grow? What kinds of tools do we want to use? How will we use them? What kinds of processes will we have those kinds of things. So it's, it's, you know, we're kind of racing to, to, to do good stuff for the business. And also, for me, I really want to sort of do well by the folks on my team and give them, give them paths that let them grow in ways that they're, that they're interested in growing.

Absolutely. And when you say end users, across the company, who, who is that? Or who are the different teams that you work with?

So, um, we have kind of a couple of maybe concentric rings. We have our broad NPD analytics team is a team now of about 50 or so, my team is about seven. And the rest of those 50 people are analysts and others who are affiliated with, we kind of have have dotted functional lines to different kinds of functions within the organization. So they're connected to sales and marketing, they're connected to supply chain and manufacturing, they're connected to quality and regulatory. And they're largely they're largely analysts who are who have responsibilities to their teams to produce analyses of different kinds, monitoring data, strategic planning information, those kinds of things. And so my team helps to, you know, feed capabilities to them, and then also work as project partners with them on the various things that that they need to do.

Background and journey into the role

Yeah, I was wondering if you had any engineering or IT background before you came into this, or if you just kind of like grew into that at Gore, because I know sociology has quantitative elements to it, right? So I'm sure you already had some of that stuff. What was your kind of journey into the engineering side?

Yeah, I guess there's a story there. You're absolutely right. I mean, the social background was the thing that I pursued that I presented as a way to say, hey, I could do, I could be not an academic, and not an academic could look like a bunch of the following things. I could work with data, I could do stats, I could do some, you know, programming of different kinds, I could do research. So my entry into Gore was kind of pitching myself to the clinical research team. And that's where I started in Gore as a data, clinical data manager. So I was doing, you know, data, data collection design for clinical studies, essentially, and then monitoring of data as it came in and those kinds of things.

My my jump from from there at Gore was into an IT role where so I sort of translated those kinds of things into saying, hey, I could fill a new commitment here that has to do with strategic planning of it stuff for the for the clinical team. That role, and that was a business partner role. And and that role gradually expanded to doing it strategy things for our whole division, which gave me lots of exposure to different businesses, as well as the different kinds of businesses and functions, as well as the different kinds of technical needs that that they had.

So, I mean, you know that, and then, at some point, I said, Hey, I sort of been ready to do something new. And an opportunity came along to join this then very, very small analytics team that was trying to figure things out. And, and I, and I jumped on it. But so no, like, that's the really, really long answer to your question of like, like, no, I'm not, I'm not trained as a software engineer, or as, I don't know, probably any of the things I do day to day. But there's a sort of through line from, from the stuff I've done along the way that has has helped me kind of figure it out as I go, I guess enough to enough to be okay at it, and to be successful at it sometimes. If there's any through line, I think there's a lot of enthusiasm for, you know, working with these technical tools that I get rewarded by finding success in and gradually getting better enough at those that I can can do more complex things, I guess. And now as a leader, I think that's a whole new space of learning for me is how to, you know, what does successful leadership look like?

Team backgrounds and hiring philosophy

So people are interested in I think there's there's a range there. So one of the folks on the team has done a data science master's degree. And I think that that's the most, that's sort of the, I don't know, kind of top end of formal training. Lots of other folks have done some course, some coursework, some amount of kind of independent, independent training of different kinds of things. And then, you know, more generally, folks have, we have we have a great we have a great mix. I have a mechanical engineer on my team. I have, you know, folks who do physical engineering, and that's really cool.

Yeah. And I kind of reflecting on that a little bit. When I came into this role, we had a definition for this data engineer role, that was that really emphasized the technical the technical kind of accreditation. I have really intentionally cast a broad a broader net than I think we've started with, based on the idea that I think people can be successful, coming from a bunch of places. And we really depend on a deep understanding of our businesses and our functions, for example. And I believe that lots and lots of people can learn that the technical pieces, but you know, there's a business aptitude, there's a there's a sophistication around how people interact and solve problems, that I think has has been a really, really important part of building my team. And I think I can see that as part of our, our broader success. You know, that accreditation is one thing, and it demonstrates a particular kind of capability that's important. But for me, at least, I really don't want it to be the only one.

And I believe that lots and lots of people can learn that the technical pieces, but you know, there's a business aptitude, there's a there's a sophistication around how people interact and solve problems, that I think has has been a really, really important part of building my team.

Developing the team and leadership growth

Alan, I know you mentioned this briefly in the beginning, but like, one of your the parts of your role that you really enjoy is like helping develop your team and helping them be successful. And I'd love to chat a little bit about that in here. Like what you're learning in this role, or what has has been most helpful?

Yeah, so I guess as framework, I can say, Gore as a company takes that kind of development really seriously. And so we have some formal processes that try to structure our approach to it. So I have some help, organizationally, in the fact that there's always a little bit of a, of a reminder that, hey, we're, we're coming through our cycle of doing development planning with our teams and making sure that we're that we're thinking about it and talking about it. So the formal element has to do with trying to do good planning with people about what are they interested in? And where do they want to go? And having realistic conversations about, okay, you know, are the things you're interested in things that we need right now? If so, great, let's, let's connect you to those and make sure that your skills are developing in a way that feels rewarding.

So for me, I think that one of the things that I'm, I think, learning that I have to figure out how to do well, especially as the team grows, is how to balance having like a vision for where we want to go technically, and also letting my team develop that and run with it. You know, a year and a half ago, we were a team of three, and all three of us could be really deep in just about everything we did. And so the one of the big pivots for me is going, okay, now we're working with five or six different functions, we have a lot more work than I can technically lead anymore. My role is different than it than it was a year and a half ago. And I can still be really invested in that, like technical solutions, and the writing code that is really rewarding for me. But the future direction of the team, I've got to let them own.

And so figuring out how to do that, that's one of the things for my development this year, that's really important for me is figuring out how to have a vision, get buying for the vision, and then and then let them run with it and really be successful with it. Because my success is they're doing good work that is really rewarding. And that, you know, ultimately, we have to get our business needs done. But but success for us as a team, I think, will feel really, really great when when they feel like their skills are developing, and they're doing things that are meaningful to them in ways that they want to work.

What makes a strong candidate

Yeah, it's a great question. I guess I have to give some caveat that that you know, those skills I do think are important. I just don't think that they're the only sort of thing that that gets you in that can get you in the door. So for example, you know, working as we have people who are who are successful on our on our broad team, who come from the analyst backgrounds of all different kinds, and from tools backgrounds of all different kinds, and they can be successful there. And I think that that applies to to a team like mine as well. I do think that there's a, you know, there's a, a, an element of being competitive for these kinds of roles that really is rooted in some some core kind of technical foundations. But for example, like, you know, I'm trying to think of a good example, you can be really technical, but not a good problem solver. And we really need people who can be who can be who can learn the technical things, but can come in with a perspective on like, what does solving problems well look like?

And I guess I'm thinking of, you know, you can you can be, you can be really technical, but inflexible, I'll say, in how you solve problems. And that's a really, really hard way to be successful. Because you can't, there's a whole lot of what we do in our work that has to do with, you know, we're satisficing, we're getting to a good enough solution that folks can do work with, that we know we want to improve later. And a lot of, I think a lot of technical work, a lot of technical training is sometimes a little too black and white for being able to to compromise about, this is good data, and my customers can work with it. And I'll come back and I'll help improve it for the for the next cycle. You've got to be able to compromise, I think you've got to be able to talk well through problems. And I think you've got to be able to feel embedded with your customers, so that you're a partner to them and not a not just a technical service.

Data science is not one thing

I do. Yeah, I think I do look around, you know, I've had conversations with folks doing like data science certificates of different kinds. And I do, this probably ranges a little bit, kind of kind of around around with your comment a little bit heavier. But I think we, I don't always know if we if we do a service to people the way we set them up for what we as an industry data science tends to tends to look like. I know my team is unique in the way that we're positioned within our organization, right? There's a whole bunch of our founding conditions that describe how we how we get to where we are, right. But and so I know there are lots of teams that do look like that sort of sort of archetypical data science org. But I don't know if it's, I don't know if it's the right expectation for people going through data science training, to have their eyes on, you know, the the like machine learning engineer kind of kind of career, for example.

You know, there aren't there aren't a ton of them. The applications are pretty specific. We're a pretty sophisticated business. And we're trying to figure out what some of those things mean to us and how to effectively use them. And don't get me wrong, I'm really excited for my team to be where we develop that expertise. But without the without the business need, it's not fair for me to tell people like, come join my team and be a data scientist the way that the way that sort of the world says data science looks. It's going to be technical, it's going to be interesting, it's going to be rewarding, but it's different from from that other picture. And so I think we have to be realistic. And I don't think there's any reason we can't make people really excited about that kind of work. It's really cool work. It's really complex. The problems to solve are really fun. The platforms we get to work with are really cool. It just but it looks a little different. So I think we have to be realistic.

And I think I think this expansive view of and, and I'm kind of going on and on. But so as a job code, the folks on my team are data scientists. That's the way that's what people we call them in PeopleSoft. And I think that's the the but the work right now that we talked about and that I hire people for is data engineering. And so we've what I like that we've set up is we've got a lot of runway for folks with a broad set of skills to come into my team, I have to be really realistic about what I promised the work is going to look like and when so that we're not bringing in people who have a very particular vision of data science that that we just can't offer. There are other places that can. I would love for folks on my team to be able to do that kind of work when we're ready for it. And when we've got the skill, but we're on a path.

But without the without the business need, it's not fair for me to tell people like, come join my team and be a data scientist the way that the way that sort of the world says data science looks. It's going to be technical, it's going to be interesting, it's going to be rewarding, but it's different from from that other picture. And so I think we have to be realistic.

Connecting R and Python to company data

Maybe I should talk about our infrastructure a little bit. I said that that we're, we're pragmatic data engineering. And so some of that means some of that means for some projects, it makes sense to connect to some databases and do some transformations with Python and produce something on the other end. The biggest, the biggest kind of piece of infrastructure that we have in place right now is a set of integrations, not written in Python, that, that, for that, that build in conjunction with a bunch of other mechanics, build a big data mark that feed a significant population of our analysts who use Tableau against it.

I bring in R whenever I get to sit down and do something because I like to work with it. And, but again, it's, it's, you know, the sort of the right tool for the job. And one of the jobs that we've had over the last several years is, is bringing together a bunch of data from some complex data sources, having a pretty deep business understanding, and helping to feed this, this big data mart. That's pretty, you know, like, that's not the, it's not the thing necessarily that you put like on the data science recruiting poster, but it's, but it's really, really critical. And the folks who have done that work are hugely talented. And absolutely critical for our team success, and have, I think, developed as part of that program, a ton of really great skills.

I would say if, if Python connecting to finance data as an alternative to spreadsheets, helps get the work done that you need to get done, that's the case that you make to anybody who is who you need to get buy-in or permission from or, or whatever. And if in that method, you can then render out the kind of data products that your customers need, then it's success. And then you've got a then you've got a cycle where you can say, hey, I worked through this Python oriented method to provide data to customers, it worked, let's expand the scope, let's upscale the number of people who rely on this, and so on.

I think it is. I am. I love Libby's comment, too, which goes along with that. It's like data science is not one thing. And I'm thinking that might be the title of this conversation on YouTube.

Balancing technical and people leadership

Yeah, yeah, sure. Thank you. So it was really just going back to a comment that you had made about kind of balancing, I think when when you'd first mentioned it balancing kind of like division aspects of a leader and the kind of like the technical expertise that people in these roles generally have. And so really, I was just hoping that you could elaborate that a little bit more and kind of like how you handle that balance. The general background being where I am, generally speaking, the higher up you go, the less technical you are in terms of just kind of like title. And I'm kind of at the first inflection point now where I'm beginning that transition from kind of like, person who is turned to for a lot of technical things to being more kind of like the people leader. And that balance is something I struggle with.

Yeah, no, I hear you. I think I'm feeling a lot of that, of that same thing. For me, I think the a big part of the reason the work is rewarding is being technical. And so selfishly, I don't want to work myself out of a, out of a job that that is at least somehow, somehow hands on. And I think I'm working on figuring out how to, like influence with some with some kind of vision, but also being really open to what are the tools that the folks on my on my team want to use, what's going to be rewarding for them and sort of sort of letting them run.

So maybe there's kind of a kind of a path there where, you know, if I'm maybe part of the technical piece is, for me is figuring out, like, what's the potential solution space. And I need to be able to understand that enough that I can be like an advocate for the for the kinds of tools that people want to use, and understand them well enough to, you know, do do administrative things like like make investment forecasts, like how much is this going to cost? And can we can we afford it? Should we afford it? Right? Those are still those still require me being technical enough to understand the payoff and the the constraints and the cost and benefits and things like that.

The, I mean, I'm really, really lucky right now in that I can be strategic, and I can go into conversations about our, like enterprise global analytics direction, and I hope be influential on behalf of my team. And then in the afternoon, I can look at code with someone on my team, and we can sort of ideate together, like, what does a good a good solution look like, that kind of being able to do both of those is great. And so, you know, I would hope that I don't end up in a role where I don't get to have to have that mix. So I guess, you know, ultimately, I think I'm really sympathetic to the kind of position you're in right now, Daniel of, of like, what is good people leadership look like? And is that rewarding while at the same time being able to be technical and hands on? And I think I'm lucky in my organization that I'm able to do some balancing of it. And I hope I can continue to figure it out and hope to do it well. But yeah, it's hard.

Project management and stakeholder questions

That that last bit implies a lot of organization up front about knowing what to tell people they now need to do. A lot of a lot of leadership at Gore is kind of evolving into a commitment that that may be expanding. And, and then learning, what are all the things that you don't? What are the organizational things that you just you had no, no idea about? You know, I, I've had to learn, like, how, how do I make an a budget forecast? How do I make a budget forecast? Fortunately, I have, I have good, my team leader, the person who provides leadership to me is really, really supportive of, like helping me figure those things out. But that's not universal. And a lot of those things, I think you sort of sort of stumble along.

One of the things from from a call, two or three weeks ago, the Toronto Health System folks, I think they described that they, when their team formed, they had a portfolio manager or someone to that effect. That to me is such could be such an important kind of founding condition for success going forward to say from the jump, we want to have people who are helping us to organize this portfolio of work. I think my experience across a bunch of roles, it is really hard to come too late. But that doesn't mean we shouldn't be thoughtful, thoughtful about it.

Differentiating data science and data engineering roles

Good question. There's a whole, there's a whole out there that I think is pretty loaded. I guess I had I had, I had a similar conversation in in hiring at one point about basically, the end of which was was was saying, Hey, I don't think it's the question about about like the Are you over? Are you over qualified? Are you going to get bored? Like, I think that's for you. That's, that's your like, that's for you to think about, I think, I think if we take seriously, people who are interested in our, in our roles, we got to think about like, are they are they qualified for, for, for this work? And trust, trust that they are when they apply for our jobs, that they're interested in them, I guess.

In terms of the difference, I mean, I, I think there's a lot of fluidity between them. And that's why I think it's important to say, aspirationally, my we call the folks on my team data scientists, most of the work is probably what we call data engineering. I don't think I'd draw a bright line distinction between them, though. I think that if the if the distinction between data engineering and data science is a is a technical one about like the methodologies that you use are, you know, are you doing machine learning? Or are you doing, you know, complex data management processes? I think that makes it really mechanical in a way that I don't know if it if it serves us. In either situation, you're profiling information, you're asking questions of data, you have to be responsive to the things that you're that your stakeholders need.

And I think, I think doing data engineering, I don't know, maybe this is provocative. But I think doing data engineering is a kind of data science. And I think that doing data engineering is also foundational. I think that performing data science also involves doing a lot of data engineering. So I don't think I would like draw a super bright line. But I do think that that people who are hiring and people who are leading teams, and people who are doing the work need to have really serious, honest conversations about, like, what kind of work does this role need? And does that look like the stuff that I want to do the stuff that I've trained for the stuff that I've, you know, envisioned myself doing? And if not, then yeah, I think you need to be really honest about, okay, maybe it's not the right, the right fit.

I think doing data engineering is a kind of data science. And I think that doing data engineering is also foundational. I think that performing data science also involves doing a lot of data engineering.

Self-taught versus formal education

I mean, I'm a sociologist, and I convince people that I could do this stuff. So I'm I'm biased towards saying I don't think computer science should be a preferred degree. A couple people on my team have CS backgrounds and degrees, and they're great. I don't think it's the only way to be successful. I don't think it's the only way to be successful. I mean, I think if you look around the community, there are, you know, so many that this community that our RStudio and Posit has been such a, I think, foundational positive part of there are all these people who come into this kind of work without that background, and they're great. And so for me, I want to be really encouraging of not needing to come through that, that particular pipeline. It doesn't, it doesn't exclude you, of course. But I think there are tons and tons of ways to come at it without, you know, there are all kinds of people who are who are super technical and do really fascinating, complex, interesting technical stuff who aren't who don't come out of computer science, they come from, you know, history and literature and social science. So, you know, that's, yeah, that's obviously my baggage, right? But But yeah, I don't think you need to, I don't think you shouldn't need a CS degree.

Internal community and partnership

On the on the community one, I think we're we're working on it, you know, we have, my team is a little bit unique in structure within our enterprise right now. But there are individuals and, and other teams sort of forming. And I, you know, and we have some of them are in are in whole other businesses. And so we don't necessarily have a natural connectivity to them. But we're aware of, you know, we're aware of them out there, we're trying to build some sort of networking so that we can, you know, share good practices, or at least, like at least see each other as peers out there doing similar work, even if it's not the same work, or even if our, our tools and stuff are really, are really different.

And in terms of the second part of your question about sort of the partnership, I think that we're successful because we are such close partners to our, to our customers. We don't, right now, I'm sort of figuring out with the folks on my team, should we have, you know, should a person on my team be dedicated to doing work with our quality organization, for example, or does my team kind of kind of float and sort of, you know, fill needs as they come up on projects. And I think there are pros and cons of both of those. But thinking about your question of what does the partnership look like, I think, you know, we do well when we have good close relationships with our customers. And that means that as data folks, we understand the business, we understand the functional needs, so that we don't have to, you know, so that they so right, so that they're like, they trust us, they know that we understand their problems enough to help to help to solve them.

Quick wins in project management

We, so we, we talk a lot, maybe, maybe two things that I can try and say really quickly, we talk a lot within my team and the bigger analytical team about feeling comfortable pushing back on requests and saying, what are you going to do with this deliverable? What are you going to do different or what's going to be value added because of it? That is a really helpful clarifying question, not only in terms of managing scope, but also in terms of better understanding what success looks like. Because often the thing that they say they're going to do, isn't necessarily a direct line from what they asked, from what they asked for. So being confident enough and having enough credibility as a big team to say, to ask that, I think is really, really good for us.

And I think I said, I had two, two thoughts there. And I have no recollection now what the, what the second one is. But that one for us, I think is, is a really important, reaching a milestone where we could push back in on, in terms of scope was, I think, a really significant one for us. And the way that I think we crystallize that is to say, okay, what are you going to do? You know, help us define that. And I think that's really, really a key one. Tell us how you're going to act if we make this thing, or if we give you a versus B, what do you do differently? Is it's really key for everybody, I think.

Thank you. This, this is fun. And yeah, slightly self indulgently, you know, just real quick, having this community sort of being able to be a part of over the last year so has been really great, super validating. And, you know, congrats Posit on being Posit. You know, that's such a big milestone, and, and really fun. And, yeah, you all are a big part I think of why so many of us feel like this is a community we can be a part of. So I'm really, really grateful. And this was really fun, fun to chat with everybody. Super happy to talk more if folks want to find me. And I'm really happy to look around and like feel like a peer to a bunch of folks. So thank you.