Natalie O'Shea @ BetterUp | Focus on relationships first | Data Science Hangout

Transcript#

This transcript was generated automatically and may contain errors.

Welcome to the Data Science Hangout. So nice to see you all. Hope everybody's having a great week. Beautiful here in Boston today. I think it's about 70 degrees. But I'm Rachel Dempsey. I lead our pro community at Posit. And the Data Science Hangout is our open space to chat about data science leadership, questions you're facing and getting to hear what's going on in the world of data across different industries. And so it happens every Thursday, pretty much every single Thursday, unless it's a holiday. At the same time, same place. So if you're watching this recording at some point later, on YouTube, you can add it to your calendar details below. But every week we feature a different data science leader as my co host to help lead our discussion and answer questions from you all. So together, we're all dedicated to making this a welcoming environment for everyone. We love hearing from everybody, no matter your level of experience or area of work.

So it is totally okay to just listen in if you want. But there's also three ways you can jump in and ask questions or provide your own perspective on certain topics. So you can jump in by raising your hand on Zoom. You can put questions in the Zoom chat and just put a little star next to it if you want me to read it out instead. And then we also have a Slido link where you can ask questions anonymously. And I think Curtis, you can grab that Slido link and share it in the chat. But I'm so excited to have Natalie joining us here today. Natalie O'Shea is an analytics consultant at BetterUp. And Natalie, I'd love to start with having you introduce yourself, introducing yourself and maybe share a little bit about your work and something you like to do outside of work too.

Sure. Yeah. So as Rachel said, I'm Natalie. Yeah, I'm an analytics consultant at BetterUp. And a lot of the work that I'm doing right now is focused actually on building a flexible, scalable reporting system in Shiny . And I'm like fresh on that right now because I just finished recording my POSIT conference talk. So hopefully maybe going to share some of those learnings there. Well, I could go on and on. I have a very long and winding road to where I ended up. So lots of diversions and different experiences. But yeah, outside of work, I've got my drum kit here. I have not been practicing as much as I should. But that's kind of a hobby of mine, trying to learn how to drum as an adult. I never learned a musical instrument when I was growing up. And then I saw one of my favorite bands at a jazz club. And I was like, alright, I need to learn to drum. So I'm a very bad drummer.

I will also say my birthday was yesterday or the day before. Now I'm forgetting, but happy birthday. Oh, thank you. I'm bringing it up because a new hobby, though not quite a hobby, but I got to meet beluga whales at the Shedd Aquarium. And that was pretty, pretty awesome. So now I'm like, wanting to become a whale trainer as well on the side. We'll see about that. I love it. That's awesome. Well, you said your favorite band. Who's your favorite band? It's a band called Lettuce. Yeah, they're like a jazz, funk, hip hop band. They're very fun.

Use cases and the Shiny reporting system

So while we wait for questions to come in from everyone, I thought it'd be helpful to kind of put ourselves in the mindset of some of the work that you do at BetterUp. Would you be able to share maybe a few use or a use case that comes to mind for your data team?

Yeah. So the whole kind of approach I'm building right now, you know, it's a big, I'm a consultant, though, I'm not really directly consulting as much right now. I'm kind of supporting a lot of our consultants. But as consultants, they need to be able to kind of customize reports and presentations for partners. So I built out a system within Shiny to actually populate slide decks with metrics and visualizations. And I can go on and on about the reasons why I took that approach. But a big reason why I wanted to have all of that kind of populate in Google slide decks was so that, you know, we can customize the look and feel and the story of any given company's data specifically tailored to them. And so yeah, I can go on and on about like why I chose that approach over something like parameterized reporting, which I'm also a big fan of. But yeah, that's that's kind of a big, big project of mine right now.

And then in addition to that, we know each other because I've been leading a pretty major procurement effort. And we're in the final stages now of like installing Posit software. So we're really excited about that. But I learned a lot about what it takes to kind of build a business case for data science tooling at your organization, and getting buy in across the org. And it's, you know, it's a pretty major lift to get get something like that off the ground.

Building a business case

What was one of the biggest lessons learned in building business case?

I would say, like one of the biggest lessons learned in building the business case was have kind of a flagship project that ties to direct business value. So the project that I'm doing really helps automate a lot of our processes and makes it a lot faster and easier and more streamlined to populate these decks with with different data insights. And so that was enough of a driver kind of showcasing the additional flexibility that open source programming tools offer us over a more business intelligence tool. That was really a big driver and what led us to get get this this software. So I'd say having kind of a project that you can directly tie to business value. That's like a big, big learning from it.

And then I'd say another learning from it, I would never have been able to get this pushed through if I didn't have a supportive manager who really walked me through the whole process and helped me navigate a lot of the organizational hierarchy to get something like this off the ground. So kind of finding and developing your community of allies that are also interested in the same thing as you, you're, you're definitely not going to be able to do this alone.

So kind of finding and developing your community of allies that are also interested in the same thing as you, you're, you're definitely not going to be able to do this alone.

I often find that it's not the most technical person in the room that has the best ideas. It's the person with, like, the most direct experience with the problem that you're trying to solve.

Tools, autonomy, and expanding Posit adoption

Yeah, so I think, you know, we use, like, Looker a lot internally as our business intelligence tool, so I feel like that's kind of where, like, a lot of our efforts, right, as an analytics team have been, like, devoted to that, but, you know, as great as Looker is in its many ways, like, there are always questions that you're not going to be able to answer with a business intelligence tool, so we've always had people working in R and Python and doing their own analysis. So, you know, I think a big part of, like, how we sold that in terms of, like, the autonomous side of things is people are working internally, or, like, on their local machines and things like that, and that's obviously not analytics best practice, so we want to move to a more cloud computing kind of approach, and that also, in terms of, like, making the business case for things like that, that helps shore up our digital, like, security, so making the case that we can have a one-stop shop that supports both R and Python users in a secure cloud environment where they get to use the tools that they like, you're not, you know, forcing Python users to use RStudio , you're not forcing RStudio users to use VS Code, like, everyone gets their cake and gets to eat it, too.

I think it remains to be seen, right? We're kind of have a small, like, developer license group initially because we've gone, we need to prove that value first, so that's kind of a big part of that, so I think once people start to see us producing value and centralizing on this tool, that will help us make the case to expand the developer community on Posit. I'm also, you know, we're in the early stages of developing, like, there's the app that I'm working on, but a lot of the logic that exists in that app, we're trying to move into, because it's pulling directly from our database and doing some standard analyses, we're trying to move that into an internal package, so I think once there's, like, aligning on the tools, but then there's also aligning on the code and the workflows, so I think internal package development is a great inroad to not only proving the tools value, but also aligning people on how we work with data.

What's most exciting in the year ahead

Well, I wonder if she's listening to this call, but we recently, so, one of my, like, my best work friend from a different part of the organization recently transferred onto our team so that we could work more closely together and we are building out this internal data processing package and kind of trying to develop some onboarding materials for Posit, so I feel a little, like, imposter syndrome and being, like, we're successful with Posit already because we're, like, just at the beginning stages and have so much more to learn, so I'm most excited about, like, really working with my friend to, like, build out the onboarding for all of this to build some shared workflows and then to kind of socialize that more broadly in our organization. I think that will clearly demonstrate the value of, like, why we invested in these tools, so it gets me excited to think about people actually, like, using the apps we're developing, people being able to, like, easily access all of the different reports.

Like, one of the first projects we're planning on doing once we get all of this, like, really up and running and all the, like, deployment issues kind of, like, ironed out is building a central landing page, like, from the Posit, like, curating your data science content or content with what's the connect widgets package, which I'm so excited. I get really excited about getting people to be able to share their work more broadly, more seamlessly, so there's so many, like, really interesting reports and things that people are doing at our organization that often don't have the kind of reach and impact that they could if we just had a tool so that they could easily, like, deploy it and just say, like, here's a URL that shows all of the reports that our team has done on this specific topic.

GitHub Actions and continuous integration

Yeah, I feel like I'm just, like, beating the drum of the Rhino framework, but I didn't. I'm still fairly new to continuous integration. I've done a little bit of, like, CICD stuff with Power BI before this, but this is my first time deploying a Shiny app with continuous integration, and I did not develop it from the ground up. That was one of, I really love the Rhino package because it forces you into some best practices, and that's one of the things that it forces you into. Since deploying the app with that framework, I have learned a little bit more about GitHub Actions and have modified that template.

Yeah, so, like, for instance, the framework, the way the GitHub Action is set up, it runs a series of different tests on every push, and I've realized, oh, my God, like, this is just, like, every time I push a change to the app, it's running these continuous integration tests, and it's just, like, overwhelming, so I realized, oh, I just need to change the YAML header, and I can make it so that it's only on pull requests that it runs these checks, so things like that, so that was kind of, like, a design thing that was built into the Rhino package that forced me to learn something that I should have been doing the whole time. But, you know, I'm in a weird position now where I'm, like, starting to become, like, more recognized as, like, a Shiny developer. My organization people are, like, coming to me for advice, and I always tell them, like, I'm giving you this advice because I've made this mistake 10 billion times before, and it's painful, so when I'm telling you, like, it's worth learning Shiny modules, it's because I've built 10 billion Shiny Frankenstein apps that, like, quickly grow in complexity and then are horrible to debug and all of these things.

So, yeah, that's a long-winded explanation, but, again, plugging the Rhino framework for forcing me to learn about GitHub Actions, and then the things that I didn't like about the, like, default settings, that helped me learn about GitHub Actions, because then I needed to learn how to, like, modify those settings, so I'm running linters, you know, yeah, again, like, setting up some deployment. I don't even fully understand how it's testing the runs on Linux and R and everything, or Linux and Mac and all of these different setups, but to the vein of, like, building relationships, the fact that I had that in my application made the DataOps team take me more seriously, and they were more willing to support my efforts to get this tooling and to get it built out, because they saw, oh, you're not just, like, ragtag Shiny apps that, like, can never go anywhere, you're, like, building in more robust ways, and, therefore, I'm willing to put in the time and effort to support you. So I'm the big proponent of, like, meet your engineers halfway, and you'll have a lot more success, so where and when possible, you know, really, really try and demonstrate some robust engineering practices.

Focus on relationships first

I've been there. I am there. Yeah, it's, I would say, like, again, the anthropologist in me is coming out, but, like, focus on relationships first, because inevitably, like, what you define as a best practice on first case, like, you're not going to be doing that best practice, like, six months, not always, right? Like, there's certain things that will stay, and, like, teaching your team to, like, use Git branches and merge into main and, like, those things are going to be pretty stable, but, like, there's other more thorny questions that are really hard to build best practices around. So, for example, in our team, we have a lot, we support a lot of different organizations, right, with different data analyses, and, like, how do we, like, what size of repo, do we put everything into one big GitHub repo, or do we make a repo for every organization, for every project? Like, it's always in development, and it's constantly iterating. So, being comfortable with that, I think, is a key part of developing best practices, because it's never going to be just, like, a set it and forget it best practice. It's going to be constantly in relationship and, you know, building together those best practices.

Focus on relationships first, because inevitably, like, what you define as a best practice on first case, like, you're not going to be doing that best practice, like, six months. It's never going to be just, like, a set it and forget it best practice. It's going to be constantly in relationship and, you know, building together those best practices.

I find, like, we run in our users' office hours every two weeks, and I often don't have an agenda or anything, and it's a great way to just, like, first and foremost build community, but that's also where people come to say, like, I'm really struggling with this, like, how do you approach this? And then now we're starting to build those best practices, and as we build out the whole kind of posit onboarding infrastructure, our hope is that we, and, like, internal packages, like, I think building that into, like, vignettes, right, or, like, confluence document, I haven't tried this out yet, but I did see that Quarto is supporting, like, confluence documentation, which is awesome, because our team uses confluence pretty significantly, but I, God, I hate anything that's not, like, programmatic. So, I want to have it as a script in R, and, like, I can automate, or, like, I can get in R and, like, alter that script, but then, like, send those updates. So, yeah, maybe not the best answer, but just be comfortable with iterating and, like, make sure that you're always communicating with each other and building strong relationships.