Data Science Hangout | Joseph Korszun, ProCogia | Encouraging People to Learn to Code
We were recently joined by Joseph Korszun, Manager of Data Science at ProCogia. There was a great discussion on mentorship and helping teach people to code. 🤔 How do you encourage people to learn to code? (15:27) ⬢ At every point in your career, you’ve written a formula in Excel so just lending that to translate into you know more usable scripts is helpful. ⬢ It starts with identifying what their determined career path is from their own perspective. Some people want to be more statistics oriented, or more ML engineering oriented. You have to understand what their focal point is. ⬢ Help identify someone’s pain point that they have right now and with that - what’s the quickest way to up-skill them in that? ⬢ Have people do some hands-on labs. This can be more beneficial than watching videos or reading textbooks and allows you to get into the code. You’re going to have errors along the way but that’s ok! ⬢ Let new coders know that it’s okay to google and copy/paste code. This can unblock new coders, so that you don’t have to code everything from scratch. Adapt existing code to your problem. ⬢ You can pair someone with somebody else who has that skillset to help mentor them. ⬢ Remember that junior colleagues often have a lot to teach to senior team members as well. Things are changing so quickly, and there are so many ways to do things. Interns may teach you something new technically and senior colleagues may then mentor them in the soft-skills. Resources shared: ⬢ Working with IT: https://lnkd.in/dzU-uzzW ⬢ Security courses here give practical tips for how to follow good security practices as an R programmer: https://lnkd.in/dmb2nmGV ⬢ Manager tools podcast: https://lnkd.in/dXY6hK7V ⬢ Breaking Math podcast: https://lnkd.in/dEJNu64F Where to find more? ► Subscribe to Our Channel Here: https://bit.ly/2TzgcOu ► Data Science Hangout site: rstudio.com/data-science-hangout ► Add the Data Science Hangout to your calendar: rstd.io/datasciencehangout Follow Us Here: Website: https://www.rstudio.com LinkedIn:https://www.linkedin.com/company/rstudio Twitter: https://twitter.com/rstudio
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
Rachel Dempsey. Hi, everybody. Welcome to the Data Science Hangout. If you're joining for the first time, it's great to meet you. I'm Rachel Dempsey. I'm the host for the Data Science Hangout. If this is your first time, what is this? It's an open space for the whole data science community to connect and chat about data science leadership, questions you're all facing, and really just what's going on in the world of data science.
So there's a few ways that you can ask questions today. You can always ask questions anonymously through the Slido link, which Robert will share in the chat in just a second here. You can raise your hand on Zoom, and I could just call on you. Or you could also put questions into the Zoom chat. And if you want me to read them out loud instead of you, you can just put a little star next to your question too. But I do like to reiterate, we want to hear from everybody, no matter your level of experience or the industry that you work in.
I am so happy to be joined by my co-host for today, Joseph Korsen. And Joseph, I might need a lesson in saying your last name. Manager of Data Science at Procogia. And Joseph, I'd love to have you introduce yourself and maybe share a little bit about the work that you do.
Sure. Well, thank you for having me, Rachel. Happy to be here, and thank you all for joining as well. Yeah, my name is Joe. You did pronounce my last name correctly. It is Korsen.
You know, kudos there. But yeah, I am the Manager of Data Science at Procogia. My role primarily is delivering engagement for our clients, making sure consultants are kind of on track. I help out with a little bit of code review here or there. But for the most part, I'm kind of a deliverables manager. I have oversight on progression as well for consultants, making sure they're on the correct trajectory for their career path as well. Internal development's big. So that's kind of a little bit about my role.
Team structure and background
So I do manage a little bit of variety of data scientists. There's some bioinformatician, genomicists on the team. I have a few data analytics stragglers in there too. But yeah, so primarily I manage a team of 16 that's going to be bumping up to 18 right now.
Their work kind of varies depending on their role and expertise. Some people do ML ops, ML engineering. There's some data engineers as well on that team that specialize either in Azure, AWS. We have some Google Cloud Platform gurus on the team as well. But yeah, day to day, a lot of variety within the team and kind of the role in general.
So what are you super excited about right now in data science?
Well, just kind of the opportunities, right? There are so many problems in the world that data science can solve, whether that be supply chain, cancer research. There's a lot of improvements that can be made in the world today. And I think that comes through automation initiatives, but eventually you need an understanding of the data set in itself. So first and foremost, I think we identify a problem. We look for a little bit of a solution to the problem and then kind of let that be self-sufficient, right?
Moving into leadership
Yeah, it's a little bit of a difficult leap, I would say. I found myself being a little bit passionate about diving into some code, understanding a problem at hand, but those don't really change too much. You're just a little bit more hands-off. You have more of a variety of problems, but the thing that led me to help others is exactly that, right? There's more of an opportunity to help develop people, round out some skill sets, identify maybe some weaknesses, some strengths where others can actually help one another as well. So that's a little bit of part of my role as well. So that's the most satisfying and what really led me to take on a little bit more leadership.
We are a fast-growing firm. Last year, I believe we doubled in size. We're on a similar pace this year. Can I ask you, how do you manage professional development and keep track with 16 different people?
So it's a little bit challenging, but I think you kind of face similar challenges with smaller sized teams as well, right? So with a smaller firm, we are kind of considered a startup. So for the most part, it brings about more opportunity. So more senior people, they look for more of those leadership roles, those tech lead roles as well. For the most part, the more junior analysts or data scientists, they all have a little bit of a pain point where they need to develop, round out some skills. For me, I try to see where people sit currently, benchmark that a little bit, look for areas of improvement. I conduct one-on-ones. I try to be on top of the day-to-day workload for them as well. I don't want them being overwhelmed. Gradual progression is probably the easiest route to take for most people.
Do you miss the coding side of it? You said you weren't very hands-on these days. I was wondering what you thought about that.
Yeah, so there's opportunities, you know, not within your daily profession to still establish some professional development if you're looking to enhance your technical abilities. Part of being a manager as well as, you know, being experienced with, or at least have a baseline understanding of some of the technology that's currently in development, right? So moving to more cloud platforms, I think I've been learning a little bit more about data engineering, upping my Linux skills as well on the side. So it doesn't, you know, fall off the table. You still want to make sure you're up to date with the latest technology, understanding how some of that works, going through some tutorials as well. So I don't think it really just completely falls off the table. It's just not part of your day-to-day life anymore, but there's always opportunity. The continued curiosity is a big thing that I don't think ever really leaves you.
The continued curiosity is a big thing that I don't think ever really leaves you.
I think it's kind of where the company's at as well, where I look to round out some of my skillsets. You know, if it is ML ops, understanding how pipeline development works, eventually data scientists get a firm understanding of, you know, statistics and, you know, that technical knowledge doesn't leave you too quickly, thankfully. But the programmatic side of things, helping out with code, there's always going to be somebody on the team that is going to be more proficient at you at coding. But you still need to have a little bit of a firm base as to how things work on a high level.
Career path and background
There was an anonymous question that was about your background, and what led you to this field?
You know, I want to point back to curiosity, I would say. Through my progression, I think I started off doing some economics during my initial master's. I think that was in business intelligence and analytics. See, at the time, analytics was still relatively new. I'm showing my age a little here, but, you know, you got some deep dive understanding of how AI would work, you know, understanding some Python implementation. But the continued development, I would say, for me is, I wanted to get more, I wanted to take a little bit of a step back. Statistics is pretty much a lot by hand. You might use SAS a little bit. R is very common as well for statistical programming, but the inferential side, you know, I was trying to understand things from a business perspective.
I wanted to take a little bit of a step back, like, see what I can get from some of these assumptions, you know, tests that you perform. So I would say my progression is just hopping around a little bit, seeing what fits well, you know, trying to master a skill set at a given period, and continuously moving forward, I would say, is the biggest challenge.
Hiring and growing junior talent
So I've been talking to lots of people on teams around, you know, kind of in our R space, where they're really hiring just seniors are not really looking for anybody who's junior because they don't have the seniors in place to grow juniors yet. And I've been curious if that's been a challenge that maybe you faced in your org.
Yeah, I mean, it's definitely a pain point, I would say getting more senior people in there. But part of the progression aspect with larger firms is maybe these more senior people aren't given the opportunity to mentor more junior analyst programmers. So we try to give them that opportunity. So internally, we've tried to take some of our senior people do a little bit of, you know, a weekly hands on coding session with some of them understanding how some of these data science techniques work. I think a lot of our work centers around bioconductor right now. But I would say, you know, giving those people an opportunity, continuously looking is, is probably my advice. But a lot of people are just looking to help others in today's society. So giving them that opportunity, showcasing that your firm's really about that, I think will help retain and acquire some of the key talent that you're looking for.
Tools and platforms
Sure, we are a consulting firm. So it kind of depends on the client that they're in as well. So in house, we do have a little bit of a playground in AWS going forward. So that's primary target for us internally, we want to continue, you know, getting people acclimated with some of these tools AWS offers, you know, spinning up EC2 instances is a big thing. The parallel processing compute. So I think that's kind of the direction we're taking internally. But depending on the consultant, it's kind of where the firm they're allocated to, and the use cases there for, you know, what tools are given, but most of them are on cloud, they're either Azure, it seems primarily or AWS, given those are our partner networks.
Yeah, so I think we primarily have Tableau and Microsoft Power BI. I think we have more Power BI developers than Tableau at this point. But they're not going to be one in the same. Tableau and, you know, Power BI are easy to develop, you know, key visuals for business objectives. I would say Python are both of those languages are geared towards understanding what's going on with a data set at a given time. So when it comes to presentation, continual integration, dashboards, visualizations, they're great, especially for automation initiatives. So we do encourage some of our data scientists to, as you know, be familiar with some of those visualization tools, they're very key for business objectives, relaying information to stakeholders. So identifying the differences there, I would say, you know, perform some of your inferential analysis, exploratory analysis with code, when you're ready to kind of present that to somebody else, that's when the visualization should take form.
Encouraging people to learn to code
Yeah, just real quick, I'll just introduce myself. I'm an engineer for a railroad maintenance company. And I've been doing that quite a while, I'm a PE and all that. And recently I was paired up with a data scientist, somebody kind of like what you've described yourself, and I was given some work to do with him and really enjoyed it, and ended up moving to work with him. It started off as, he kind of came to me with some, how do you do this and that, and I gave him all these messy Excel sheets. And eventually I moved to his group, and now I'm in his group, and it's a bit tough learning how to code. I never was taught how to code, but it's going very well. I'm just a little curious, how do you have people to work on you who have maybe a lot of some skills, but zero coding skills, and how do you encourage them to kind of go on their own with that sort of thing?
Yeah, we definitely have people that are, you know, unfamiliar with some semblance of coding. I think at any point in your career, you've written a formula in Excel. So just learning to translate that into, you know, more usable scripts, I would say. So how I develop people, and enhancing their programmatic efficiency. Again, kind of pairing them with somebody else, but you know, I think it starts with identifying what their, what their determined career path is from their own perspective, right? So some people, they want to be more statistics oriented. They want to either be, you know, more ML engineering oriented, right? So you have to understand, like, where's the focal point for their career going forward? What's the pain point that they have right now? What's the quickest way to kind of upskill them in that sense?
So the most recent case that I have is, we had somebody that really wanted to, you know, get into more of the architectural design space. So, you know, getting them familiar with some of the tutorials, you know, just having them do some hands-on labs. I think it's more beneficial than watching videos, reading textbooks. You're actually getting, you know, down and dirty with some of the code, and you're going to have errors along the way. That's the most important thing. I don't think anybody's not written a script that didn't function the first time. So having an understanding that there are going to be errors along the way, giving them the resources that they need, whether they're a visual learner. If they do prefer textbooks, that's okay. You know, some of the more stats oriented people, I would say, prefer more text from what I've seen. More of the engineers, maybe a little bit more of the visuals, documentation, just a little bit of a hybrid approach. So providing them the resources that they need, understanding where's the initial pain point in development, and just giving them the tools, pairing them with someone that may have that skill set.
I think at any point in your career, you've written a formula in Excel. So just learning to translate that into, you know, more usable scripts, I would say.
Mentorship and learning culture
Hi, sorry. I'm new to this group. First time I come in. I heard some blimps about, like, how to mentor, you know, new coders. I've done that a lot. And one thing that surprises me all the time with new coders is they feel uncomfortable just googling and copy-pasting large chunks of code from the web. So that's just, I know it's a silly thing, but I feel like that unblocks new coders, that you don't have to code everything from scratch. You can literally search it, google it, copy-paste it, and adapt it to your problem. And yeah, for some reason, that's something that new coders feel reluctant to do.
Yeah, so I am graduating this semester. I am wrapping up some of my work there. Do you feel like that's helped you, sort of, in your management role, or even just as a data science team member? Specifically the stats masters, because I saw that you had another master's.
Yeah, so I think both actually do help. I didn't plan to step into the managerial space. It just seemed to be where I was needed the most. So I'm always willing to help out others, but for my own progression, the stats masters does help, just because it's a little bit of a different approach than, say, a machine learning engineer or a typical data scientist is learning in school now. You've seen some of the degrees coming up. They're data science, business analytics, ML engineering. All of those have a little bit more specialization in one key area or not. So I would say a combination of both the business intelligence and analytics degree helps really solidify the business foundation understanding for myself.
And I do like to highlight a little bit with this development, too. Some of the data scientists, it's a little bit different way of thinking, so some of them start off with a problem. They look for what are these key features going into this model, so I kind of approach it from a statistical perspective in that sense. But from a business perspective, what's our key objective that we have? Can we work back from there and establish some sort of understanding of the data set in itself? So there's two ways to approach a problem. One is more linear, and then the other one's kind of working your way back, have an understanding of what's our end goal here? What do we want to establish, and how do we get to that objective?
Sure, I think it's more of a mental blockage that you have to get past, and I think it's also something that maybe women in data science struggle with maybe more than men. I'm not going to generalize everybody, but it's a common feeling for me where I think like, oh, I don't have anything to give anybody else, but I have the desire to. And when I talk to other data scientists that are kind of at my level below, they're constantly telling me like, you know so much more than you let on. But not being a senior and not being a lead, it feels like a presumptuous thing to do, to reach out and want to talk to other people. But I'm getting over it slowly.
So I find it, I find that, you know, the feel of incompetency, kind of, I get that. I actually learned R by teaching it. So I had no clue. I mostly worked with R, but I had no clue from the start. But what I did do is I had, you know, people that I was teaching, and I would teach something that I just learned. And I would ask them to come with their problems to me. And then if I can solve it, I had like, a person that I had established contact with that I would go to to solve that problem, and come back to the mentorees. And that worked for me, because you learn from other people's problems. And you also like, teach things that you know, like, or that you almost feel comfortable with.
In the early days, like you need one contact person that you know you can go to if you don't know. And then you can teach what you do know to, you know, who you're mentoring, and they know that you can get information if you don't have it.
Another thing that I do regularly is when I discover something, and it, you know, something new that I didn't know, I usually present it to the team. And so, you know, they might know it. But that puts a learning kind of aspect to the team. And they will put forward stuff that they just discovered, a new package or a new, you know, whatever. So I think that also helps team learning. For sure. Yeah, we just implemented some knowledge sharing sessions ourselves, trying to get into that mindset of like everybody sharing.
So I, a couple of things. I really think there's power in learning out loud. Most people are experts at a very, very, very narrow field. And so they are, if you learn something, you can typically pass it on to many people, and they'll go, oh, wow, I hadn't known that. That's fantastic. The other thing I saw just today was that there was a psychology type poll about learning and asking for help. And it found that 44% of people won't reach out for help, in case it makes them look like they don't know what they're doing. But that means that 44% of people aren't asking for help when they need it. So if you're ready, you know, it means that you can help a lot of people, because there's a huge number out there who really need help and are just too afraid to kind of fess up, come forward and say, actually, I do need some help here.
It's a community service. I want to touch base a little bit on this. So you got to be mindful that, you know, everybody's gonna be a little different to your workplace. So, you know, you can have as much technical ability as you want. But if you're struggling to find people that are willing to reach out for that help, that's kind of the pain point in itself, right? So it seems like you're on track for community involvement within the organization. But the culture is a big thing. You want to, you know, build foundational skill sets, but you want to make sure the transparency between people is something that's, you know, within the workplace too. If they're not comfortable reaching out to a manager, that's okay. You know, there are other people that I'm sure they could be paired with that, you know, would help them with their problem. So just be mindful, I would say, of every individual. Some people don't like to reach out just because it's in their personality, right? So you have to have an understanding that all people are going to be a little bit different. But we all have similar goals, right? We want to continue to move forward, continue to progress.
So I think you have some semblance of a relationship there just based on that. And Joe, how does the, oh, you go ahead, Mike. I'm also thinking of, you know, what Joseph just said reminds me of J.D. Long's stuff about empathy. So J.D. Long tweets as C-mastication, or cerebral mastication, and he has presented at RStudio conference about empathy, and how if you approach people with problems with empathy, you know, folks are looking for someone kind to come alongside and cut them some slack and help them out. So yeah, if you wade in, hey, look how much I know. I'm going to beat you over the head with this. You'll never win friends. You're not going to know it all, too. That's part of it, right? So there's no real reason to treat it as such, I would say.
A lot of it, you know, it may be segmented out a little, you know, depending on where people are located, what firm they're allocated to. But I do encourage, you know, we have some ML tutorials going on. I'm looking to establish more of the data engineering tutorials. But I want to foster this community culture. So that's the biggest takeaway. Everybody has their own trajectory that they're looking for. You know, giving them kind of a buddy system of somebody that's a little bit more senior following that pathway or has already been through that struggle. Yeah, I can provide as much resource, as much guidance as I can. Community, external events are a big team builder, too. So you want to have a relationship with people in person. Open office hours, too. You know, they're very crucial, I would say, for certain people. So all of those in combination, I would say, help kind of falter this continual learning objective that I'm trying to establish internally.
Data engineering vs. data science
And you caught me just as I was stuffing M&Ms in my mouth. Yeah, I guess, you know, in my organization, I'm in an early stage data science team, and we live outside of IT. We're actually a research function. So it's a little bit interesting, and we're reliant on IT for data warehouse, graduating into a data lake. And there's an ebb and flow there. And we try to keep our distance from those data management activities. But at the same time, we often say, okay, kind of have to go commando or have to go a little workaround and band-aids and negotiating that to what extent. And I'm just curious about other people's experiences with this.
I mean, I think, you know, everybody's going to be working together too, from my perspective, right? So the data scientist should have an understanding of the architecture that's being developed, right? There's parameter checks as well, dealing with that infrastructure build. So something to keep in mind is, you know, what's the intent of working with the data? So I don't think it's just a complete migration. You want to make sure utility is going to be maximized as well from your analyst data scientist. So I would almost, you know, encourage a little bit of, you know, overlap between the groups, at least for input, making sure everything's kind of, you know, you want to make sure qualification of the system essentially is up to par. So I think there's a little bit of input that's needed. Input and perhaps, you know, talking about empathy, going back and saying, okay, look, we're all working on this together. You know, let's help each other out by actually being a team and being colleagues.
Sure. It's interesting because I'm just wrapping up an engagement with a data engineering consultancy, which we used to help our small team move into the cloud, some of our ETL processes. But ultimately we are still responsible for them. Our IT doesn't help. We don't have data engineering teams and none of the companies I've been at have had data engineering functions when we've been there. So the teams I've been on have always been responsible for that, for better or for worse. Many times for worse, sometimes for better. I've sort of developed my own philosophies on how to do this that would probably make data engineers' eyes roll to the back of their head. But it's about optimizing around the way I want to be able to work. I want to always have the data ready at hand. If I could all anticipate the kinds of requests that are going to come up in the future to front load the gathering of that data in advance and then automate the collection of it, even if it's not particularly sophisticated. And then I basically want to minimize the time of every new project that is spent on data collection and data engineering. And so how you get there can be different ways, but by optimizing to the analytics approach later, generally speaking, I'm able to do the work on the projects I'm working on pretty quickly because the adage of like you're going to spend 80% of your time collecting the data doesn't apply if you did the work in advance to build up the data sets that you're going to need later.
Yeah. I mean, not too much to say that probably a lot of us have experienced, or at least for those of us in like sort of the government area, public health is horribly underfunded and IT is just a whole other field in the realm of public health. So yeah, that has been definitely a struggle for us as well. And I just put in the chat, we're trying to focus on increasing knowledge and training for our IT teams as well, just to try to get everyone up to speed, try to increase the knowledge base and just kind of try to get support in the way that we need. Because it's true, I mean, you're pretty much dead in the water if you don't have the right infrastructure set up and the right people to support that infrastructure.
IT and data science collaboration
I'll just comment because I come from, I'm the interloper here because I'm really an IT person, not a data scientist person, but I have to support people who want these environments in order to be able to do the data science. So I'm quite interested in that interface layer between the users, the people that want to actually use the products which we'll implement, and how we get that working. Because obviously the traditional IT department isn't well suited to doing the sorts of work which you do. And that's where things like DevOps and being a lot more responsive to users requirements and actually getting users as we're developing the products, as we're implementing our RStudio environments, getting engagement as early as possible along with our users is really critical.
So as we're developing the platform and rolling out new versions, we're continually trying to engage with the users and say, what features do you need? Are you happy with the way this looks? What extra libraries are you going to need? How do you want to interact with us? Do you want to raise a service ticket or do you just want to post a message on a bulletin board saying, hey, this library is needed? So it's quite interesting to see how IT interfaces with users and it's that sort of almost like developer oriented IT, which is relatively new. Well, not that new, but it's now of greater focus.
So we have a product manager for doing our stuff and data science. We have lots of key users scattered about. So I work for a very large agrochemical company. So we have big central heavyweight IT departments, but then lots of little sort of offshoots and little group clusters of engineers who go around to help people. So we're more on the research side. So we're trying to sweep up users who are interested in RStudio, Neo4j, Mongo, Mundo, all of the little things and try and say, can we do this better than you're actually doing it yourself? So we have a lot of users who will actually start up their own environment and get it running. And now they want to keep it maintained and don't really have time because they're supposed to be doing their day work. So we, as a sort of relatively lean team, come in leaping and say, how can we actually make that a bit more stable environment?
So you've got the thing working. Now let's take over responsibility for patching it and making sure it's up to date and also creating a community around each of the products. So we'll have an RStudio team, teams group, where people can ask questions about RStudio. Similarly, we'll have a focus on R and Python and other sort of like technical areas. Then people can actually, if they're interested, they can join that community and engage. And hopefully some of us will be scattered about those groups to be able to sweep up saying, oh yeah, that's an IT related issue which we can help with.
But our problems also have that our main big IT departments aren't interested in this sort of user engagement. And that's really, we think is a big failing because they will run a giant GitLab server and that's great, but they don't patch it. Well, no, we run a little pirate GitLab server which we patch on a regular basis and people tend to come to us. So you can't stand up a service unless you're willing to provide a full service around that. And that's that social, that's that engagement with the users. So just finishing a project is not the end of the project.
I'm learning this as I'm going along as well. So this is all, there's a lot of stuff which is, we're learning, we're doing a big AWS project. So we're rolling out RStudio with Terraform and Ansible and others like cool bits of technologies, which we're still, we're learning about as we go along. And it's very difficult to actually, a lot of this information, there's bits, snippets available on the internet. So we're having to work this out all by ourselves. So we're also, although we're a little sort of pirate offshoot doing all this stuff, we're still also trying to learn as we go along.
Client success story
Would love to hear a cool success story of something you delivered for a client.
Oh, we had a recent, somebody reached out to us, a firm, they were working, establishing some on-prem servers, configuring RStudio Workbench, trying to establish an RStudio Connect as well. They ran into a bunch of issues, eventually reached out to us, to provision their, ensure that their provision servers were indeed functioning correctly with their RStudio Workbench, Connect, they could publish with some version control as well. And it took us a little bit longer than I would say, but diving into the deep nitty gritty of the problem itself, whether it be a config file, whether it be a firewall prevention, right? We wanted to make sure that we rounded out some of these understandings of the problem at hand. It wasn't one central problem as we were kind of under the impression of at the time, but that was a huge victory for us. I had somebody kind of working with one of our more senior DevOps, she ended up developing very quickly. And I would say that was a major win for us just because of the problem at hand. The client was exceptionally happy, I would say. Once the issues were resolved, they were able to get on Workbench, write to some shiny applications to link back server. So it's happy, it's a happy moment, I would say, when a very simple problem, it seems, turns into a little bit more of a challenge than you expected. And you're able to kind of persevere and get over kind of the last step there, making sure the implementation is up to par and users are happy with the end product you delivered.
Domain expertise and hiring
Yeah, so I think right now, we've just been focusing on building out the infrastructure there. So we've been targeting people with the domain expertise for now. Again, kind of, you know, somebody mentioned previously, it's probably going to find more senior people. I think you want to start with the senior people that are willing to kind of take on that leadership role, potentially move into beyond the current technical lead that they are at the point in their career. But you know, just getting somebody in that's more senior, it has that domain expertise, it helps build a lot quicker than somebody, you know, with a lot more variety. We look to build out some junior people too. But it starts with building a firm foundation. I always like to, you know, circle back to understanding the foundational skill set and building up from there. But you need to have a firm base with what you start with, if you're looking to build out that sector.
Inside vs. outside IT
So I work on a team, data analytics and data science team that's within IT. And there's been some discussion on moving us outside of IT. And I have seen in the chat that there are a lot of people talking about some of the cons of being outside of IT. But I guess I was curious about some of the positives.
So most of my analytics has actually been outside of IT. You need a strong leader. And the most successful one that I've been on, we had our own data engineering resources. Data science doesn't get done without data engineering. And I've been in organizations where you don't even get any data engineering support. And it's kind of a complete nightmare. They look at data science as you guys are just a corner case. We're going to take care of the rest of the organization first. And it's kind of like, well, then you're not going to get any innovation or data science out of us then. And it works extremely well as its own organization, especially when you have someone on the business side, or at least someone strong in the business side and domain side in charge that has also a bit of the tech background.
You know, I see the pros and cons to each situation here. I like IT primarily working a little bit closer, especially people building out the infrastructure. I think it's good to kind of, you know, get a requirements gathering session. And like the continual integration, continual development, right? What are the pain points in the system that we've established already? What needs to be enhanced? It's hard to say from an engineering perspective, whether it's kind of cost effective, unless you're understanding a little bit about the analysis techniques that are being applied to the day-to-day work.
I have only been in analytics and data science capacities outside of like core IT. And part of that is because most of my experience is in like financial modeling. So, you know, it's interesting, the like projects where I feel data scientists or, you know, analytics engineers within IT orgs, the projects where they really shine, where you're like, wow, this is an amazing concept that you guys have implemented. I feel like they're usually more backend related, where, you know, they're using ML or AI, like in a very advanced way to make data more consumable for, you know, the entire org, including data scientists. Whereas my experience being like, in these roles, completely outside of IT, I kind of see that the focus is much more on some type of visual storytelling app or, you know, presentation or something like this. So, the nature of the, like, business problems that we're trying to solve are just inherently different. I tend to like that aspect more, because I really do enjoy sort of the shiny app building or like the visualization aspect of data science.
Something that's fun, I was responding to a comment from Melody, just in talking internally and having these inside, outside IT functions, working with IT, my team, we recently stumbled on the phrase, we refer to ourselves as transformers. And it's a way of leveraging the power of data and technology to support decision making by our subject matter experts and business colleagues, but also the other way too. We have an infamous case at my organization asking about usage information, where there was a head of our, basically, account management went directly to a database engineer asking for usage information. And, you know, I have great respect for everybody on all sides of this, but it was a bit of the old adage of gigo, garbage in, garbage out, right? She got back a spreadsheet that had usage data and said, what am I supposed to do with this? And so that's an infamous case here where it's like, okay, the data science team, we come in and we understand, we get to an understanding of your problems that you don't work directly with IT, because then we can help shape and standardize the problem to be able to get closer to decision making.
I think my, my take is that traditional IT departments aren't suited for this. And it's always better if you can do some, if you can, if you can show something and produce a little sort of nifty little products and then show IT, show the IT department, look, I can do this. Then they can actually then take a step. They can hopefully take a step back and say, right, can we recognize whether this is, can we recognize how useful this is and take a look inwards and say, are we the right sort of IT organization to be able to better support people like this? I think traditionally big IT departments aren't appropriate for this. And what you have to think about is, okay, if we no longer have, if the big IT department has become a giant dinosaur by itself, can we think of something which will better facilitate our people to do work? Now that might mean creating better communications, having more appropriate Slack channels, having discussions and having an environment, which is more mentoring and helpful to people rather than these big legacy monolithic IT departments. So the question isn't whether or not you do it inside or outside IT, you do it. If you find, you can find a tool which is useful to you, use it. Now it should be the role of IT departments to be able to now help people do it more efficiently. And if they're not doing that, then they're not a good IT department.
I hear innovative and disruptive and well, we're not all Steve Jobs, but we have things to do and there's increments to be made. And I actually have a substantive PhD and there's an XKD comic where it was like, here's what PhD looks like. It's this little pimple on the surface of the sun. It's like, yeah, you're advancing things and we're not all going to make those huge jumps. But now adopting from some product management, identifying, okay, everybody wants that huge jump, but we can deliver value along the way while offering this expertise. And then within my team, we've stumbled on beginning prototyping, working with IT and being like, okay, we can do this as a shiny app, or we can do this, this is a script that gets to the data artifact that we're talking about. And they say, yeah, I can understand that. So we've gotten to the business needs and supporting decision-making and then transform that and getting to these small bits because it's like the whole scale upgrade of our platform likely can't happen anytime soon, but we can increase the value with these little bits at a time and adopting like an MVP mindset and collaborating that way is starting to get some traction.
Closing questions
There was an anonymous question I missed for you earlier, Joe, which was, what do you do for fun?
What do I do for fun? Well, generally right now, it's just a lot of walking. I enjoy going and seeing the sun. I throw a ball for a dog for a few hours if I can find some time. So those are my fun activities right now, just getting outside, enjoying some weather when it's available. But other than that, it's primarily just like wrapping up studies right now for me.
So I'll give you two podcasts that I really like. And maybe one's very math oriented. I really like the Breaking Math podcast. So that's something that I would definitely recommend. And then one podcast for more managerial stuff, my previous mentor recommended it. It's called Manager Tools. So I totally recommend that one if you haven't already seen it. There's also an additional career tools. So that helps provide a little bit of guidance for individuals, not necessarily managers looking to advance their career as well.
Awesome. Thank you. But thank you all so much for joining today. Thank you so much, Joe, for sharing your knowledge and insights with us too. And Caitlin, thank you for joining. I saw your comment in the chat your first time here. Glad to hear that you enjoyed it. And for anyone else who is a first time here too, we hope to see you back as well. Thank you for joining.