From paramedic to leading analytics in pharma | Dan Haight | Data Science Hangout
To join future data science hangouts, add it to your calendar here: https://pos.it/dsh - All are welcome! We'd love to see you! We were recently joined by Dan Haight, Director of Continuous Improvement Analytics at Merck, to talk about his unconventional career path, the value of lateral career moves (check out his book recommendation on this!), and the importance of creating "great charters" for successful stakeholder communication in projects. Dan's advice about project management in this episode is so valuable. He recognizes how tempting it is to rush into a project without knowing all the facts beforehand, but then your scope starts to balloon, you see the project getting behind, and there are all these constraints you weren't aware of. So, he says to take time to build a charter, be upfront with stakeholders about realistic timelines, and then use the charter as a contract to negotiate scope changes and resource allocation. He also discusses the challenges of working with incomplete data and the need to triangulate information from multiple sources to ensure accuracy and build confidence in the findings. If you're a job seeker or looking to transition, Dan came with great advice to pursue continuous learning, network, and hone the ability to effectively communicate the value of their work. You'll have to listen to learn more! If you didn't attend live, you missed the party in the zoom chat People were excited about posit::conf 2025 early bird tickets getting released, and there was a SUPER great discussion about how to share your work when it's all under NDA or very private due to security reasons. There was some great suggestions, like: 🥸 Anonymize data if it's possible, or present a similar project abstractly Use public data to demonstrate the methods you used, even if you can't showcase the findings Emphasize lessons learned during a project (ah-hah moments) instead of the business impacts IF the overall project failed or wasn't implemented (as is the fate of many DS projects!) Document projects as you go, in a format that you can safely take with you, so that you can remember all these things even after you leave your role Lean on your friends and colleagues to help you describe the impacts you had on a project, or the importance of what you did (we all need to be hyped up sometimes when it comes to writing resumes!!) Resources mentioned in the video and zoom chat: Up is Not the Only Way Book → https://www.amazon.com/Up-Not-Only-Way-Rethinking/dp/1523083484 Shiny Assistant helps you build shiny apps → https://shiny.posit.co/blog/posts/shiny-assistant/ Brag Documents - Julia Evans → https://jvns.ca/blog/brag-documents/ Lessons From Four Senior Leaders in the Data Space → https://posit.co/blog/lessons-from-four-senior-leaders-in-the-data-space/ ► Subscribe to Our Channel Here: https://bit.ly/2TzgcOu Follow Us Here: Website: https://www.posit.co Hangout: https://pos.it/dsh LinkedIn: https://www.linkedin.com/company/posit-software Bluesky: https://bsky.app/profile/posit.co Thanks for hanging out with us! Subscribe to posit::conf updates: https://posit.co/about/subscription-management/
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
Welcome back to the data science Hangout, everybody. So nice to see you. If we haven't had a chance to meet before, maybe this is your very first one. I'm Rachel. I lead customer marketing at Posit. And if Posit is new to you, Posit builds enterprise solutions and open source tools for people who do data science with R&D. We're also the company formerly called RStudio.
I'm joined by my lovely co host here, Libby.
Hey, everybody, I'm Libby. I am a community manager, working with Posit to help foster our Hangout community, which is wonderful and amazing. And I'm also a Posit Academy mentor. Posit Academy helps professionals learn R&Python to do data science. So I'm very lucky to get to do that as well and teach R&Python.
And yeah, and I think a little bit about me, I'm in San Antonio, Texas, where it's definitely not very wintery or fall like, and my background is in supply chain and banking and insurance and stuff. That's me.
I forget to add, I'm in Boston. If anybody's in Boston and ever wants to get together, grab coffee or something, that's where I am.
But the Hangout is our open base for what's going on in the world of data across all different industries, chat about data science leadership, and to really get to connect with others who are facing similar things as you. And we're here every Thursday at the same time, same place, unless it's a holiday, of course.
But if you are watching this as a recording on YouTube and you want to join us in the future, we'd love to have you join us live. And there will be details to add it to your own calendar below.
Thank you so much to everybody here who has helped make this the friendly and welcoming space that it is today. And we are all dedicated to keeping it that way.
So if you do ever have feedback for me about your experience or anything you want to share anonymously, good or bad, or maybe suggestions for topics, I'm going to share a Google form in the chat with you in just a second. But you can always reach out to me directly on LinkedIn as well.
At the Hangout, we love hearing from you. That's what the Hangout is about. This is not a presentation. There will be no slides. The way that this is going to work is we are going to ask questions as a community and have a community discussion.
So there are three ways that you can jump in and share your experience, share a question. And we really would love for you to also share where you are, what you do, if you have any roles that you're hiring for or looking for, so job seekers or job posters.
And I want to reiterate for everybody, as we do every time, that it doesn't matter what industry you're in, what your level of experience is, what your role is. You are welcome here. We want you to be here. So those three ways you can jump in, you can raise your hand in Zoom. One of us will call on you to ask your question live. You can put your question in the chat. That's a great way. We will grab that question and ask you to unmute and ask it live.
If you can't ask it, maybe you're at a coffee shop or you're somewhere loud or your mic doesn't work, just put an asterisk next to it. We'll ask your question for you. And then there's also a Slido link where you can ask a question anonymously, and Isabella will stick that in the chat for you.
With all that, we are so excited to be joined by our other co-host today, Dan Haight, Director of Continuous Improvement Analytics, Global Clinical Trial Operations at Merck & Co. And you may have seen Dan had a different title on our website, so congrats to Dan on this new role as well. Dan, I'd love to have you introduce yourself and share a little bit about your role now. That could be also the prior role too, but also something you like to do for fun.
Sure. Thank you, Rachel. So as Rachel mentioned, my name is Dan Haight. I currently am the Director of Continuous Improvement Analytics for Merck's Global Clinical Trial Operations organization, and I've been in that role for all of about two and a half weeks now. Prior to that, I was the Associate Director of Data Science for our marketing group, specifically around our hospital specialty and acute care brands, so supporting data science and data analytics projects that were around things like patient journeys, patient segmentation, sales reporting, et cetera.
And I work remotely from northern New Jersey, about a little over an hour west of New York City. And for fun, well, my wife and I have four very large dogs, so they certainly occupy a lot of our time and energy. When I'm not doing that, I do a lot of CAD modeling, 3D printing, things like that. So I'm always kind of tinkering and making or breaking something.
Right now, it's mostly organizational stuff. Like I have a toolbox in my garage. I'm just slowly printing folders for screwdrivers, wrenches, what have you, just kind of trying to get myself a little organized.
Dan's career journey
Well, Dan, I thought maybe we could start by talking a little bit about your career journey. Now, in getting to talk to you, I've learned you've had maybe a non-traditional career journey, going from full-time paramedic to leadership roles across really diverse industries. Could you tell us a little bit more about maybe some of the turning points in your career?
Sure. So I've always been in healthcare in some way, shape, or form. As you mentioned, Rachel, I started out as a paramedic many years ago. And from there, I have organically moved into supervisory management roles. And that's when I started to get bitten by the bug that eventually would be Six Sigma and process improvement. I spent a significant portion of my career doing that type of work for a variety of different organizations.
I was with Quest Diagnostics for a period of time, which, for those not in the U.S., is a large U.S.-based laboratory provider. I was with UnitedHealthcare for several years, leading a team there and also leading projects there. Prior to Merck, I was with a medical device manufacturing company called BD, or Beckton Dickinson. And then, obviously, now I've been with Merck for a little over a year and a half.
Like I said, for the majority of my time, I've been involved with Six Sigma and more so the analytics side of Six Sigma. And obviously, you can see where that's a natural progression into more of a deeper data science type work. So for probably at least a decade or so now, I've been around some form of data analytics, data science, analytical programming, et cetera.
Absolutely. I guess maybe even specifically like the experience as a paramedic, too. Yeah, I mean, I think that that experience helps almost kind of give you some perspective about things like urgency and, you know, priority. Obviously, you know, it gives you a skill set that lets you really determine what truly is important and urgent and, you know, what is a high priority versus a low priority. As I like to say, it's a lot harder to light your hair on fire when you've, you know, done that for a long time. So it kind of gives you a sense of calm almost in that scenario.
As I like to say, it's a lot harder to light your hair on fire when you've, you know, done that for a long time. So it kind of gives you a sense of calm almost in that scenario.
I love it. Yeah, I agree. I feel like there are not a lot of analytical emergencies that compare to paramedic emergencies that can give you great perspective.
Types of problems and tech stack
I wanted to ask, Dan, for the people here who are not in your industry, who don't share your sort of professional experiences, I was wondering if you could give us an example of the type of problems that your team tackles just so that we have some context about what you do. And that will help us ask more informed questions. And some of those might be like, what type of data sources do you work with? Or what tech stack do you use? What technologies are really essential to what your team does?
Sure. So I'll talk a little bit about more so about the role I'm just coming out of. Let me just because, like I said, I'm very new in my new role.
Yeah. So the team I'm coming from, we mostly work with patient claims data. We also work with a lot of sales data specifically around both our own products as well as competitor products. It's a lot of a lot of our data comes from external data vendors such as IQVIA is a large player in this space. And like I said, a good portion of our work was around patient claims.
A lot of that was either segmenting patients or segmenting providers, trying to understand some cohort of patients that was either applicable for, say, a new indication for a drug that we were exploring. Is there a potential market here or is there a data gap for patients that have a particular social determinant of health that might have been limiting access to care that we would want to go pursue and try and ensure that those patients are getting care? So ultimately we hand off those findings to our marketing teams.
And through that, a lot of it was, like I said, patient claims. It's all de-identified claims. Certainly there's nothing that can be re-identified or reverse engineered for trying to identify patients individually. But looking at them, probably one of the biggest challenges we often run into is that it's not 100% coverage. Most of our data sets are open claims data sets. So sometimes you don't really know what your coverage is for a particular cohort. You may have 30% of the patients.
And I should preface it by saying my team was focused on U.S. therapy areas. So you may have 30% of those patients in the U.S. You may have 70%, depending on whether they were inpatient-focused therapies, outpatient therapies, et cetera. There was a variety of capture for claims in those spaces.
That was always one of the big challenges that we ran into, was just trying to sort of project up the right amount, you know, based on that subspace that, you know, we were working in in that given moment.
Demanding great charters
But, Dan, something I would love to talk a little bit about, and I think this comes up quite a bit in the Hangouts, but around collaborating with other stakeholders across the business. And something you taught me or were telling me about is to demand great charters. And I was wondering if we could spend some time talking a little bit about that and what that means to you.
Sure. So I know it sounds a little cliche, but, you know, I think, Rachel, I shared with you that was something that, you know, I took from a prior leader several roles ago was, you know, demand great charters. I think that sometimes it can become easy to sort of rush into a project or a particular task without necessarily having all of the facts and all of the information that you need in order to, you know, move forward with intent. And, you know, most folks here probably have that experience where, you know, you see the scope of your project immediately start to balloon or you find out that, you know, the project needs to be done by a certain date that you weren't aware of or some other constraint that you maybe didn't know about beforehand.
So I think that that's really what something I try to, you know, keep in mind whenever I approach any sort of project or any sort of conversation with a stakeholder around deliverables is, you know, really developing that sort of charter document, you know, you know, conceptually and physically, but it really becomes a contract. You're agreeing to all these terms of here's what it is that we need to deliver. Here's, you know, when did we need to deliver it by? Here's the various, you know, budgetary or personnel constraints that you may be working with, you know, and any other relevant information that really sets those boundaries or those guidelines for that project.
And then you can always negotiate changes to your project charters later, but then that also enables that tradeoff conversation, you know, where you could say, okay, we understand we need to add this to our scope, but understand that's us. That's how that's going to change the schedule we already agreed upon, you know, or whatever other constraint needs to be changed.
Ethics and working with patient data
Yeah, so this one isn't really on the topic from before. But first of all, yeah, thank you. And thank you, Dan, for joining. So my question actually is with respect to kind of the profile that I saw for you. One of the things that you might deal with quite a lot more than many other data analysts or data scientists is, you know, kind of the ethical concerns around using data for both providing solutions to, you know, for patients and things like that, but also for marketing and kind of that. So I'm just wondering if you could talk about any maybe tricky ethical situations that you've dealt with, maybe not in this role, but maybe in prior things.
I appreciate that. You know, I can say I'm fortunate in my current role and the role I'm just coming out of. Merck has a very robust, you know, data review process. Essentially nothing can even go as far as our field sales teams without getting a rigorous review. They certainly ensure that we're not sharing anything outside the four walls that we can't and that we are being 100% ethically sound, if you will.
So, you know, we are fortunate with that. We know anything that is going to be – and like I said, sometimes it's as simple as something that's going to face our field sales forces or is going to drive a business decision. It goes through a data review process and that review process with our internal teams. They certainly provide feedback, make changes, et cetera. So we are fortunate to have that available here, and that's something that – so it takes some of the, I guess, ethical concerns sort of out of the equation.
I can say most of the – like I said before, most of what we deal with is all de-identified. There's very minimal features available at an individual level. At most it might be a patient's gender, age. We don't even have things like zip code, right? Like sometimes you have to sort of infer that from a provider's information or some other aspect. So, again, being very careful that we're not even touching data that could be linked back to a patient or that could be used to re-identify a patient. Like I said, it's something that Merck is very, very aware of and very sensitive to.
Yeah, that's probably a more common scenario, you know, to what I mentioned earlier, because we don't have a lot of that – a lot of those features are variables, you know, we often have to infer them. And one way we've done that is we have some zip code-based SDOH data, right? So it's a lot of index scores based on, you know, zip three level, zip five level. And again, you know, my scope was the U.S., so not getting into foreign zip codes.
But, you know, so what we would often have to do is say, okay, this claim for this patient, well, we know they saw provider A, provider A's practices in this zip code, and we're going to use the zip three regional level and pull in, say, the income index for that zip three region, right? It's a very imperfect model, right? There's a lot of model error when we do that, but it's either that or nothing, right? So in a lot of cases that's our only option. Like I said, it does introduce quite a bit of model error.
And, you know, we built a model, just thinking back like about a year ago, where we were able to get some useful information out of that model, but by no means – in a perfect world, yes, we have all this, you know, PII that we'd be able to use to make a more informed model. But, you know, again, to the point we made a few minutes ago, that certainly exposes a lot of that data. Right now we don't even have access to it, right? So it's not even a matter of we have it, we don't want to use it. It's something that we often don't even have or usually don't even have.
Patient segmentation and clinical features
I think you mentioned that you've been building different types of segmentation models based on patient data. And I was wondering if you have any clinical features of the patients that you used in those models, such as diagnosis and EPS. How do you handle the fact that there's a load of diagnosis out there?
Yeah, certainly that's something that we often do is when we are segmenting our patients and looking at – obviously, like I said, most of our therapies are specific therapy areas. So, for example, the team I'm coming from, we were focused on the HIV therapy area for the last eight months or so I was there. So, my team was building models that were very specific to HIV-related diagnoses. So, that's kind of where we always generally start is taking the patients that have any of the diagnoses that fall into that space and then from there building out those various cohort segments based on the marketing team's needs.
So, it might be something around, say, patients that are switching between therapies or patients that were therapy – treatment-naive, so they were on either no therapy or just started on therapy as part of that cohort. So, that was where a lot more of our work tended to occur is looking at sort of that patient – the end-to-end patient journey when it came to diagnosis, treatment, et cetera. And, again, that's really the data that we have, right? So, generally speaking, it's going to be diagnosis. It's going to be, like I said, age, gender, provider, provider specialty, relatively high-level features like that.
Yes, that's something that we did. Part of our models was looking at, you know, and specifically related, there's a subset of comorbidities that are of interest in the HIV space that, you know, can either be contraindicated or may be more indicative of a side effect that's occurring in a particular patient cohort that's of interest to our marketing teams. And the other piece we also look at, too, is like drug-to-drug interaction. You know, there's certain drugs that are commonly interactive with a lot of the medications in this space, so we often pull that in as well.
Presenting insights to the business
It was, how do you present your insights to the business? And they added, the last mile is oftentimes where things fall apart.
How do we present our – well, I guess it's going to be dependent on the specific scenario, right? You know, I personally am a big fan of, you know, the idea of data storytelling, right? And sometimes that can be a challenge depending on who the different people are that are in a particular project that are part of that conversation. You know, I think there's certain ways that are really good to present data, but you also don't want to get bogged down in the details, right? A lot of your non-data-related stakeholders, your executive-level stakeholders, you know, they have a thousand emails waiting for them, a packed calendar. You know, generally speaking, they want the highlights, and, you know, so I find it very helpful to get that out of the way up front. Tell them the so what. Get them interested. Present them, you know, essentially the minimum amount of data that you need to to get your point across and then move on, right?
It can be – I think a lot of us instinctively want to just present all the hard work we've been doing, right? Here's what we've been doing the last three months, six months, whatever. But as a result, you wind up just overloading the stakeholder with information that isn't of use for them or is too far down into the weeds of the details for them, and you wind up sort of clouding your message.
That's what I was going to say, executive summary, right? Load it up front. Get them interested. Don't be afraid to put stuff into an appendix, right? Here's all the charts and graphs and detail that we've worked on. Move it into the appendix. Provide it as a pre-read or a follow-up. You know, put your executive summary up front. Always some of your most important, you know, charts or graphs or whatever that you need to help, you know, back up what you're saying. But I find it's always helpful to get that executive summary up front. Get it out there. You know, here's what we found. Here's, you know, what we recommend or, you know, whatever the situation is. And, you know, again, whet their appetite, you know, if they want more info. And that's where you have to kind of know your audience, right?
You may have, you know, I've worked for VPs that were former engineers. And they'll be sitting there with their calculator, double-checking your math. And people that are more, you know, sales-oriented, they just want that quick elevator pitch. And, you know, their attention is distracted. So, you know, really it does help to know your audience, to know what's going to be appealing for them and what they're going to be looking for. Obviously, that comes with time, too, with working with a lot of the same stakeholders over and over. Just being able to identify their specific personality or needs.
I was working on a Quarto doc this morning to share with our executive team. And now I'm thinking, I need to go back and ask myself, so what, for the very top line of it.
Yeah. It's tough sometimes, right? I mean, like I said, you put a lot of time and energy and heart into, you know, developing some of these things. And the last thing anybody wants to do is just put that into an appendix or delete that slide or chart or whatever. But, you know, if you take a step back and realize, is this really adding anything to my story? Yeah. And sometimes you're not going to need that appendix at all. They're not going to care. But if they do care and they do ask about it, you sure better have it, right?
Building confidence with incomplete data
We have this problem constantly of trying to tell stories with claims data and are frequently or often met with the response of, well, we know this data is incomplete. So how do we trust what you're really telling us? And that can, you know, the room full of engineers like doing their own math, they look up and they go like, well, where's the other 15 percent? So I wonder if anything from your experience has been particularly successful in giving confidence in the face of uncertainty while acknowledging that your data is incomplete or that your data does have flaws. What's helped your team to be successful there?
That is a valid challenge that we constantly deal with. I think the things that we've found to be successful is a lot of times we'll do desk research on top of doing our data analysis to essentially validate some of our assumptions. As long as we're in a reasonable ballpark, so even if it's something as simple as what's the number of patients that are on a specific treatment therapy? If we do some desk research and see that the CDC says that there's this many patients that have that are on that therapy or that have that diagnosis and it's reasonably close, then we will usually supply that as sort of a backup or a supporting piece of information. And usually we find that to be helpful.
And again, we'll use other sources too, like we'll use sales data. Again, if we see that at least our composition of, say, facility types, for example, is similar for sales for a particular product and then the patients on that particular product, then again, we know that the totals may not be exactly the same, but at least we could say, look, we're probably getting a pretty good representative sample.
And acknowledging that, hey, we know this is imperfect, but we're going to try and project it as informed as we can. And we'll make sure that we don't accidentally over or under inflate something without calling it out.
Career transitions and lateral moves
So I'm trying to actually jump into a role for data science, although I want to jump into something different. I want to lean more towards financial analysis. So I wanted to ask if you can please give us a history about your path that helped you prepare for this role, to execute it so well. What did you do? What could you have done differently if you were supposed to maybe get a time machine and go back to your past self? What tools do you acknowledge that are going to be best then that would have helped you improve your work even now?
I appreciate the question. You know, I think that for me, I've always found probably the thing that I've done, and I would go back and tell my younger self, definitely keep doing this. I like to think of a can't as a strong word. Never think of I can't do that. I don't have that. I don't know how to do that. Figure it out. If you are given a problem to solve and you don't know how to solve it, go figure it out. Learn the task that you need to learn. Find the people that are going to help you solve it or are going to teach you how to do it.
But really, the last resort is saying no, so really taking no and turning it into, okay, there's something I have to do in order to accomplish this task or this problem or whatever it is, and I'm going to go figure out what that thing is or what that barrier is and overcome it. So really taking that perspective of don't let anything stand in your way of accomplishing what you need to. And I think that really is something I found to be helpful, and I would, again, I would go tell my younger self, don't ever not do that.
Obviously, there's a number of different, I don't know if I can pinpoint any one specific project that prepared me for it. You know, I think it was, you know, a combination of just having had the opportunity to lead projects that were in a specific space. So, like I said, you know, earlier, you know, I started out working on a lot of projects that were process improvement, right, so Six Sigma, Lean, Kaizen implementations, et cetera, found that I enjoyed that. You know, so I guess that's probably part of the takeaway is, you know, don't be afraid to work on different projects in different areas and figure out what it is you enjoy doing. And then from there, you know, realizing, hey, I like doing this. I'm going to go do more of this.
And then started, you know, looking for projects and then eventually roles that were more targeted in that space. You know, I've never, I've often found that I'm domain agnostic. So, if you were to look at my resume or my LinkedIn, you'd see that, like I said before, I've gone from lab operations to health insurance operations to, you know, supply chain, now, you know, marketing, data science to back to continuous improvement, but in clinical trials. Right, like I worked across a lot of different spaces just because, you know, I'm willing to and I enjoy really flexing across those different vertical, you know, it's more of a how I can apply my specific skill set or my interest in that specific space and figure out, you know, okay, how do I use this muscle or this, you know, how do I take this hammer and start looking for that nail that I'm going to hit?
This is great. Dan, actually, I wanted to hop in and ask you, because I know that you had mentioned before, not for anybody here, but Dan has mentioned before a book called up is not the only way. And you have a great perspective on lateral career moves, sort of, instead of just focusing on up, up, up always. I was wondering if you could share a little bit about that perspective, because it's sort of on this topic here, right? Of, like, what has prepared you for this really interesting career moving into a different area?
Yeah, no, it's spot on, Libby. I mean, lateral movement is good. And it's not a bad thing. I don't think some people maybe have this conception of I have to move up, right? I have to move into my boss's role when they're done with it and their boss's role when they're done with it, etc. And realizing that, especially in larger organizations, or even across different organizations, there's nothing wrong with taking a lateral move. Sometimes you might even decide to take a step down if it's going to give you the right skill set.
You know, so I think really thinking about your skill set, where you have gaps, or where you want to spend more time or learn more, you know, let that drive your decisions as far as roles, as opposed to just always saying, okay, now I'm a manager, I need to go become an associate director or director or whatever. And now I'm a director, I need to be a vice president, you know, like, you find a lot of people that get that mentality tend to chase title. And I don't know about you, but a title is not going to get me out of bed in the morning, right? I want to enjoy what I'm doing. I want to be excited about what I'm doing. I don't want to just wake up and say, okay, I got that title I've been shooting for, and now I'm going to shoot for the next one. You know, that to me is not very motivating.
And I don't know about you, but a title is not going to get me out of bed in the morning, right? I want to enjoy what I'm doing. I want to be excited about what I'm doing.
Are you intentional, Dan, about like setting aside time to think about that for your own career?
Probably not as intentional as I should be. You know, it's something I just, I, I find I often have that conversation with myself as I'm preparing, like, for mentoring conversations, you know, I have a few folks that I've mentored in current and prior roles. And I find that that actually helps me because as I'm preparing for those, and, and just whether it's a direct report that I'm coaching, you know, it helps me a lot. Kind of reinforce some of that thinking for yourself as you're either talking through that or preparing for those conversations.
I was just going to say 1 thing that to that point, you know, that I found useful in the past 2 is, you know, I've had a couple of a couple of companies where I've used a career blueprint. Right? It sounds a little hokey, but to be able to sit down and say, here's my strengths. Here's my gaps. Here's what my, my manager thinks. Here's the feedback that I think my manager would identify for me, my peers, et cetera. And then helping just kind of use that to say, okay, what do I need to do? Right? Where do I need to spend my time and energy? From a learning perspective, do I need to go find a mentor in a specific space? Because I know nothing about it, but I want to work in that space, you know, whatever using that to really kind of. Figure out what your roadmap looks like for the next couple of years or so.
Dashboards, Shiny, and internal tooling
Dan, I was curious. We're talking a little bit about communicating insights. I was wondering, does your team host, like, is it dashboards? Do you get to create Shiny apps or what are the kinds of insights that you share?
So, Rachel, to your question, we do a lot of power apps, power BI related dashboards. You know, Merck's, like most large companies, is pretty invested in the Office 365 suite. I've done a few Shiny apps internally. You know, one of the challenges there is that oftentimes I'm on an island doing that. So it becomes a little difficult to have, you know, infrastructure around you to help support that. A great example was in my last company, I developed a number of Shiny apps that, you know, there was nobody else that developed in Shiny. Right. So if I took a day off and something broke, my phone wouldn't work. Right. So we didn't necessarily have a lot of folks that were doing that kind of work.
And even in my last role, we had a similar experience, although there we used it more for prototyping. So we built, you know, I built something quickly, prototype it, say, hey, this is great. Let's hand it off to our data visualization teams that they have some inspiration for the power BI app or dashboard that they're going to develop.
Thank you for bringing that up, too, about sometimes feeling like maybe you're the only person using a tool as well, because I've seen that a lot with huge organizations where there's like pockets of users, pockets of users. data scientists that don't get to really talk to each other as much. And what is the internal community look like? Do you have opportunities to share different use cases with each other?
Usually it's within different business units. We do have like a data science. I think the core center of excellence within Merck that, you know, it's very diverse. It's very, I don't want to say high level, but there's certainly a lot of different people with a lot of different topics. So it doesn't often get too deep into the into the tech stacks and the nitty gritty, if you will.
You know, where I found that there is some, you know, we like, for example, my last role within that, that it was called human health, digital data and analytics. It was about 600 people that are focused on supporting marketing. We had a number of data science teams. We have a pretty good internal structure for where they resist the Microsoft team space that we could all every self or somebody. You know, we're paying in there. Hey, anybody ever done? This is similar to, I think it was Alan's question about survival analysis. Really? Somebody might post anybody ever done survival analysis with Python. I'm running into this problem, you know, and being able to sort of leverage that.
You know, we also sometimes because we when I get I am. I get the sense this is common across a lot of pharma companies. We use a lot of contractors. So oftentimes it's our contractors choice on, you know, how they're approaching a lot of these projects and stack and whatnot, you know, and, you know, so it's certainly it's a matter of trying to balance. What is they like? Yes, I could go to a contract and say, I want you to do everything in R. But if nobody in that contracting organization uses R, you know, at that point, I'm basically just cutting off my nose to spray my face. So it is a matter of trying to balance that to what's what's available internally, what's available with our resources from our vendors.
A lot of times, especially when you're dealing with marketing teams or executive teams, they're very used to seeing Power BI dashboards and anything that doesn't look like a Power BI dashboard. You know, makes their head explode. So it's certainly trying to balance all those different components when you're trying to decide how what, what stack are we going to use? How are you going to approach this problem from a technical perspective?
But Dan, I wanted to ask you, you're moving into a new role. Congratulations again. What are you most excited about in the switch in being able to like shift your perspective in a different direction or getting the chance to what do you think?
I think what excites me, you know, I enjoy leading people. I enjoy, you know, leading a team and motivating them and trying to figure out what makes them tick and helping to develop them. That's not something I've been able to do in my most recent role. I have in the past. This was an opportunity for me. to get back to using more of that CI or, you know, continuous improvement process improvement skill set, which, you know, again, wasn't a core skill set of my last role. So sort of, you know, being able to use that again was exciting for me.
And then, like I said before, it's a new space. You know, I I've often said I'm not the one you want pushing the button on the assembly line all day long because I'll just go out of my mind. You know, I want to I do want to work in different areas and learn new things and meet new people. And so to me, that's a that's an exciting part about any role, especially a role that's in a new a new area. It's an opportunity to learn processes. I didn't even know existed or, you know, learn new things.
I got distracted in the chat for a second here, but I see Devon was asking about building out proof of concepts and just some any ideas for speedy development and proof of concept. To support adoption of Shiny. And so I was just quickly sharing the new Shiny Assistant. It's really fun to play around with if anybody wants to check it out.
Setting scope and realistic timelines
Sure. I think that. So, realistic is probably the important word there. You know, I think that a part of that's going to also be just based on what you've done for that stakeholder, right? If you're constantly. Telling them this is going to take 3 months and it always takes 6. Well, then it's going to be really hard for you to pitch them a specific timeframe, no matter how realistic it is. I think it's partially knowing and building in either redundant time for your team. Being realistic with yourself about this, here's how long this is really going to take us. Let's not over promise. And then being being up front with your stakeholders. Here's how long this is going to take. Right? Don't be afraid to tell them it's going to do what it's really going to take.
Let them either push you to move it faster because it's a high priority project and that's going to change how you allocate your resources. Or, you know, it may change how we're not going to work on this project right now, because we, we need it's going to take too long. Maybe we'll engage a contractor for that particular project or a consultant firm or something. And we're going to focus your resources on something else. You know, so it's definitely going to change those sorts of, but I think the key is to just really be honest with yourself. You know, maybe if you've done similar projects in the past, and, you know, you either work with that data set or not. I mean, all that it's all those variables are going to impact how long something's going to take, right? There's a brand new data set. You're working with a new set of contractors you've never worked with before, and they might be a new topic area for you. That's going to take a lot longer than if you're building on to a project that you just finished with the same people and data and whatnot.
Career advice: selling yourself
So I think it's being able to sell yourself. You do great work, but really spending time connecting that work to the people that you ultimately want to hire you or moving you into that next role. And it's a lot that goes into that. We talked about networking. We talked about willingness to learn, et cetera. But really being able to pitch yourself. Here's the great work I've done. Here's how it's added value. And being able to convey that in a way that it's easily heard and digested by the people that you're connecting with, I think, is probably one of the most important things. And it's tough, especially for people like us in the data world. We may not feel comfortable talking about ourselves and selling ourselves on a regular basis. Sometimes it takes some conscious effort to learn that skill set or to be comfortable doing that.
Practice. I mean, it's like anything else, right? The more you do it, take an interview that you maybe you're in love with the job or the company just to give you some practice. If you're internal to a company, you'll be willing to take jobs and interviews that maybe you don't feel like is a great fit. But, you know, it's a good opportunity for you to practice that. Right. The more you do it, like anything else, the more comfortable you're going to get at it, the better you're going to get at it. The more you'll be able to talk about work you've done, projects you've done without necessarily stumbling over it or to refine some of that, too. You may take some takeaways from one interview. Like when I said that, they all made a funny face. Maybe I don't say that the next time, you know, again, practice.
And I wanted to add, like, let your friends hype you up. I feel like writing your own resume is so difficult. But if you give a description of what you did in a job to four of your data friends and say, hey, can you guys describe this for me? They will come back with a much more glowing version of what you did than what you wrote for yourself. So, yeah, we all tend to downplay our own our own accomplishments. We tend to think, oh, that's not that important or that's unimpactful. But then when you tell somebody else, like, well, that's really cool.
I really like that that point about like after you have an interview, like actually writing down like, oh, when I said this, they reacted this way and taking that and improving each time. It's almost like like a postgame meeting with yourself. And yeah, and I think that's also helpful for just meetings within your organization, too, or like presentations, too, so that you can go back and look at that.
Yeah, and Julia said, have a brag sheet, like, every time something cool happens, or you've done something great, like, keep a document of it. I'm terrible at that, but it's a good thing. Yeah, I use my LinkedIn for that every time I, you know, and I'll use that to write my self evaluations at the end of the year for, you know, whatever company I'm working on, you know, and then you can use that to sort of create your resume. You're not going to put every bullet point from your LinkedIn, pick up, pick the ones that are that are of value for a particular role or job. Right.
Just like that, we are at the top of the hour, but thank you all so much for taking the time to join us today. And thank you so much, Dan, for sharing your experiences with us. It's always extra fun when it's somebody who's been an attendee of the Data Science Hangout and gets to join us as the featured leader, too. I really appreciate it. Thanks a lot for having me, guys. Thank you all. Have a great rest of the day, everybody.
