Jessica Ulyate, @HelloFreshUS

Thank you for tuning in to today’s episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes we explore topics from the world of APIs, but we look at things through the lens of business and engineering leadership. Joining me today we have Jessica Ulyate, platform associate director of product at HelloFresh. Jessica validated for me that having a platform team is a sign of an organization who’s further along in their API journey, but she also left me thinking more about how product management and these platform teams will be engaging.

I always start simple with the basics: who are you and what do you do?

So I’m Jessica Ulyate, I am the product lead for the platform tribe at HelloFresh. So I started my career as an engineer in mobile software at a startup, and at that time, it’s a typical startup, like the business people tell you to build something and you build it, and what happens so often is we show stuff to clients and it was just wrong. And I was so frustrated with it, putting all my energy into this, and I figured, man, there must be a better way of doing software. And that’s how I ended up in product management. And I guess maybe the developer background always stuck with me, like, I like the idea of making the lives of developers easier. And I’m really excited I can do this, building a platform and building common infrastructure to make sure that engineers can spend their time worrying about actual customer problems as opposed to fiddling with Terraform or something.

Yeah, so you just described really nicely this kind of, I don’t want to say it’s a platform, but it’s kind of a bridge between business and IT and technical groups, that I see product management’s a number one conversation I’m having with enterprise organizations. They’re like, how do we hire, train the next wave of product managers? And a lot of that I hear is from the business side, like trying to, what you said in the beginning of that, we need to reflect business needs, but you just also said which is really the important other part, I need to make developers’ lives happy in doing this. So what is product management, like how do you define what product management is?

I guess all of those things. Product management sits at the intersection between business and actual development and customers. I might be paraphrasing it the wrong way, but Marty Cagan has a really nice definition, it’s like making sure that you’re solving the right problems for your customers in a way that’s both acceptable or good for your company and from a development perspective. And I like that idea, there’s never just one party involved, there’s always different angles, like maybe you can dream up this amazing feature but it’s technically infeasible, or the business wants that but it’s not really reflecting what the customers want. So it’s a job with a foot in a lot of different areas.

Oh my god, like I said, it’s bridging a lot of these things, like how do you bring them together and end up with, let’s say, the optimal thing at the end for everyone. But you feel like, I mean, it’s an ongoing thing, right? You’ve got to have feedback loops with all of these stakeholders, and there’s no end to it. I mean, there’s little lands and Sprints and whatnot, but…

Yeah, I guess, I personally, I like finishing things, and maybe that’s sometimes frustrating, like there’s no, I’d say, gold star, if you’ve reached it now you can stop product management. But I guess that just makes it fun as well, like there’s always more things to discover. Your customers change, your products change, the technology changes, so you always have to keep in touch with actually what your users need, what they want, what’s new tech developments that can enable new things. And your business has its own goals in itself, and making sure that you keep on top of what’s important for them as well.

Yeah, no, this is definitely the human side of our roles and what we’re building. I think a lot of people focus on the tech, but a lot of this is just about the people on the business and the technical side. But you also mentioned platform, and I’m really fascinated, I would say this is another common thread in all the conversations I’m having, is this platformification of our enterprise organizations. So what does a platform group do? Like you mentioned about making developers’ lives easier, what do you do to make it easier?

Yeah, so the definition that we use internally is that we support the engineering workflow and we help developers to create customer value faster. So a thing like, how do you get them to focus on the things that matter for customers, or external customers in our case, people who buy boxes, as opposed to fiddling with, I don’t know, the craft related to infrastructure, setting up things. And yeah, it’s thinking about what’s the common thing that all developers have to do independent of what specific business in their mind they’re focusing on, and trying to centralize that. And I guess for me it’s like just remove that fiddling with that. I mean, I call it, for me it’s a fun part, but I think that’s what I found frustrating when I was still doing development as well, when you’ve got this great idea of this thing that you want to do, and then you have to install 50 libraries, and nothing runs, and you end up filling more time with getting your environment set up than actually building the cool thing that you want to do.

Yeah, no, that enablement I find is pretty key part of every goal. When I talk to business leadership there, they want governance, but actually enabling developers to do the right thing is a bigger part of governance than any of the actual details of governance. Because developers will do the right thing if they have the right scaffolding, framework, everything around them, but if they don’t, they’re going to probably be making lots of bad and important decisions about what libraries and security and other things. But one of the things that I’m seeing with governance and platform enablement is there has to be proper team structure, as far as structure and domains kind of structure for the organization to operate in, to be able to coherently define what the platform looks like. So what does the domains and team structure look like for what you guys are building?

Yeah, so I guess it kind of depends on your company and what you define as your platform. I’ve seen that the term platform is a lot of times very overloaded as well. Since we consider a platform something that enables developers to write code faster, but I’ve seen other people use the word platform when they build common business things, like a payments platform is another thing. But in theory a payments platform would still depend on a developer platform. So in our case, when our customer is an engineer and their goal is to get software into production, we’ve been thinking about the squad structure and what this engineering workflow looks like, and we set out to try to define this workflow better, like what are the actual user journey steps involved. So if you wanted to create software in production, you’d go through the process of discovering information, writing the code, testing it, building it, deploying it, running it, kind of looking at operating it, getting observability and incident management. So we kind of thought about this workflow. And I mean it would have been nice to say like we discovered this workflow and then we created our teams, but to be honest it kind of went the other way around. We created some teams and they kind of worked, because we thought intuitively this makes sense, and then later we figured out the framework that kind of explained the intuition of how these teams were set up. So our squads actually focus on specific parts of this workflow. So one squad’s focus is on a specific coding and testing aspect, there’s another squad that focuses on the release workflow, we’ve got a squad that focuses on the specific runtime environment which is Kubernetes in our case, and one group that focuses on observability and incident management. And it works for us, but with the caveat, I’ve been operating in this one platform environment, and I think this might look slightly different depending on your particular platform and your particular company.

Yeah, I mean across the API lifecycle for me, there’s a lot of our customers ask us, well, just tell us the way to do it, just give me the formula please.

Yeah.

The two things, tell us how to do it, and then when are we going to be done with APIs? It’s like, well, you’re never going to be done, and there’s no one way. And so teaching people, I guess teach people how to fish, they have to be able to form their own teams. And I guess that’s what it feels like that’s what you did, is you thought, you had in mind how to organize it, but then once you did it, it kind of validated itself, and then you explain why and how it works. I think teams have to just have the confidence to do it, and have the right skills, but then make it fit to their organization and their culture and their unique industry and how they operate.

Yeah, exactly. I think what I particularly like about this framework, and like I said, I haven’t implemented it in a different world, but I think it can actually fit on a number of different size platform works. Like if you have a larger platform, you can make your squads smaller to focus on narrower plans of this engineering workflow, or if you’re in a smaller team, then you say, like, oh, we have to take care of all of this, but then you use it as a way to prioritize which areas maybe I’ll be focusing on in this short term or midterm. So it’s a nice general framework, but I guess I haven’t validated it in the wild.

Yeah, no, interesting. So how much of this topology is programmable? I mean, are you guys using Terraform to stand things up and tear things down?

Yeah, I think we try, oh, mostly infrastructure as code. So we try to have no rogue things running, everything should be reproducible. But yeah, there’s automation. I think it plays a huge role if you’re working on platforms and trying to make workflows a bit smoother. I’m not sure which aspect to go into, but I think automation is life.

Yeah, well, I mean, making the technology do the things we can’t do at scale or repeatable, as you said, is pretty critical. And even me as a human, I can’t do the same thing in a repeatable way every day because I wake up in a different mood some days, and so automation’s essential I think for this to work at scale with the number of resources or people we have available. So how do you measure productivity across this? Do you adhere to any DORA metrics or any way of understanding what’s working and what’s not?

Yeah, so we try to measure the DORA metrics for our organization. It’s kind of playing around with the idea, like, are all these DORA metrics good KPIs for our platform? And the answer is both yes and no. On the one hand side, the DORA metrics measure how fast you can deliver things and at what quality, so in theory that should be a good indicator if you’re doing your platform well. However, there’s a lot more things that squads can do, or the teams can do, that are outside of platform’s control, so that you’re not the sole driver of this metric. So I’d like to think of it like mobbing, like a squad can implement mobbing and that can make them, I don’t know, it can make the PR process a lot shorter, and then in theory their deployment frequency could go up, or the time to change, but we don’t know if we’re doing that. So just looking at that as our sole indicator of success is very difficult because there’s a lot of other factors that can actually influence these metrics. So we’ve been kind of, they’re there and we’re measuring them, but I’m trying to figure out what are some more granular things that are more platform specific. Yeah, I’m not sure if I have an answer for that yet, but it’s actively consuming my mental cycles at work at the moment.

Yeah, well, I think you’re in the state that I see everyone. I haven’t gotten a solid answer, like, yes, here’s how we’re measuring it. The ones that are further along in the journey are measuring and pulling the data, trying to make sense of it, but it’s the tea leaf thing, where, well, I don’t know, this quarter it’s making sense, but last quarter it didn’t really, and there’s just a lot that goes into it.

Yeah, and I think this is, I think naming things are hard, but measuring things are also hard. And there’s a lot of things that you can measure, but it’s also figuring out what are the right ones. And there’s a thing, like if you torture any data long enough, it will tell you what you want to hear. So you have to make sure that you pick the right things at the end of the day.

I think I’m gonna come up with an observer performance framework and call it Torture, so you can come up with a way of playing with that. Because it’s so true, you can make anything kind of speak to what you want to see, and you really have to have an honest view of it and an honest conversation. Because I get my blinders on too, where I’ll be reading the signals and reading the tea leaves, I’m like, yes, I’m confident this makes sense and we’ve got it nailed, and then someone comes in from a business unit and goes, no, no, that’s not actually meaning anything, and I’m like, well, wait. So I think we need to get out of our silos sometimes, and it’s got to be peer review or a group.

Yeah, exactly. And it’s kind of aside from the point, but I read an article recently and the person was writing about pair product management, which I thought was a really nice thing. Like, we think about a lot of times pair programming in a developer community, that there’s usually working together on things, but I think when you go into product management roles or other more leadership roles, it becomes more isolating, the things that you’re doing. And I’m trying to bring that more actively in my life, to pair product management with someone, just go to someone with a similar role, like, hey, just help me think through this problem. Because like you said, you sometimes get so stuck in your own specific tunnel of what you’re thinking about, that just a kind of reality check from someone else is just so valuable.

Yeah, so I just hired someone for my team, she’s helping me define what is product management, and not for our platform what we’re doing, but for the community in the space, and helping us create workshops and curriculum. Because one of the top requests we’re getting from our largest organizations is, how do we train up the next generation of product managers to be API literate and understand all of this? And they’re asking, well, should people come from technical backgrounds, should they come from more business backgrounds? The pair product management kind of fits, like you could almost seek out someone who’s got more of a technical background if someone has a more product background. So what’s the ideal mix or journey, I would say, for that, you think product managers should follow?

Well, I think product management is an interesting discipline, because I think, I’d say, I know there are university degrees that you can get, but I think up to recently it was more like you come from somewhere else into product management, it’s not a degree you go and study. So I find it interesting that there is such a diverse mix of backgrounds that bring a lot of people into this product management discipline. If I think about platform though, I’ve recently hired a few product managers, and it was a debate that I also had with people in my team, like, do you optimize for people who afford the domain knowledge, but maybe these product skills or Sprint skills can be more developed, or do you optimize for someone with more product skills with maybe less domain knowledge? And to be honest, I think it’s sometimes more difficult to learn product management skills than it is to learn about a domain. Because I think if you’re a good product manager, you will always be sounding out a situation where you’re not familiar with the product, so you kind of inherently have these skills to upskill yourself in whatever new product you’re working on. That being said, I also know it depends on the maturity of your group, like if you prefer to hire more senior people or more junior people. But I think previously in my career I thought, like, oh, yes, you really need a technical background if you want to do product management well in engineering tools, but I’ve kind of had to eat humble pie when I’ve been dealing with some of my other colleagues with no tech background, and they’ve asked really, really insightful questions about the domain that are just like, man, no, you don’t need to have a tech background to ask the right questions. And I think, maybe that’s not a one-size-fits-all answer, but that for me is the takeaway, it’s less about your background and more about being able to ask the right questions I guess at the end of the day.

Agreed. And I’m constantly trying to, I mean, my career since 2010, part of my career has been trying to turn people on to the API world that’s kind of beneath everything, and I find business stakeholders, curious people, ask the best questions and the most obvious. And it’s back to me, I get my blinders on technically as a classic white male developer engineer, 30 years experience, those blinders go on really easy, and I get locked into specific ways of thinking. And I’m very aware of that from surrounding myself with other business stakeholders and people go, oh wait, why are you doing that? So I mean, curiosity is kind of one of the number one requirements of the job for me. Is this something you’ve always been in your career, like, were you like this back in school and when you were younger?

I guess so. I mean, I like figuring things out, so when you said curiosity, I’m like, yes, that was the right thing to say. Like, that curiosity is a really important aspect, you can have a really great person in a role, but if they’re not curious about the products or about whatever they’re working with, it doesn’t mean anything. But I don’t know, I don’t have any stories on the end of my childhood, but…

It’s okay, it’s cute.

Yeah, I mean, I like creating things. I think what led me now to the road of actually engineering and software is like, that’s sort of like, I can create things, it’s amazing. And I mean, I tend to do that, like I like baking as well, it’s a similar kind of thing, of taking stuff and making something. But then I think curiosity is an awesome skill to have, I’m not sure how you can go through this world without being curious about what’s going on, there’s so much cool stuff, man.

And it’s the thing that I interview for, I’m always looking for curiosity over, I don’t do coding tests, I just want evidence that someone’s naturally curious before they’re gonna come into my team. Because I’ve had people come onto my team who just will tell me what to do, tell me how to do this, and I’m like, no, no, like, here’s the thing, like, be curious, poke, figure it out. And that’s just an essential skill as far as being able to accomplish and figure out where you’re gonna be. But back to cooking, so do you cook from recipes you find online, from your head, from cookbooks, like, where do you get your recipes?

It depends, in different phases of my life. I guess before I had a kid, it was mostly finding stuff online, and really, like, at some point when food blogging really exploded, it was probably about 10 years ago, and that was a really cool time because, like, people posting stuff, and there’s some big blog posts, kind of just making things based on stuff you see other people making.

Well, I mean, I’m a big believer in recipes for that matter.

Yeah, there’s a reason someone wrote down the exact steps, you don’t have to go figure it out from scratch. If you’ve ended up doing something multiple times, then you kind of get a feeling for where you can make the tweaks. But I guess that’s my number one frustration, when people come, like, that’s so difficult, like, remember there’s a recipe, there’s a recipe, someone with a lot of experience figured this out for you.

Yeah, exactly.

But yeah, so I did more of, I’d say, freestyle cooking then. Well, at the moment I’ve got a two-year-old son, and what I’m really enjoying at the moment is that I can get a HelloFresh box. I don’t think I would have necessarily thought about buying it if I didn’t work there, but man, it’s better just getting a box with, like, these are three meals you can make this week, you don’t have to think about that, I feel like it frees up my mind for thinking about actual things that I want to be creative with.

Yeah, well, that box, so I have to say, I spent 2010 through 2020 on the road, me and my wife, and then we settled down, and neither of us cooked, we just ate out all the time. And I didn’t marry her because she cooked or did anything, but then she got started getting the boxes delivered, started having the recipe, the formula, and then she stopped getting it after several months, because she’s like, all right, and the training wheels were up, she started doing and cooking. And then now she’s, I mean, she makes muffins, finds a recipe for a muffin, and then creates a spreadsheet of data, and then iterates on the muffin recipe until she dials it in exactly what she wants for her running and what she does. And so I’m just always fascinated by that overlap between cooking and recipes and tech, so that’s why I asked.

Yeah, I really like technical writing as well. Actually, I guess it’s part of, like, documenting things well enables people to use your things. And one of my favorite things is, if you think about a user guide, it’s actually a recipe, or a tutorial. You want, at the end of that, someone wants to do something, you tell them, like, oh, you’re going to make this, I don’t know, you can integrate this fabulous library and then you have these features, then you tell them the prerequisites, the ingredients, and then you just take them step by step, like, do this, do that, bake at 200 degrees, and then you’ll have this amazing thing. So it’s literally a recipe that you’re giving someone, and so I also kind of like this overlap between writing and recipes.

Agreed. And so I look at a lot of API portals and API documentation, and my positioning is, you can land on a website and read the marketing for an API, that’s one layer, the next is the docs, and then the next is the actual design of the API, and they’re varying levels of truth or honesty I find in that. And I find increasingly people are doing APIs, and it’s kind of like the recipe sites you come across now, where it’s like, here’s a big long story about how my grandma did this thing, and then at the bottom there’s like, oh, well, here’s the recipe, and they do the SEO. And I feel like some people are doing that with technical writing and documentation now.

Oh yeah, that’s a bit too much. I really like what you’re saying, the different levels of honesty in the different kind of material you read. And I guess at some point in my life I thought, like, oh, maybe I like writing, maybe I should look at developer advocacy, it kind of drew me to that role as well, like there’s more honesty in there in my opinion, like the things that are being said, it’s someone that’s actually out there to help people in what they’re doing, as opposed to trying to throw some marketing fluff at you.

Yeah, and that grades of honesty between the marketing material, the docs, and the design of the API, or lack of honesty sometimes, or connectivity, because this is the API product management, is your API and your docs are moving forward with each version. So depending on how connected that feedback loop is, an actually meaningful relationship between the producer and consumer is also in there in the docs. So each version of the docs and the design of the API, if a producer is listening to the consumer and incorporating that into the design, and then thoughtfully creating docs, there’s just this natural smooth relationship between producer and consumer. But the ones without product managers in there, I see, there’s no relationship between the producer and consumer, the feedback loop is non-existent or sparse, and so the design, the tech writing, is just really poor. So product management’s at the heart of it, as I see it.

I love, I guess that’s a part that I like about it as well. In one of my previous jobs, I worked with APIs, and at the point, man, I love designing the interfaces, but I really don’t want to write the code behind it. And I’m like, oh, there’s no job like this, I guess I’ll just have to do product management and other things. But like I said, it’s exactly that thing, you have to put yourself in the shoes of the person that actually wants to consume this, and go like, how would they experience this, what would they think if they read this or that with none of my context, what are the feelings that I would get? And one of the things that I frequently tell people when writing documentation is, remove the word “simply” from any of your documentation, because when you write it as a person who does it, it’s like, oh, it’s easy, simply. The person who reads it, they read “simply,” and when they can’t actually do it, it’s like this cognitive dissonance, oh, should I have done this, am I actually stupid now, that I cannot simply do this? And it’s, yeah, it’s like, it’s that empathy thing, putting yourself in the shoes of the people who use it.

Yeah, yes, the empathy is the important piece. And so, like, my career trajectory is, the 1990s I was a database guy, about 2000 I started building the back end database driven web applications, distributed, and then I saw APIs kind of poking holes in this classic, databases were always that classic power structure within an enterprise organization, and APIs kind of started poking holes in that, and I started getting access to feedback loops with consumers. And I love being out on the front end, and I got really sick of owning production and being a back-end developer, so I became a chief evangelist or evangelist advocate, so I’m very much on that road that you talked about.

Yeah, I mean, but that’s the curiosity aspect, building something is cool, but don’t you want to know how people actually use this? Like, why do they actually want this?

Yeah, or why do they not want it?

Why do they not want it, if you’re doing a bad job? Yeah, I want to know that.

But I don’t think everyone’s equipped to want to know that. Like, some people are like, no, I’m a really good programmer, this is great, of course everyone’s gonna want it.

Yeah, that’s why we’re all different people, we have different things that actually tickle us in our day-to-day. And so I don’t know, do you get strongly, like, the people who like starting things or people who like finishing things, and is it the same, like people who like building that technically, like they want to go deep into the way you created, and those people are more curious about how it’s used?

Yeah, so the evolution of APIs is kind of one of the areas I focus on the most, is how it’s kind of changed our lives, from ride sharing and Uber to grocery delivery to restaurant delivery, and then being able to cook at home, and what y’all offer as far as making it easy. So I mean, is this why you work where you work, or what keeps you coming to work every day and kind of driving what you’re doing, is it helping people cook at home?

Well, the thing is, I feel like I’m very lucky that I can work at a company that provides food products. I love food, I love eating, I like cooking, so I really like the actual end product that we create, I find very intriguing. At the same time, I can work on creating developer products, which is like, oh cool, that’s great, I can do both of this, or it was combined into one company. And then I guess what I really like also about HelloFresh is, I feel like I’ve worked at previous companies where there’s a goal and there’s a product, but it doesn’t really help people. And what I find particularly inspiring, it’s super lame, but my company actually tries to make the world better. Like, if you think about the carbon emissions of getting your food to a grocery store, the amount of wastage involved, there’s so much of that cut down with creating a box and delivering it to your house. Like, I think we’re the first carbon neutral meal kit company or something, and I find that really cool. Like, I’m not working on that side of the business where I actually work with the food things, but it’s nice I can work at a company that actually has this kind of global level impact, and I can still tinker around with dev stuff.

So yeah, that’s, I’ve been dealing with turnover on different teams that I manage, and I’ve had an interview, one of the interviews I did was with Twilio, a VP that worked at Twilio, and he talked about the turnover after COVID. There’s a lot of people who are feeling, you know, it’s called the mass resignation, they’re just not happy in their jobs. And I think in tech, I think a lot of people got into tech because you’re going to make a lot of money I guess, and then the money doesn’t satisfy you, and the tech doesn’t love you or nourish your world. And so it just sounds like, I mean, do you, has this really helped with your mental health during COVID, like having a job in what you care about?

I mean, to be honest, my kid was born like right after lockdown here, so the first year of COVID I wasn’t even working, at home I was just playing, playing with a little newborn. But I don’t know, I guess that also kind of brings it into perspective, like you actually work for a company that does something for the world. And I think when you actually get to the point where you decide to have children, that is also one of the things that kind of runs through your head, like, is it the responsible thing to have a kid, like with climate and people and everything? And I mean, I think at the end of the day it’s a pretty selfish issue, whether you want a kid or not, like you’re not going to save the world one way or the other by having a child or not, but it’s nice for me at the end of the day that I am working at a company that has some ecological impact, or some positive ecological impact, as opposed to, I don’t know, any example, it was just going to be rubbish. But yeah, it’s a nice aspect, you can feel like there’s some meaning in your work that you’re doing.

Yeah, I think, but I think having kids is another meaningful part, so you gotta load balance across these things, having a family, having the meaningful things, but also work that matters. I, the first year of COVID, I shipped my daughter off to Seoul, South Korea, she’s doing university, and she’s actually just coming back next week, I haven’t seen her since. And so I spent the first year just stressed out that my daughter’s in another country, and it was rough, but she did well, she’s good.

Must have been intense, yeah.

That’s good. So this is the first time you’re seeing her since like the beginning of COVID?

Yeah, I haven’t seen her, it’s amazing, and it’s her first time out of country, out of home, everything, and so with COVID on top of it. So I mean, she’s a woman now, and she does, you know, amazing things that just kind of blow my mind, she’s not the little girl that she used to be, so it’s a whole different world.

So yeah, I kind of find it interesting that when you have a kid, you go from being a very independent person, and then suddenly 24 hours of your day is dedicated to keeping this thing alive, and it feels to me like just the exercise of actually being a parent is just learning to let go from that point. Like, we have to tightly keep hold of this little thing to keep them alive, and then learning how to just let go progressively.

Yeah, yeah, which is a very cruel kind of trick of nature, and it keeps getting weirder, just wait, just wait, with your little boy.

Yeah, I’m not even that far into this journey.

With little boys too, it’s a whole other game. And with my daughter, it was just, as a father it was just really hard to let her out in the world right now, but, you know.

As if the world isn’t a scary enough place.

I know, like, right during all the MeToo movement, like everything, I’m like, all right, daughter, go out into the world, COVID, MeToo, like, yes, you know. But it’s worked out well, she’s coming back, she’s gonna finish her senior year here in the West Coast of the US, so it’s good. Staring back, no, that’s good, I love these little side journeys. So what’s new and interesting trends, what’s innovation look like at HelloFresh, what are you looking to do that would push the boundaries that you’re not normally doing?

Well, I’ll answer that. I guess for me, I’ve been with a platform team at HelloFresh for a long time, well, more than four years, and being on this journey of taking it from a loose connection of developers doing things and building this into a proper, product-led, let’s say, platform organization, that’s kind of what’s occupying my mind at the moment. And I think it’s interesting, I think probably two years ago I would have told you, like, we’re a really product-like group, and as I learned more, I’m like, maybe there are some more things we can do, there’s some better ways. So in the platform space, I think about product managers, thinking about developer products internally, I think that’s a big thing that we’re focusing on at the moment, like how can we make a really strong product organization for internal developer tools, which I think is a really cool thing.

Yeah, yeah.

So tech-wise, I think there’s, as tech changes, I’m not sure if I can wow you with anything technically interesting. There’s a blog post, I can’t remember who wrote it originally, but it’s about, like, build boring tech or something, and there’s a follow-up post about it, like, in platform teams you actually have to think about boring tech a lot, because you’re kind of at the front line of what happens in tech, so you spend a lot of innovation tokens in the company, but it means your responsibility is to make it at least use boring tech, don’t overload the cognitive load of the rest of your org with leading edge things, give them interesting things but sort out the interesting things yourself.

Yeah, and so again, back to the honesty and pragmatism, that was more people-oriented, what you just talked about, and products and customers being customer first and all of that. So does all that involve dealing with legacy? I mean, when you talk about boring, mundane work, I mean, moving forward your legacy infrastructure along the way.

I guess, as a company, HelloFresh, we scaled very fast in the beginning, and I think the company was very successful because we moved fast, and that brings some sort of a lot of legacy things. So I guess there’s always these things about, right, dismantling our monolith, some other things. And what’s interesting, I think when we started with Kubernetes, we were also kind of moving fast at that point, so I’ve recently just had a conversation with the squad that’s kind of maintaining Kubernetes, and when we moved fast it was great, we migrated the whole company into Kubernetes in about six to nine months, but now we’re dealing with, like, what is the next scaling challenge. Like, we’ve kind of got the single cluster set up, and in the future this will probably hold for x amount of time, but if we want to go to the next step, there’s a lot of refactoring and dealing with technical debt we encounter ourselves to kind of get us to the next level. So yeah, it’s not sexy work, but it’s kind of going back with previous decisions that were made to optimize for speed, and now kind of re-looking at them and, like, how can we optimize now for sustainability or scalability of our platform.

Yeah, no, I think you’re right in alignment with some of the other people leading in the conversation across the space, and federating regions globally, edge, kind of scalability being closer to the customer, that kind of thing, performance, a lot of that stuff seems to be the next.

Yeah, and it’s interesting, I think, like, the design decisions maybe initially weren’t that in mind, but it’s just becoming so apparent, like, if we don’t solve this problem, I know we’re going to shoot our future selves in the foot.

Yeah, yeah, lots to learn there. I mean, I think you guys are right in alignment with the other, I would say, API economy as I would call them, game changing ones that have, you know, I had a conversation with 7-Eleven, the convenience store chain, and how they went API first to deliver alcohol and respond to COVID, getting alcohol into everyone’s house and do that globally, but do that with regulation too, because there’s alcohol regulation in different places. How do you scale that, not just technically, but scale that business and legally, I think is an interesting conversation.

Oh, that’s super interesting.

Yeah, and I think about it, like, a lot of times we want to solve every problem with tech, but more often it’s not a tech problem, it’s a people problem.

Yeah.

Well, I have a Venn diagram that I created in 2012, because I worked in the Obama administration and I did APIs for the federal US government, and I see it as tech, business, and politics as a Venn diagram. Because your API can be perfectly designed, but if it doesn’t have a business model, you’re in trouble, or if you haven’t gotten the right licensing, or there’s other legal or regulatory, you’re in trouble. So it’s that kind of relationship between those areas.

No, man, like, straddling, having a foot in each of them makes you successful.

Yeah, well, I liked your view of the landscape because it was very people-centric, product-centric, customer centric. You talk more about that than, you know, we talked a little bit of Kubernetes here, but that’s really, I think, what this show is about, because this is really trying to reach leadership, we’re not trying to get to the nitty-gritty detail. So I really like your view of the space, I think it’s healthy and pragmatic, and I appreciate you coming by today and sharing it with us, I enjoyed this.

Well, it’s a pleasure. Yeah, I think I guess pragmatic is kind of the highest compliment you can give me, so I appreciate that.

That’s why, I can see it, because I see a lot of people who are technically very geeky, geek out on this, and I’m like, well, wait, there’s, this is a world we’re human, and your tech’s gonna collide with that human reality, and I don’t care how perfect it is, so you gotta kind of tone it down, be a little more pragmatic.

Yeah, it was a nice conversation, thank you also for inviting me, we delved into areas I didn’t expect for an API related podcast, but it was fun.

That’s what this is all about. Thank you so much.

Yeah, thanks.

Thanks again to Jessica for stopping by. For more on Jessica you can find her on LinkedIn, and you can learn more about HelloFresh at hellofresh.com. You can subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host, Kin Lane, and until next time, cheers.