Data Science Hangout | Jay Sewell, Harry Rosen | Prioritizing work with a centralized data team

Welcome to the Data Science Hangout! If you're joining for the first time, it's nice to meet you. I'm Rachel. The Data Science Hangout is an open space for the whole data science community to connect and chat about data science leadership, questions you're facing, and what's really going on in the world of data science. So the sessions are all recorded and shared to YouTube, as well as the Data Science Hangout site. You can always go back and rewatch them and find helpful resources there. I try to take some of the suggestions and links in the chat and put them up with the recordings as well. But we also have a LinkedIn group for the Hangout too, if you ever want to continue a certain discussion.

But yesterday, Marcos had an idea of starting a show and tell, like our show and share thread in there every week. So if a side project you're working on or a cool tutorial or article you found. So maybe we can start those conversations going in that group too. Together at the Hangouts, we're all dedicated to creating a welcoming environment for everybody. So we love when everyone can participate and we can hear from all of you. So there's three ways you can ask questions here. You can jump in by raising your hand on Zoom. You could put questions in the Zoom chat and just put a little star next to it if you want me to read it. And I can, or I could call on you to introduce yourself and share some context. And then we also have a Slido link where you can ask questions anonymously too.

Just like to reiterate, we love to hear from everybody. So no matter your level of experience or the area or industry that you work in as well. But with all that, I'm so excited to be joined by my co-host for today, Jay Sewell, Director of Analytics at Harry Rosen. And Jay, I'd love to just kick it off by having you introduce yourself and maybe telling us a little bit about your role, the company, and maybe also something you like to do in your free time outside of work too.

Jay's background and Harry Rosen

Sure. So like Rachel said, I'm Jay Sewell. I lead the analytics and data science practice for Harry Rosen. If you haven't heard of us, we're a kind of luxury men's retailer based out of Canada. So, you know, the company has been in business for 60, oh God, I should know this, 68 years. And, you know, we've had really an analytics practice for the last 12 or so. I was one of the first to kind of join as a junior analyst way back when, about 10 and a half years ago. At that point, we were really just, you know, kind of slinging SQL queries for the marketing department and things like that. It was kind of, you know, what you'd expect at a retail company in 2012 or whatever.

And one of the things I noticed right off the bat was, you know, we had this amazing data set. And we were really, really using it. We were kind of sharing it to some of the salespeople in the stores and things like that. But we weren't really like getting many insights from it. It wasn't being leveraged like it could be. So I kind of took it upon myself to show the business a little bit of what data science could do. And so through that, I've kind of raised through the ranks and now I kind of lead the team. And yeah, I mean, it's, we're an R shop, which is one of the reasons I'm kind of doing this. I love the language. I love the platform and the community. And yeah, so we kind of have our hands in everything within the business and we use R to power almost all of it.

And what was the other thing? Oh, something I do in my spare time. I love to cook. I'm a bit of a gourmand. So when I'm not, you know, writing code or whatever, I'm typically cooking something. I actually moved out to the country. We're surrounded by farms. There's such good food around. So it's been amazing. Yeah. And that's what I love to do.

Building a data-driven culture

That's great. Thanks, Jay. I know when we were chatting a little bit earlier, you talked a bit about how you're thinking a lot about building a data-driven culture and what that really means. I'd love to hear how you're doing that.

I mean, how am I doing it? Well, so that's, you know, like I mentioned, you know, Harry Rosen's a pretty longstanding company. We have almost 70 years in the market, you know, for a lot of that time, like I said, we weren't really using data the way we probably could. Right. So part of growing a data science team is also growing a company that wants to use that data science team to its fullest. And to me, that's kind of, you know, a really good starting point for a definition of a data-driven company.

But, you know, so the challenge we're sort of facing is like, how do we teach people the skills they need to consume data? And at the same time, how do we produce products, you know, however that kind of manifests itself so that they can learn and grow with that? And like, that's been our approach. I'd love to hear opinions from participants in the chat about like how they would, you know, conceptualize what a data-driven company is. At the front of it, within the last few years, we've kind of, you know, placed data-driven culture as part of our, one of our core values, right? We call it measure twice, cut once, really kind of encapsulates part of that thinking. But you can't just say, you know, we're going to do this. You actually have to do it. And you actually have to sort of build not only, you know, the knowledge, understanding, the data literacy, and the drive to use data, but then also, you know, the products, the data sets, the backend, everything that supports it.

So yeah, I mean, how we've been doing it is kind of inching forward slowly, but surely. So we do, you know, some lunch and learns and things like that with people in the company. We try to, you know, build products really iteratively. We took agile very seriously in the last couple of years to work really closely with people we're building products for, to try to, you know, deeply understand how they're approaching problems and how we could help them use data to approach those problems better. And we found that's been a positive kind of change in the way we've approached things. But yeah, it's an ongoing challenge, I think, and one that, you know, I don't think there's a specific formula to solve, but very happy to kind of hear suggestions and thoughts from participants in here about what they think.

Sure. I always seem to have thoughts, but yes, I have experienced this quite a bit. I feel in my mind, if everybody has access to the information, a lot of ideas get generated, how to enable it for the whole organization. Many times we run into roadblocks of having access to particular sorts of information, but I feel if all the departments could have equal access, I think that would create like data-driven insights for the whole company.

Yeah, I mean, that's a great point. And actually, so one of the approaches we've sort of taken to that, and, you know, this is, you know, a long time ago, somebody convinced us to buy into Tableau. We've never really built much dashboarding on it, but what we have done is created data sets, you know, kind of, and made them available to some people in various parts of the organization, but basically whoever wants it, and we'll sort of curate a data set and kind of make it available so that somebody from that team who has questions and is close to the problems they're working on also has sort of wide and unfettered access to some data about it to try to, you know, kind of short the game of telephone between the question and the answer, so to speak. So, I mean, that's been an approach, and I think it's actually been pretty successful, but it's hard to scale, and it's hard to find pockets of the business and convince them to want and need that because there's some training and whatever involved, too.

Starting conversations with business users

And Jay, how did you first start those conversations with the business users? I know you said you had, like, the lunch and learns, but is that across the whole company?

I mean, probably the first real attempt at starting to build this. We have a kind of senior leadership group within the organization, and kind of the part of that was, or the point of that, sorry, was to, you know, be able to share knowledge and, you know, kind of leadership wisdom and things like that across the company. So, once or twice a year, we'd pull in leaders from all over the country. We'd do a presentation. I got a chance to kind of get up and, you know, like, I think I titled my talk, The Seven Habits of Highly Effective Data Analysts, or something contrived like that, and I tried to kind of convince everybody that, like, no matter what their role, in some way, shape, or form, they're touching data, they're learning from it, and they're using it, and so they should learn some habits of what good data analysts do. So, that actually got a little bit of traction going, in terms of people being a little bit more open to talk to our team.

I think we were sort of seen as, you know, the pretentious or pedantic SOP team that did all sorts of weird algorithms and whatever. So, that kind of opened the doors, but really, it's been a lot of frontline, me approaching a team, trying to understand what they do, what their business problems and issues are, and what challenges they're facing, and get them open to the idea that these aren't insurmountable, and sometimes there's data sitting right there to help them at least, you know, come up with answers quicker, easier, faster, better, whatever it is. So, yeah, those conversations are very much, it's more of a pull from my end than it is a push right now, and although, you know, it's starting, that tide is starting to turn a little bit, which is great, but yeah, I've been out there kind of mining for business for our team, if that makes sense.

The Realtime Pulse Shiny app

That's great. Can you give us an example of something that the team works on?

Sure. So, like I said, we kind of service any area that needs it. For a long time, it was mostly the marketing team, just because, you know, from an audience generation targeting point of view, there's a lot of applications there, and we have a lot of good data about our customers, and what they buy, and that sort of thing, but lately, the focus has been more probably on store operations. So, we built recently an app, a mobile app. We call it Realtime Pulse. It basically just came out of a conversation where one of the operations leaders were like, I just need real-time data. I need to get the pulse of the business, and we're just like, all right, you keep using those words, that's what we're calling the app, and it's really just, you know, a way of taking some of the reporting that was really slow, or inconsistent, or, you know, weekly, or something like that, and put it right directly in the hands of the store leadership, so they can pull up and see up to the second, what are the sales in the store? How are the various sales people performing? How are they tracking to their weekly goals, and things like that?

And this has just been an opportunity for us to kind of insert some, and this is all built in Shiny, and this has been an opportunity for us to sort of insert some insights and intelligence into those layers. So, instead of showing them, you know, a big list of numbers, we were kind of trying to find what are the insightful, what are the important figures that we need to look at and pay attention to, so that you can make quick decisions throughout the day. So, that's been probably one of our most impactful apps that we've built, and that's been probably our most widely used, in terms of like, you know, total hours of usage, or whatever. So, that stirred a lot of excitement in the company, just in terms of what we could do for them.

Yeah, I was just thinking what Libby just said in the chat as well. It sounds like your data people sometimes have to be sales people.

A hundred percent, yeah. And we, yeah, getting in their shoes and understanding what they think about from day to day, and it's often not what you'd expect, you know, coming from a math background, and computer science, and things like that. The way you approach a problem is definitely different than the way somebody who's day-to-day is clienteling, dealing with people. So, just trying to cross that barrier is sometimes a big challenge, but part of the fun of it, I think.

Prioritizing work across teams

Andrew said... I was curious how you organize and prioritize the work, especially when there's multiple teams, departments that you're working with, and stakeholders. So, there's not a single list that you're knocking out on, but you still have a single team that you're working with.

Yeah. I mean, prioritizing work is, you know, it's like, what's that joke about the two biggest problems in computer science are cash invalidation and naming things? Well, the third one is, like, prioritizing your work, right? So, you know, everyone thinks their thing is the most important thing. We have tried probably a dozen different ways to try to get agreement across the business on what our team should be building at any time. And what we finally kind of nailed it down to is, you know, we give like a kind of value rating, t-shirt size value rating to something and an effort size value rating to something, put it in a matrix, and then we open it up to our executive and say, tell us which ones you want us to do. And they go, I like this idea. I like that idea. If we have different opinions, we are, we, you know, kind of present an argument. And then we come up with our priority for the quarter.

And then we go on, right? How we get to that value statement is typically a lot of conversation with the team and trying to figure out what their challenge and what their business problem is actually, you know, kind of how connected it is to something like sales or efficiency or things like that. And that's another part that I think like we're trying to get better at. I think we'll always try to get better at. But yeah, I mean, it's definitely, you know, like I said, one of our biggest challenges is picking the right priorities and making sure we can stick to them. Like when, you know, if someone else comes in and says, no, no, no, this thing is more important. We have to stick to our guns and know that like we picked the right thing all along and, and, you know, like have a good argument, have a good, good logic behind that so that, so that we don't get sidetracked or bottlenecked and things like that.

So my question is kind of loaded, but I know for experiences I've had in the past, sometimes it's easy to find a quick solution to a problem at hand, but maybe taking that extra time to pursue something that's a lot more innovative that might have not been done before can have big payoffs in the long run, but it might look a little risky. So I'm just curious for your group, how do you do that? Do your, does your group feel empowered to take those kinds of calculated risks to do something innovative? And how does, how does the leadership feel about that kind of, that tug and pull between getting something done quick versus maybe taking a little time up front to make something better maybe for the future as you solve a problem?

That's a, that's a great question. I mean, I feel, and maybe this is me kind of like with 10 years of elbowing out this kind of space around me to, to, I feel empowered by our leadership that they trust my judgment on that. And typically we will, we will look at a project with two, two kind of pieces of value when we look at it, it's like, this is the value to the business problem and this is the value to future work. Right. So for example, if we're going to, you know, approach a problem like, you know, let's just put a linear model into Plumber and, and fire it off and whatever. And that's, you know, going to get us 80% of the way there, or we can develop a better data set, we can develop, et cetera, et cetera. And we can turn that into a package that we might be able to use down the road. You know, that, that future work value is taken into account, right? So I'll say, you know, we'll spend three weeks instead of one week or two months instead of one month on this in order to be able to use this extensively in other projects.

I, I have gotten a lot of, you know, got a lot of leeway to, to allow our, our team to do that because I think our, our executives sort of see, have seen the payoffs from that before. But that, you know, that's always a challenge, but sometimes you just have to, you just have to, you know, bring in the estimate with that in mind, rather than telling them that you could probably do some half-assed solution in a lot less time because you know what it will bring to your team later. Right. So, yeah, I mean, I guess, you know, that, that's, that's kind of the answer is, is yes, I feel empowered, but also I don't always, I don't always tell them the other, you know, the, I don't always give them the option for the, for the quick solution. If we know we're going to get a lot of value out of the better one.

I don't always give them the option for the, for the quick solution. If we know we're going to get a lot of value out of the better one.

Jay's razor: deciding which reports to keep

Thanks, Jay. I'm not sure how to ask this as a question, but I remember when we were talking maybe a few months ago, you talked about like when you decide to reproduce reports or keep reports and you call it internally, like Jay's razor. And I was curious if you could just talk a little bit about that, because I think it'd be really helpful.

Yeah, yeah, sure. So we kind of have this plan over the next few years to migrate all of our reporting into, you know, the, the, the kind of platform we're building, we call it Misura. It's the Italian word for to measure. We do a lot of made to measure clothing in the company. So it kind of resonates with people and, you know, has a kind of cool double meaning. So, you know, we did an audit. This is probably a few years ago. Yeah. Pre pandemic, we did an audit. I think we had a thousand reports. It was like 900 and something reports sitting out there and the tool where you, the tool that the development team has been using forever. It doesn't track who uses them. So we're sitting there going like, we're not, we're not migrating 900 reports. There's just no way.

So yeah, we kind of developed this, this technique where rather than, you know, migrating report, I sit there and go, okay, you guys use this report. Show me, show me how you make a decision that impacts the business from the data in this report. Right. You know, so a good question I ask is like, okay, so imagine you pulled this up and I went, oh, oh crap. I just found out this data is wrong. And I gave you brand new numbers and you like, you never seen the before. How does your week change? How does your month change? Are you doing something different now that I've shown you new numbers? And if you can't reasonably convince me that your week or your month has changed because the report was wrong, it's a useless report and we should not be looking at it.

So a good question I ask is like, okay, so imagine you pulled this up and I went, oh, oh crap. I just found out this data is wrong. And I gave you brand new numbers and you like, you never seen the before. How does your week change? How does your month change? Are you doing something different now that I've shown you new numbers? And if you can't reasonably convince me that your week or your month has changed because the report was wrong, it's a useless report and we should not be looking at it.

Right. So, you know, trying to get at, you know, plugging information into actions and into decisions and really kind of like stripping down reports that aren't doing that. Like if you're just looking at a report in order to pass on that information to somebody who's passing it on, it's just kind of this game of telephone or whatever it is. It's time to go. Right. So we, we, I use the analogy a lot of like, you know, we're not historians, right. Looking at a report about what happened last week. You can't change it. The sales were what they were. We sold what we did. The customers came in. You can't do anything. Right. So unless you're using that to figure out what you're doing next week. Right. So the analogy I always use is like the weather. Weather report is a report everybody uses. Right. Everyone knows how to use it. Most people use it every day. Right. What does the weather report do? It tells you how to make decisions. Do I need an umbrella? Do I need a sweater? Should I drive or walk to work? It's forward looking. It's a forecast. Who looks up the weather from last Tuesday? Nobody. Who cares? It already happened. And so I'm trying to get people to think about reporting more like the weather report. It should be, if it's not directly telling you what's going to happen, you should be thinking about what do I know about what's going to happen because of this report and how can I make a decision to accommodate that or to take advantage of it? So, yeah, that's kind of the razor when, when people can't answer that question with enough authority. I'm like, yeah, we're killing this one and it's, and it's gone.

I love that. I see Libby, you had a, you said you had a similar way to prioritize reports. Do you want to jump in on that?

Sure. Yeah. Yeah. So our, our org, I was just part of kind of the modernization effort where we were going through and prioritizing things. And there was some prioritization that already existed, at least the logic behind it did. And as we were going through all of these reports, just like pouring through a billion reports that there's only one that was high priority. That was like, you know, top, top level priority. Only a few that were kind of mid-level and everything else was either, like you said, outdated or didn't meet the criteria. And the criteria was kind of like, who looks at it and then what decision are they making with it? And if it's not ELT that's looking at it, it's not executive leadership team that's looking at it, then it's like an automatic bump down kind of, and then if you're not making an actual either strategic or operational decision with it on a daily basis and it's not updated, you know, on a regular, you know, timescale, then yeah, why are you looking at it? And you kind of like already spent so much time just looking at all of these reports that it kind of blows my mind that like, oh, we can spend like four months digging through these 50 to a hundred reports just to find one that somebody actually looks at every day, the data's up to date, and moving forward with less feels like corporate minimalism to me and I really like it. Yeah, it's freeing.

Choosing a reporting platform

Yeah, I imagine that there are many vendors who would like to sell you a reporting system to put all of the things in. I'm curious to hear more about how you, you know, what you were looking for and how you're getting it. You mentioned it's a custom thing, so I imagine it's not just a straight off-the-shelf thing.

Well, yeah, so it's built on RStudio Connect, actually, so that's, you know, that's the vendor, and one of the reasons I'm here today is, you know, just conversations through speaking with RStudio, but yeah, I mean, we've been approached by, I mean, you name it, Tableau, Looker, Power BI, like everyone wants to sell us their solution. My typical kind of question I ask is, you know, like, how well can I version control this? How well can I, like, how flexible is it in terms of, you know, creating, writing to a custom data model? Like, how can I incorporate machine learning? I've never got a good answer on all or even most of those types of questions from most vendors that kind of come to us and try to sell us their solution, and so, you know, I stick to my guns. Like, I love a code-first approach to problem solving. I think it has so many benefits that outweigh the, you know, to me, slightly extra time it usually takes to get a project off the ground, and so far we've had, like, nothing but success kind of building our own, building and managing our own code that I, it's almost like, you know, I kind of know how these conversations are going to end before they begin.

I don't know if that kind of answers your question, but, like, our platform is really just a way of hosting and orchestrating Shiny apps and Plumber APIs and things of that nature. You know, we're sort of always on the lookout for good ways to do that in the back end, and RStudio Connect has been a great way to do that in the back end, but in the front end, like, what those things do, like, the kind of logic layer and presentation layer in that scheme has always been code-first, definitely. You know, if one day we move to Python or whatever, maybe, I don't know, but it was probably still always code-first, and, you know, it will probably still always remain, you know, code we build and code we maintain and code we kind of pour our heart and soul into.

Managing user adoption

Yeah, just how do you manage user adoption, right? So, there's so many new things rolling out, as you said, looking forward reports, like a weather style approach. How do you make sure people are up to date on the latest and the greatest? Are there regular training sessions?

So, yeah, I mean, we're a small team, and it's kind of hard to manage the time it takes to sort of do training sessions, but we're really trying, and I think, like, the more time we put into it, the more value we get out of it. So, it's something I'm trying to steer us to do more of. Great documentation, like, you know, a lot of the applications we build have documentation kind of, like, built into them as, like, a little user guide tab or something like that with what's hoping to be a lot of information, but we also, I mean, and this is something relatively new, like, we monitor the logs of who's using what app, and we can sort of see, like, in RStudio Connect has a connector to Postgres that we leverage a lot of kind of reporting on in Postgres internally to see, like, who is using our apps, how long are they spending on them, that sort of thing.

We're also trying to develop, we're working on a package right now that's going to help us kind of a little bit more fine-grained reporting, so we can see, like, what features of apps are being used by users, and that's hopefully going to help us ask better questions when we go back to them for feedback. So, you know, the feedback mechanism built into the sort of agile process is really helpful, but it's better when we can say, hey, look, we built this thing you guys asked for, and this tab never gets touched. Like, is it because you realize you didn't see, you didn't, like, you thought it would be more useful, or it's not providing the information you thought it would, or what is it, so that we have a bit more focused questions, because right now we have to kind of pull that out of users, and that's not as efficient.

But, yeah, I mean, user adoption is critical, and the hard part is capturing people's attention, and then the other hard part is figuring out what to do when you don't have it. And so, yeah, I guess another one I'll lean on is, like, getting leadership on board with this, so, you know, like, our president and COO is a big proponent of our team. He does a lot of work to convince others that they should care about the reporting that we're giving him and them, and so, like, that's another one that's been a really big help in terms of growing adoption of our products.

Sharing knowledge internally

As your team finds great solutions, develops great apps or cool analytical pipelines, what are efforts that your group takes to make sure that you're sharing that knowledge across and that, you know, people are learning from each other? I don't know if you have, like, internal user group sessions or shared learnings or things like that.

Yeah, so that's a very apropos question. I swear, like, are you spying on us? So, we recently, so we kind of, in 2019, had this idea of, like, starting a center of excellence for analytics, and the pandemic kind of put a pie bash to that for a little while, but we recently kind of took that off the shelf and we're trying to build that up, and part of it is, like, you know, there's other people in the organization who are either power users of our output, or they're doing kind of analytics in their area, or they're, you know, just basically just data-driven people. We want to create a kind of space for them to share knowledge and things. We've actually chosen, and this might sound terrible, and I bet a bunch of people are going to get goosebumps when I say this, we chose JIRA Service Desk as the kind of platform to do this, so we have a place for people to come in and write requests, or ideas, or whatever, and also just see work going through. So, if we're having a release for an app, we have, you know, a ticket for that release that people can kind of watch the progress of, but really for internally, if somebody's doing something, they can put it in the Service Desk and talk to any member of the Analytics Center of Excellence and get some advice.

What data would I use for this? Like, have you guys seen this result? Does this make sense to you? And so on and so forth. You know, that's, we're sort of just in the infancy of that kind of experiment, but like, that's kind of our solution to that, in a sense, is to see if we can create a little kind of shared space for people that are either, you know, analysts by title or analysts by trade, to kind of just, you know, talk about this stuff. I don't know how far-reaching it'll get. It's kind of, again, still brand new, but that's kind of our idea, and having that, you know, that knowledge base start to grow and build in a single place with some searchability and, you know, with confluence, kind of keeping documents and whatever together. I'm hoping we kind of create that, but that's, yeah, that's so far our idea to solve that problem.

Yeah, that's very helpful. Having that central place people can go to is so much better than just typical send that person a message or send them an email that gets lost in the abyss of who knows what. Exactly, yeah, no one can search for it. Somebody new comes on board. How do you find, you know, so yeah, I know JIRA, a lot of people pull their hair out over JIRA, and I've done the same thing many times, but it's kind of like, what's that old Winston Churchill quote? It's like, JIRA's the worst solution for this, except for all the other ones, or whatever.

Fine-grained app usage tracking

Yeah, it was just a selfish question. So, you were talking about being able to look at what features are being used, what tabs are clicking on. I stopped using Connect with my organization right before the, like, Connect API came out, so I'm aware of it, and I was like, oh, this is so cool, but I didn't get to use it from an org side. So, I was wondering if you were, like, building server-side events that you were harvesting, or if this is in the Connect API somewhere, I'm not aware of. I'm just curious.

Yeah, so it's actually separate to the Connect API, but we are putting it in the same physical database. So, the Postgres database that Connect is feeding to, we've created basically, like, an extension database for that, and the reason for that is we're hoping to take advantage of some connections. Like, if we know a user's GUID, then we can use that to say this user did these actions or whatever, and we can connect those things together. Again, this is, we're still sort of an experimental phase, so we're not sure we can do as much of those things as we want, but that was kind of the idea. But really, at its core, this is going to be a front-end package, so a package that we can kind of load into a Shiny app and basically call almost like a logging function, you know, inside ObserveEvents or things like that to say this is happening, this is how the user clicked here, the user did this, and that's basically going to connect to a Plumber API that's going to do the hard work of writing this to the right log or whatever. So, essentially, we're going to be creating just a giant, almost like Google Analytics ripoff for our thing, and I know some people have even, and we consider this, some people even connected Google Analytics to their Shiny apps.

We tried it out, we could never get it to work. Yeah, so look it up. If you can figure out how to get it to work, please let me know. We could never quite follow along, but yeah, so that's the idea. We'll have this Plumber API just listening for any old event from any one of these things, and the trick is we're trying to make it as low overhead as possible so it doesn't slow anything down at all. Yeah, so it's going to be on the developer to choose where to put that in the code and to make sure that we care, like what we care about is being recorded, so yeah. Very cool, yeah. Shiny app developers have to be half data scientists, half like UX designer, and I'm never prepared to be a UX designer, so this part, the like harvesting information about the way people are using it is more intuitive for me than like deciding it to be better usable from the outset.

Managing a small team and looking ahead

Hi, yeah, you just mentioned that you had a smaller team, and I guess how do you manage everyone's timelines and trying to work on one project or multiple projects and deliver that to the people that you need to get it to?

Yeah, I mean, so our team, actually, I'll shameless plug, we're hiring right now. If you're based in Canada, like we're programming in R and Shiny, go to harryrosen.com, look at the careers page, you'll find data product developer as an open position. So, you know, our team is, should be four people, it's three at the moment. It's a tiny team, right? And, you know, so managing people's time, it's kind of hard in the sense that it's a small team, it's easy in the sense that it's a small team. And we're typically going to work on one project at a time, right? So that's how we block it. And we just have, we just take a very agile approach. So, you know, there's a typically a planning sprint that we take on where we're all as a team listening and talking to, you know, somebody that has a problem that we need to solve. And then we're kind of building a backlog, building some sprints, working through it at each at each iteration, we're trying to show people what have we created? Is this helpful? Is this going to help you towards your goal?

So, you know, you know, Jira in the back end with, you know, our user stories and kind of issues and things like that is, is really, I think, you know, the way I manage people's time is, you know, assigning and that sort of thing. But because we work so collaboratively, I don't have, I don't really have the, it's not really a task on my plate to care about what somebody is doing, because I kind of know what they're doing at any given time. There are instances where we kind of split up and do little things if there's no, if there's a lot of maintenance or something that needs to be done. But again, I have a little view in Jira, I can I can stare at and say, you know, why is this sticking or whatever. So that that's kind of, that's kind of how we do it. I'm, I'm kind of excited and scared for the challenge of doing that when we have a few more people on the team, and we have like multiple projects at the go on the go at once, that's going to be a little bit more challenging. But agile is a little bit easier, because the team holds each other accountable for what they're supposed to do, if that makes if that answers your question.

Yeah, thank you. Thanks, Jay. Thank you all for the great questions, too. I was curious, Jay, as you look ahead to the next year or so, what's something that you're most excited about?

Oh, yeah. So we recently made the decision to move our data stack over to a Google Cloud Storage and Databricks. So that's really, really exciting for me to have, you know, kind of a fully managed Spark ML flow on on Google Cloud Storage from from what I would call a pretty, you know, traditional data warehouse type of model. Don't not so much but you know, a relational database has a lot of limitations in terms of like, you know, more modern applications that are providing data to our, our ecosystem. And so I'm really excited to kind of move over to that, that architecture, and kind of, you know, the work to convert all our existing applications to feed into that might be might be a challenge, but it opens the door to so much, right? Like, most of the our digital ecosystem now is is all just done through JSON, right? And putting that in a relational database is a nightmare. It's always a challenge, we have to make a lot of concessions. And, you know, in terms of the way we approach modeling data, we won't have to as much anymore. And so that's what I'm really excited about. So that that's probably going to change a lot, almost everything about how we solve problems. And, you know, I love a challenge, and I love learning a new tool. So that's what I'm most excited about, for sure.

Hiring and wrapping up

That's great. I know we're quickly coming up to the top of the hour. But just to go back a second, I know you mentioned you're hiring right now. Yes. What do you think is? I guess, what is most important to you in like, hiring for that role? Or what is something you look for and the people you hire?

I mean, I kind of just mentioned it, it was like, like, if you're a little bit like me, you like to learn a new tool. You know, obviously, we work really closely together. So being open minded, being self reflective, being able to give good feedback, you know, like being able to contribute an idea, but how we can do work better, is a really critical part. And that's, you know, as much as I'd love, you know, some absolute, like banging our expert with Shiny experience coming out the wazoo. If you can't work nice with another team, and your code isn't readable, and this and that I 100% wouldn't find useful, right? Because we have to work together, I, you know, I might have to maintain your code sometime. And if you can't tell me what you're doing, it's not useful to me. So we're really looking for, you know, teamwork, collaboration, communication, and at very minimum, some R and programming and get experience.

Yeah. It's great. Thank you. I see Libby said, Well, I wish I lived in Canada. But we I will be sure sure to share it with the LinkedIn network there too. Yeah, that would be great.

What, what's the best way for people to stay in touch with you? And if they have follow up questions? Is it LinkedIn?

Yeah, LinkedIn, LinkedIn is good. Like maybe put a note when you if you if you want to join my network, put a note that you saw me on on the on this thing here, just so I can sift you from the salespeople that hang on the time. When you get that director title, I found like it's like, probably 95% of the requests that I get are just somebody who will immediately just try to sell me something. And so I do get I do have to sift through that a lot. So yeah, a quick note will help me will help me not ignore your request for a connection.

Well, thank you. So I know we just hit the top of the hour, but thank you so much for joining us, Jay. Great to hear your experience and learn from you really appreciate it. Of course. And thanks for everybody's great questions and conversation. That was that was fantastic. Thank you all have a great rest of the day.