Jessica Franks shares her experience of joining Not on the High Street as an engineering manager for the data team. She discusses the challenges of starting a new role in a new country and managing a team with diverse skill sets. Jessica explains how she tackled the lack of data strategy and created a visual representation of the data architecture using a Wardley map. She emphasizes the importance of simplifying infrastructure and improving data quality before diving into AI and ML projects. Jessica also highlights the need for clear communication and collaboration with stakeholders to ensure successful data initiatives.
Takeaways
Starting a new role in a new country can be overwhelming, but with the right experience and skills, it can be managed effectively.
Creating a visual representation of the data architecture, such as a Wardley map, can help communicate the complexity and prioritize projects.
Simplifying infrastructure and improving data quality are crucial before diving into AI and ML projects.
Clear communication and collaboration with stakeholders are essential for successful data initiatives.
Titles
Navigating a New Role in a New Country
Prioritizing Infrastructure and Data Quality
Sound Bites
"Everything new sounds like you set out on an adventure and you got what you asked for. Was it scary though? Was that like, oh my god, what am I going to do?"
"Having a picture that everyone agrees this is what it is. You know, there's all too often like 10 little things in the corner that nobody really understands that that's crucial to the way things operate."
"Using a Wardley map was new to me and I instantly loved it. The way it laid it out, the way it communicated to everyone what was visible and important, but then not visible and important was sort of also, you know, that I think as a person running an engineering team is often really hard to explain that this crucial piece that no one can see, we need to do something about."
Chapters
00:00 Introduction and Setting the Scene
02:13 Navigating a New Role and Team
11:06 Visualizing Data Architecture with Wardley Maps
19:53 Prioritizing Infrastructure and Data Quality
28:11 Challenges of AI and ML in Data Initiatives
32:05 Conclusion and Key Takeaways
Chapters
Jessica Franks shares her experience of joining Not on the High Street as an engineering manager for the data team. She discusses the challenges of starting a new role in a new country and managing a team with diverse skill sets. Jessica explains how she tackled the lack of data strategy and created a visual representation of the data architecture using a Wardley map. She emphasizes the importance of simplifying infrastructure and improving data quality before diving into AI and ML projects. Jessica also highlights the need for clear communication and collaboration with stakeholders to ensure successful data initiatives.
Takeaways
Starting a new role in a new country can be overwhelming, but with the right experience and skills, it can be managed effectively.
Creating a visual representation of the data architecture, such as a Wardley map, can help communicate the complexity and prioritize projects.
Simplifying infrastructure and improving data quality are crucial before diving into AI and ML projects.
Clear communication and collaboration with stakeholders are essential for successful data initiatives.
Titles
Navigating a New Role in a New Country
Prioritizing Infrastructure and Data Quality
Sound Bites
"Everything new sounds like you set out on an adventure and you got what you asked for. Was it scary though? Was that like, oh my god, what am I going to do?"
"Having a picture that everyone agrees this is what it is. You know, there's all too often like 10 little things in the corner that nobody really understands that that's crucial to the way things operate."
"Using a Wardley map was new to me and I instantly loved it. The way it laid it out, the way it communicated to everyone what was visible and important, but then not visible and important was sort of also, you know, that I think as a person running an engineering team is often really hard to explain that this crucial piece that no one can see, we need to do something about."
From small to big, every company on the market, irrespective of their industry, is a data merchant. How they choose to keep, interrogate and understand their data is now mission critical. 30 years of spaghetti-tech, data tech debt, or rapid growth challenges are the reality in most companies.
Join Aaron Phethean, veteran intrapreneur-come-entrepreneur with hundreds of lived examples of wins and losses in the data space, as he embarques on a journey of discovering what matters most in data nowadays by speaking to other technologists and business leaders who tackle their own data challenges every day.
Learn from their mistakes and be inspired by their stories of how they've made their data make sense and work for them.
This podcast brought to you by Matatika - "Unlock the Insights in your Data"
Aaron:
Let's talk data strategy. Nobody tells you how to do it, and that was the experience Jessica had at Not on the High Street. We've heard all about the team, the culture, technology. Hope you enjoy. Hi, Jessica.
Aaron:
Thanks for coming on the podcast. Tell us a little bit about a day in the life of of of Jessica at Not On The High Street.
Jessica:
Oh, thanks, Marilyn. So for those of you who haven't come across Not On The High Street before, we're basically an online marketplace that supports artisanal designers and curators from across the UK. We've got over 5 and a half 1000 small business partners selling over 370,000 products with us. So it's really great place for gifts, for homeware, for all sorts of things to spoil yourself with. And, yeah, I'm the engineering manager for the data team at Not on the High Street.
Jessica:
So my team is
Aaron:
That must be a big challenge, actually. 300,000 products is not your normal kind of company. Like, quite often, companies deal with a handful of products and and lots of sales. So I imagine your data job is is pretty difficult.
Jessica:
Yeah. Because it's a marketplace. Right? So now you've got you've basically a storefront for loads of different businesses. So there's data for each business on your website that you're dealing with.
Jessica:
So kind of akin to to Amazon on a smaller scale, I guess. But it's yeah. It's there's a lot of data at not on the high street, as the data platform team. So we're responsible for basically ingesting data into Safe and, making sure that everybody in the business has the data that they need to make the decisions that they need to make. We work quite closely with an insights and analytics team who kind of reports into the business side.
Jessica:
My team focuses more on the tech side of things, but we work quite closely together to make sure the company has all the data that they need.
Aaron:
That sounds interesting, actually. So that as a setup, you have the kind of, engineering responsibility for data supply, but the analytics teams sit in the business and in these teams.
Jessica:
Yeah. So they they are focused primarily on one area. Some analysts kind of work in more than one area, but they will be specialists, for example, in marketing data. And they work very closely with the marketing team to help them with whatever kind of insights they would need, to make decisions. So, previously, before I joined, there were there was one kind of data team that was run by a head of data.
Jessica:
And, before I joined, they split out into 2 teams with the data platform team and an insights and analytics team. So
Aaron:
I see I see that a lot actually, as a sort of overall strategy for companies doing with their data teams. I'm not sure it's, happened, you know, deliberately or just organically, but it seems like a very successful setup to me at least. The the companies take their data teams, put them closer to IT with kind of looking after infrastructure and and a role to support the business. And, of course, the people who understand the business sit in the business. That, seems like a good good idea.
Jessica:
I think it works. Most of the time, there's some kind of aspects where because it's kind of a crossover role, like, the the analysts are heavily dependent on the work that we do, so we still need to have an understanding of the business in order to model the data correctly so it can be used. So we still have a lot of interactions with business because they're our stakeholders as well. So we've missed we don't necessarily answer those, like, very small questions that an analyst would help with or those in-depth projects where they kind of go quite deep into the data to to investigate it. We kind of make sure they have the data to do that, and that it's modeled in the right way and has all the the necessary things, but we don't necessarily then end up answering those questions.
Aaron:
Yeah. No. That that makes that makes perfect sense. It's quite hard to know about 300,000 different things.
Jessica:
Well, I mean, a product is a a concept of a product. You don't you know about all of them. Yeah. Yeah.
Aaron:
Cool. So, I would like to I I think maybe if you set the scene for us. So you do cast your mind back to when you first started, that, initial couple of weeks. I think that would be great introduction for everyone to what what the team was like, company was like, or the sort of problem was like as as you saw it when you when you first start?
Jessica:
So I moved to the UK about 2 years ago straight from Johannesburg, kind of lived here before, had visited a few times, but hadn't lived here before. And I moved and started a new job, like, within 3 weeks of moving here, so that was quite a a new thing. I was starting completely new country, a completely new role. So, yeah, I joined not on the high street as, initially, as tech lead for data engineering team. But shortly after I arrived, it was clear about that.
Jessica:
It was no longer really my role. A few other people had left, and they weren't going to replace them. So within the 1st week, I was introduced to my team, which was just more than the data engineers. It was also the analytics engineers and the data scientists, which was quite interesting. There there's a big team for you to to manage.
Jessica:
I was ready for my little small team of 2 people in the data engineering. Yeah. But because I had some experience with analytics engineering, and like I just mentioned, I'm experienced with data science. I think they figured I could handle it. The company went through a bit of restructuring, and eventually, my title ended up being engineering manager for data.
Jessica:
So that's where we're at now. But, yeah, the the first few weeks were interesting. It was my my brand new team, brand new company, brand new country.
Aaron:
Everything new is I was like, you, you set out on an adventure, and you had to stop in your house. Was it was it scary, though? Is that, like, why come all of my guys in?
Jessica:
I don't think scary. I think very overwhelming. So it was, like, a bunch of new things and just trying to figure out, like, does the UK work in the same way as other businesses I've worked in in the past? Like, I've worked in African companies, and they have a certain way of working. Is it the same in the UK?
Jessica:
Will my sarcasm be appreciated? Because I don't want It's not even find out. It it is. So, like, at least everyone gets my sarcasm here, which is fantastic. Yeah.
Jessica:
I I came into a team that had gone through a huge amount of changes, like, the past 3, 4 months before I joined. 3 of the data leaders within the team had left. So everything was a little bit up in the air. There was a data product manager at the time was, like, trying to keep things together, trying to keep things on track. She had a lot of, like, ideas and things she wanted implemented.
Jessica:
There was, like, 1 or 2 ideas outstanding from the head of data who had just met. But otherwise, it was kind of just like, here's a data team. We need to do these 2 projects. Everything else is kind of just go for it, and we need to save a lot of money. So all your stuff is very expensive.
Jessica:
Figure out how to reduce your costs. That was the the kind of direct advice I've had coming from, people working the team. When I joined, I was also reporting to the he starts with the head of architecture. So he was, he hadn't really managed the data team before. He didn't have any experience with data.
Jessica:
So it's a bit of a learning experience for him. Now I report to the VP of engineering, so a little bit different on the data structure. So he has a little bit more experience of beta, but again, within, like, the senior leadership team, nobody has a lot of data experience. So it's kind of everybody figuring it out as we go.
Aaron:
Yeah. That that seems pretty normal that companies almost don't know what to make of the data team. They started faba ingly with the output they want. Often, it's not very well formed from from what I was saying. And how do you go about engaging with users?
Aaron:
Like, who you so these are your, managers. These are the people that, you know, obviously give you resources or give you, permission to do things, but they don't have to figure out what to do. So how do you go about finding users and and what they are?
Jessica:
So initially, when we had a data product manager, that was one of her main responsibilities was to kind of understand the problems within the business and make sure we were coming up with the right solutions to address those problems. Because there were a couple of projects that, like, for example, our data scientists worked on that weren't, like, were really cool. Like, here is a problem that I'm solving, and then give it to the end user. And they're like, that that's not what I wanted. And I think that's such a a common thing that happens.
Jessica:
So I think that was the first project that the data product manager was involved in where she was like, wait. No. We're wasting time here. So we've been a lot more conscious since then of actually qualifying requirements and making sure people actually know what they want. So you spend a lot more time on that discussion phase, that figuring out phase rather than the implementation phase, then continuous consultation draft projects, just to make sure people understand like what you're going to be doing, get their input and their feedback at every stage of the process.
Jessica:
So everybody's kind of collaborating more. So the end result is actually used, which I think helps. Now that we no longer have a data product manager, that kind of falls on me to, to chat to people. Over the past year, we did work on one project and it was kind of that, the only thing we're working on. So it was a GA 4 migration.
Aaron:
And it
Jessica:
was painful and it took a really long time and we had to say no to a lot of people cause the team was quite small. So like we pushed back on a lot of initiatives or different projects that people would like us to implement. But now that's over, we actually have time now. So it's now about like actually talking to our stakeholders, listening to their problems, and figuring out, okay, how can we help you? Like, we're a team.
Jessica:
We've got access to a lot of things. We have problems say solving capabilities that you know, how can we help you solve that? So it's more about engaging with stakeholders regularly just to kind of get their feel for it
Aaron:
Yeah.
Jessica:
As well as we have, like, our own project that we have on the side to, like, improve our infrastructure, simplify things, reduce our costs because that's a continuing thing. Like, do we need to be spending that many Snowflake credits every day? Probably not. There's ways we can improve it.
Aaron:
Yeah. Yeah. I I mean, to be quite clear, can you tell us a bit more about that? So, you know, you we went back in the the team, kind of what the company looked like. But as you said, you came into this new role and you were presented with whatever was left behind, technology wise and and infrastructure.
Aaron:
The the cost motivation yeah. Again, you're changing some things to reduce cost. Are you changing some things to be more productive, or what what what are the sort of main drivers for that infrastructure work?
Jessica:
So in terms of infrastructure, like, where we as an example, one of the cost savings that we did have. So we were paying an external service provider for Airflow and Airflow is an open source product. So there's no real need to pay someone to host that for you. They, I mean, it used to fail every Thursday And like all our DAGs would just stop running on the Thursday and I'm like, oh, they're doing an upgrade. That's cool.
Jessica:
And that used to irritate me. So now one of the, the cost saving initiatives we did was to move our infrastructure over to Kubernetes. So it's now self hosted. I think we've had one issue in the year that it's been running. Mhmm.
Aaron:
So it's
Jessica:
a lot more stable. We're in control of it, and it's significantly cheaper every month to run now. So that's like an instant cost savings. So we didn't change the technology. We just changed the way we were hosting it.
Jessica:
Obviously you need the skills in house to be able to do that kind of thing. So not all companies have that available. We're lucky our infrastructure team is very helpful. Our engineers in my team like to learn new things, so that also helps. So that's kind of one initiative.
Jessica:
The other is just looking at queries and seeing if they're efficient or not. Snowflake has a quite a good query visualizer. It kind of breaks down how your queries are, and you could kind of see the the parts that it's spending a lot of time on. So if it the longer it runs, the more it costs. So you can start to optimize and, like, remove crappy joins or re optimize, like, your SQL in general, like, the general kind of steps that you would do to to re optimize your SQL window functions are generally a big point of expense if they're if they're not working properly.
Jessica:
Just small things like that. Removing tables that aren't necessary, and kind of thing. It's just kind of constantly thinking and then also renegotiating contracts with suppliers. So
Aaron:
Yeah.
Jessica:
As much as I I dislike talking to people, I've had a lot of conversations with suppliers to see if they can give us, better terms or at least, like, split our payments up or if there's an alternative supplier that can supply the same product, just engaging with that. So that was at least one director from the business that I was, you know, able to at least pick up right away and work on. But coming in, there's, like, there was no data strategy for the company when I when I joined or not that I was aware of or can find on any of the documentation anyway. So that was another thing that I wanted to do is create data strategy, and that's something my current boss wants as well. Just, you know, what are we actually gonna do with data?
Jessica:
And it started with me kind of actually just what do we currently have. There was no data architecture diagram when I joined. There was, like, 1 or 2 diagrams for, like, very specific services, but there was no overall picture of what does data look like at Mother Line Street. It's he carries a beautiful picture that I've now created. You know?
Jessica:
Here's all the the data sources that we're ingesting from. Here are all the databases that we look at. Here is all the egress points. So we now have, like, a picture, and that also then helps you start to identify. Okay.
Jessica:
Where could we improve? Is there anything missing?
Aaron:
It's so amazing how much value that adds, just having a picture that everyone agrees this is what it is. Yeah. You know, there's there's all too often, like, 10 little things in the corner that nobody really understands that that's crucial to the way things operate. You know, that if they break, they might be a significant problem. What what did you do, during that exercise to draw the diagram?
Aaron:
Were you just, like, PowerPoint and just sat down all year? Like, okay. I'm gonna do a whole video type thing, or was it was that collaborative? How did how did you go about the the architecture part?
Jessica:
So that was in Miro. It was, like, all the tools I know we had. So for example, we use Stitch for most of our data ingestion, and it was just kind of mapping out all the different interfaces we had in Stitch. Then on top of that, we use Airflow, and we have a couple of batch containers that run custom API integrations. And then we're always going into each GitHub repo, figuring out, like, what it does, where it comes from, and just kind of understanding all the different possible data sources that we have and just brain dumping it into Miro and then starting to organize it.
Jessica:
And then where I didn't understand something, asking one of my team members, like, can you explain this to me? How is the service working? Do we have the diagram that explains it?
Aaron:
Yeah. Any situation where someone had left? Because you you mentioned the team, a bit of a turnaround on the team. So there might have been services. So I've seen it quite quite a lot where services are like, oh, we don't touch that because that was the previous person that they got off.
Jessica:
Yeah. So we do have a few of those. I mean, there's a lot of code that hasn't been, like, rejecting it, and it's now, and they're no longer really fit or purpose. And you're like, how long ago was this written? Because, I mean, it's fine.
Jessica:
Good enough, but it, like, just doesn't have newer data in it or, like, it's structured in a way that no longer makes sense for the purpose that it's serving. I mean, the com Mata on the high street as a company is 18 years old, so it's got a lot of history. Data has gone through many iterations of the company. I mean, a couple of years ago, they had a machine under somebody's desk. And when the cleaning service came in at night to clean, they would unplug it, and then the pipelines for the day wouldn't run.
Jessica:
Like, moving from that to cloud infrastructure, they had a rich database. So for one point, we're now using Snowflake. Different PR tools have been used. So it's gone through a lot of ebbs and flows throughout the years. It's been a massive team with I think at one stage, there were, like, 5 data scientists, and now we've got one.
Jessica:
So we're a lot lean, and now there's a so currently my team has 2 analytics engineers, 1 data engineer and a data scientist. So we're quite small and everybody kind of takes on roles that typically wouldn't see they will do something that's not typically something like, for example, a data scientist would do, but just because there's only so many people and so much work that needs to get done. People end up having to do things that aren't to feel what they would do. My team is quite happy to do that. They they like the learning opportunities, so that's always positive.
Aaron:
So, when when we met a few weeks ago, one of the things that I really, caught my attention here, you were giving a talk, and it was it was mostly about your strategy and how you how you went about forming it. But in particular, this idea of using a wall name map was was new to me, and I I instantly loved it the way it laid it out, the way it's, like, communicated to everyone what was visible and, you know, important, but then not visible and important was was sort of also, you know, I I think as a, you know, person running an engineering team, is often really hard to explain this crucial piece that no one can see. We need to do something about. And, you know, tell us a little bit more about your map and how you discovered it and and and then how you communicate it, how you actually use it as a tool.
Jessica:
Yeah. So mapping, I kind of came across by accident. Before that, so I was tasked with, like, I need to put together a data strategy. So I'd, like, been looking into a number of things. I did a lot of research.
Jessica:
Like, there's a lot of, like, this from different consulting firms. Like, this is what your data strategy should have, and it's, like, way long and intense, and no one's gonna read 50 pages of data strategy. And so it's a lot of, like, buzzwords and keywords that are meaningless to anybody who who doesn't understand them. So it needs to be like, for me, I want things to be simple. I want them to I want it to be easy for me to understand because I don't have a typical data background.
Jessica:
I've only been working in data for the past 5 years. So it's was important to me that it was something that I could understand. I have a mentor, and she pointed me towards, like, data maturity analysis. So I looked into that, and it started to make a little bit more sense. But, while I'm a part of somebody posted a link to a video with Simon Mordy, who's the inventor of maps.
Jessica:
He was doing a talk. I think it was at, explaining the whole concept of a Wardley Map. And it was at that point, I was like, oh my gosh. That makes so much sense. So he was talking about Wardley Maps and how it helped him drive the strategy for his technology company at the time.
Jessica:
He goes through the whole background of how he read a lot of books about war and the strategy within war and how maps are used in war and how you kind of develop your strategy around which direction you're
Aaron:
gonna Yeah. Very You can imagine the concept of the lies, actually.
Jessica:
So, yeah, it was like I was just like, oh my gosh. This makes so much sense. And he had a very good, like, example of how he applied it to his photo upload business and, like, where they could kind of see things. So idea behind the map is you basically focus on a specific user and their needs within the organization. Then all of those needs have their own needs, And it kind of starts to cascade down, and you eventually get to the point where you have a complete picture of a particular process or a particular service.
Jessica:
And the way a word in that works is you kind of put your user at the top of it, and then you've got all their needs, and then you can start to map their needs on the the Wardley map. So top to bottom is however close it is to the user. It's more visible to them. They probably care a little bit more about it. The further away from the user, the less they would care about it or the less visible it is to them.
Jessica:
So data, for example, users use Looker reports and Tableau reports on a daily basis. So that's very visible to them. So Tableau and Looker would be quite near to the top. Whereas your data warehouse is Snowflake, BigQuery, whatever you're using. They're okay.
Jessica:
They'd, like, maybe hear you say Snowflake once in a while, and they don't like, as long as I where's my graph? That's what I care about. It would be where it's coming from. Just make the graph visible. So the less kind of visible, the less things people care about, those kind of at the bottom.
Jessica:
And then when you're looking from left to right on a walking map, that's kind of how evolved a particular component in your map would be. So on the left, be things that are very new. Like, you're still exploring them and unfold developed ideas. And then as you move more to the right, it's kind of things that are well developed commoditized solutions, things you can just buy off the shelf. You're never gonna create your own data warehouse nowadays.
Jessica:
It's done. You're not gonna create your own BI tool necessarily. You just buy 1 off the shelf. So those kind of things that on the very far right. And then in between is kind of, you know, things that you're developing in house.
Jessica:
There's new ideas. You you're still working on them going towards this is quite established. We don't do much maintenance on it, but it's still something we're responsible for in house. Yeah.
Aaron:
Do you show that to people? Do you then take that to meetings and, you know, explain to leadership this is what this is what our architecture looks like, and then then do they understand it when you show it if you if you do?
Jessica:
So it was this year that I created it because I wanted to create it as part of our data strategy and was a great motivator for me to be able to show why I wanted to do some more, like, tech oriented projects rather than business impacting projects. So they do impact the business, and I was able to show how. So one of our projects is we have 2 DBT repos within Mount on the high street. 1 that runs on DBT core, one that runs on DBT cloud. So dbt cloud is a commoditized solution that just works.
Jessica:
They upgrade it whenever you need an upgrade. You don't have to maintain it very much. Whereas dbtv core, you now are responsible for making sure you have the latest version that it runs. If it breaks, You need to figure out why it's breaking. And there's no need for such a small team to be maintaining 2 solutions.
Jessica:
So I want to like, it's been on our room at wherever we want to merge these, but it's never really been something that we could explain why we wanted to prioritize it. But now we've got a map. There's 2 dbt dots on the map. 1, like, very far apart from another one is in commoditized. 1 is not in commoditized, and it was then easy for me to explain the purpose of that project and then also align it with our goals.
Jessica:
I absolutely
Aaron:
love that. It's so so crucial that, you you know, the thing that really stood out to me is you've got this business requirement. Yes. There's always these business requirements, and they they kind of know what that is. So you mentioned your GA 4 project.
Aaron:
Well, that turns into some kind of reporting or decision making. But then there's this, other aspect, which is all the kind of infrastructure that means it's much slower than it should be to achieve or there's this kind of like, you suddenly get to highlight, well, yes, you have your business requirement, but we have this kind of our own best to sort out to make things simpler, which we've tried to do. Exactly. We end loaded people have that exact issue.
Jessica:
And I think it's really useful that one of our tech goals as a technology team as a whole, since the data platform team forms part of the the technology team at Northern High Street, one of the goals or the strategy for for tech as a whole is to simplify things because we've got a lot of unnecessary complicated logic and infrastructure and things like that. So for us to tie into the overall tech strategy, like this is how we wanna simplify things. This is how we wanna improve things. It then ties back. And now I've got like a visual representation and an easy way to talk through something.
Jessica:
Because people can understand, like, I may not understand what DB key is or how it works or what it does, but the fact that you have 2 dots on the map and you only want 1, that I understand.
Aaron:
I thought I can get straight away.
Jessica:
Exactly. So it's it simplifies things, and it makes it easier to to talk about why you would want to do something.
Aaron:
Where do you think data seems so hard to understand? Yeah. You're the VP of engineering is is is in and around data all the time. Yeah. As you pointed out, I don't really have experience of what data is or what data means to the company.
Aaron:
Why is it so hard for people to understand what it is?
Jessica:
I think because it bridges the gap between business and technology. So they will get the tech side of things, and they kind of understand that this but you like it's this hybrid role where you're kind of having to understand the business needs in such a way, because it's not the same as, like, normal kind of tech operation where you would, I need this extra field on the website because I wanna do this.
Aaron:
Like,
Jessica:
that's easy to understand. There's a set requirements where somebody's like, I wanna know how many orders happen through this channel 2 in the morning. And what type of customer was up at 2 in the morning doing that? Like, it's a little bit more obscure. Like, it data isn't well defined.
Jessica:
Like, it it can be very floaty. Yeah. If that's the right word. Like, it's it's very,
Aaron:
like messy. You know? It's just making the text so messy. Actually, that is this whole function.
Jessica:
Yeah. So it's there's a lot of things that are quite well defined in data, and I think that's the part that people understand, but it's that, like, low t space in between that where it starts to get complicated. Mhmm. Also, there's a lot of technology and terminology that's different from like a normal tech process or a normal business process. So it's just making sure you use easy to understand language when you're talking about things.
Jessica:
Like one of the problems we had was our data was only being like available after lunch in Looker. So people could only really see data for the day before at 12, 1 o'clock in
Aaron:
the afternoon, which is terrible. Happens is is pretty hot.
Jessica:
Exactly. Like, initially, I boiled the dye I created a simplified diagram and took my circles through. Like, this is why, like, I know, like, I hate it too. I also don't think you should only have your data at 1 o'clock, but these were the 10 steps involved in the process to get to that point where we have data, and this is what we're going to do to try and fix that. And then we were able to simplify if people have their data when they log in in the morning.
Aaron:
So, like And all that sort of came in a couple of dots on your map. You know, we get these reports after lunch, so they're only fresh after lunch. And these are these 2 dots. And then that that muscle
Jessica:
is very
Aaron:
useful to to to explain what that is the problem.
Jessica:
So it again, having diagrams, even if it's much as the map, just having simplified pictures of things and taking people through it and using, I guess, simpler language that's not like our ETL process is gonna take 2 hours because we're waiting for Google to upload data today's service. What is the reason is it's just like we only can work with what we've got. This is why this is the pain point you have. We agree it's a pain point. These are the things we're gonna do to solve it.
Jessica:
Yeah. And I I think it's the more you explain things to people and bring them into your world, the more understanding they are later on. So any kind of thing that facilitates a conversation, whether it's a walking map or a key texture diagram or something like that, definitely helps.
Aaron:
So you you said you don't really like talking to people. We seem very good at it. I mean, it seems like none of the high street gets on like, it's a lot of communication, very clear understanding what the issues are. And I said you're building those relationships. Well, how do you reconcile those 2 things?
Aaron:
Like, you you you must be doing a good job, Dorothy, Don. But you're saying you is it a challenge? Are you gonna enjoy it? Or
Jessica:
I think it's just I'm quite introverted, so speaking to people is not something that comes, like, naturally. I'd rather just stay by myself, but I like to challenge myself to do things that make me uncomfortable. Like Yeah. A podcast, I would typically do this, but it's like
Aaron:
the more a very good job of it. So
Jessica:
I think that, like, just to grow as a person, the more you kind of challenge yourself, put yourself out of your comfort zone, that's kind of where you realize things that you enjoy or kind of yeah. I mean, if you did the same thing all the time, I mean, that's perfectly fine if that's what you want, but I want to challenge myself. I don't necessarily wanna kind of not speak to people. I think I think that
Aaron:
will take you an awful long way. You know, I I certainly relate to that that, you know, I I look from the challenge, and I think it will look from the challenge, you know, don't play a growing unless looking for the next thing. I suppose that that brings a kind of interesting question. You've got the you've got quicker for the background of the map of where we are. Are there some other big challenges on the horizon?
Aaron:
And and how do you intend to deal with this?
Jessica:
I think this is probably the challenge for a lot of data teams is everybody wants AI and more ML. I think with the rise of chat GPT and other OLNs, there's been a big focus from a business perspective now, like this new Cool Year technology is available. Like how can we use it? And it's understanding what that AI and ML roadmap would look like. But you have to get the fundamentals right before you can even start to do that.
Jessica:
There's no point in using machine learning model or an AI model to do something if your data is crap. Like, you need it and you need to be able, like, there's a lot of cool new tools that, like, will query your data for you. So you say, tell me how many orders there were in this quarter and can quickly pull the graph for you. But if your orders table is not in the correct format or you have 7 orders tables, it's gonna have the exact same issue as a human user would because it's not
Aaron:
easy to use. Yeah.
Jessica:
Yeah. So so there can be different applications, but that it's understanding how would we get there? What is actually gonna be useful? What is a hype? What is just like, you just want to be able to tick the box to say we use AI to do something, or is it, like, an actual problem we can solve with it?
Aaron:
Yeah. And and I'm sure you see that a lot with, you know, the hype around a new technology. And, like, it is it is incredible. And it is yeah. The UI has massively simplified the way people interact with AI.
Aaron:
But I do find myself going, yes, it's fight because I know the kind of underlying, challenges that have been solved. Yeah. A lot of our clients are dealing with, you know, full documentation around tables. Even if they had one orders table, there might not be sufficient documentation. They're gonna understand what the columns are, what what the values can it contains.
Aaron:
So I always gonna be stuck just like you said. I think he was going to be stuck. And so even if the technology is not all high, it it feels like there's some still some groundwork to to build. Yeah. Figuring out what
Jessica:
And I think I think having the working map helps explain it. So I can be like, your AI, here's your AI kind of little components on the map. It needs these five things, and these five things are not in a good state. They're they maybe were very fit for purpose 5 years ago, 8, 10 years ago when they were first created, but now they've kind of drifted a little bit more because no one's paid attention to them and possibly is. So we need to pay attention to them now, get them in a better state because that can then help your little AI dot move.
Aaron:
Yeah. That George It's awesome. I get like that. I I just love that. Like, you're absolutely right with the technical data that people care about.
Aaron:
Yeah. There's a thing they want to do with it, which is kind of understanding their side of the hype. And then there's this kind of, like, infrastructure that they can immediately see, well, it depends on all these things. That's that's Yeah.
Jessica:
Because that's easy to explain. It can be like, but why can't we do this? Well, because we have to do these three things first before we can do that. And once that's done, then this is much easier to do. Because now you can do that.
Jessica:
You can do the AI. You can do the ML. But you're gonna struggle because you're gonna end up having to, like, hack things or improve things anyway just to get that part to work.
Aaron:
Yeah. Awesome. Well, thank you very much, Jessica. It's been fantastic to hear about your own journey and along the high street's journey and the technology journey you're on. And we even touched on AI, which I didn't fully expect us to get to.
Aaron:
But it seems like if you're in data, it's probably a a logical place we arrive at eventually. I don't know. So thank you very much for your time.