Great to me. Good afternoon. Um, I'm Ben Grinnell, um, work for North Highland, but I've been on the DevOps organizing committee here for, um, probably about eight years. I've been to every DevOps summit and love learning lessons.

And obviously I haven't seen your talk yet, but, uh, do you wanna introduce yourselves? Yeah, so my name's Rich Day. I'm a software engineering manager at Marks and Spencer's. Um, been with the organization about 18 months now.

Um, I look after quite a few teams, um, in my time, but, uh, currently looking after, um, the kind of checkout basket team and our Christmas foods order team as well. So it's always Christmas in my world. Excellent. What a segue.

I, I don't, I dunno how to take from that. It's not always Christmas in my world, unfortunately. Um, hi, I'm Lee. Uh, it's a pleasure to meet you all.

Um, so I'm a staff software engineer at m and s. I've been there for about 10 months now. Um, what to say about me? Uh, so I've got a particular passion for DevOps.

A real focus for me is C I C D, how to make things quick, how to make that developer experience really slick. So that's a, that's a little bit Excellent. Well, one of the things that really interesting about your talk was, um, I've been, as I said, organizing these summits for a long time. And the vast majority of our talks are from people who move from a heavily outsourced to insourced environment as they achieve their DevOps goals.

And I'm looking for stories where people have made the outsourced environment work, um, and you've got a heavily outsourced environment. So keen to just have a chat around how that works, uh, where the challenges are, where, where you're seeing successes and things like that. Um, so do you wanna describe the, the makeup of your people workforce, just to make, if I understand that? Yeah, Of course.

Um, so our journey started about two years ago, I'd say. Um, and at that point we had about 95% of our tech and our digital and tech workforce outsourced mainly in India, mainly in Chennai, um, using a consulting company. Um, and that brought with it a lot of challenges, as you might imagine. Um, we had large teams, 40 to 50 individuals who had no real autonomy, no ownership, and a lack of accountability, just these really large teams.

Um, and so we weren't really getting a lot done, so we decided to bring as much of that back in-house as possible. So over the last couple years we've been recruiting heavily and rich, why don't you talk a little bit about how that's helped us in the recruitment process. Yeah, thanks Lee. So we, um, we've, we've built a really, um, strong multi-stage recruitment process.

Um, we focused heavily on our culture, um, and we wanna make sure that we have people that are the right fit for our teams. We want to build high performing teams as quickly as we can. Um, so the culture part of that is very, very important to us. We do focus obviously on, um, on the technical aspect as well.

We want really strong engineers to come and join us. Um, but the culture part of that is, is really important to us. Um, and we protect it quite fiercely. I think at m and s we are, um, we are very keen to ensure that we get the right people into our team so they can be as productive as quickly as possible.

Uh, just add a little bit to that. Um, creating teams where psychological safety is the bedrock effectively, which allows us to really, um, promote change and embrace the, the risks and the mitigations that have to happen when you are transforming or transforming from fully outsourced to in-house. When you've gone from a lot of your technology not being owned to by you, the code quality isn't always there. The structure, the architecture's not always there, so we wanna migrate that, but you don't wanna go big bang, you don't wanna do it all overnight.

That's how your website goes down. That's how you lose your revenue sources. So how do we make small iterative changes together? And that's been a big part of our journey as well.

As we brought those people in, we've created our safe space where we could say, Hey, it's okay to fail because we're gonna do it in small steps. If there's a mistake, it's okay. It's not the end of the word world. And we have really strong ways to mitigate, roll back and structure it so we create the environment they need.

Excellent. Good dear. And you said you focus very heavily on the culture. Um, what do you think when you, when you're looking at recruitment talent that you're thinking of getting in, is it easier to train the, the, the technical practices or to change the, the culture of the change, the, the way the person works, do you think?

Um, I think, I think it's, um, it's almost easier to train the technical practices, um, because they're, they are very, very defined, very kind of, um, empirical. Um, the softer skills are much harder to, to teach and, um, to find engineers that have those, have that ability, those, those things that they, that make them excellent software engineers and not just the technical stuff. Um, finding those people is, is, yeah, is key for, for us. And, um, that's the, that's the hardest thing for us to teach out.

Yeah, no, I agree. I'm reading a book called Unlearn at the Moment, which is a great book for, it's harder to unlearn than to learn sometimes. Um, you mentioned you were 95% outsourced to start with, and, uh, I always looked at organizations where I've helped them make an outsource model work and thought that if you haven't got at least 15 to 20% of the team in house and you haven't got enough skin in the game to do anything apart from managing control, uh, and you, you know, with DevOps it's always been all about collaboration in one team. But if you are, if you're, so, if your permanent team is so small, you can't do that.

So as you grow that team and you are more able to collaborate with your outsource partner, are you, are you trying to bring it all into one team? Have you got, have you got a destination in terms of what sourcing model do you think you want to be at in the future? Is, has that been agreed? I think we're still working through that, aren't we?

We're, we're still, we're, you know, we're still trying to bring as much kind of in-house as possible. Um, but there will always be a place for kind of outsourcing and, um, you know, we work extensively with our partners, um, to provide talent into the teams, um, to get the job done. And, um, it certainly gives us a lot of flexibility, allows us to kinda spin up and spin down teams much more quickly. Um, and we've done a lot of work with our partners to, to make sure that we're getting the right sort of people through the door to help, um, on those journeys that we're, that we're building.

And the, the teams themselves are very receptive to that. Um, and they, we treat our, one thing that's really important to us actually is that we, we treat our, um, partner colleagues as if they are colleagues, they, there's no distinction as to as to where they come from. Um, or even if they, you know, they're working on site or remotely, we see them as part of the team. They're part of the team.

We care about them as much as we care about our, our perm colleagues. So, you know, it, it's really important to us that a team is a team, um, and not just a bunch of perms and a bunch of people that, that are kind of come from a contract partner. Yeah, Just add a little bit to that, which is, um, we still have and want some, um, teams which are fully remote, which are outsourced. But what we've done over the last few months is we've changed the motivation.

So it's no longer, hey, we wanna keep things perfectly stable because that doesn't get us the outcomes we want. It's not, we just want 10 people on a desk somewhere. We want things which actually impact change. So we've changed the, um, reward mechanisms to say, Hey, these are the metrics we want you to go after.

We actually want this team, but we're outsourcing to focus on 1% revenue growth for this sub area. And that's changed it from a very much a developer experience and an operations experience, keeping 'em separate to them generally coming together and owning that problem, which is again, change the narrative. That's brilliant. 'cause um, there's a couple of things you mentioned that made me think.

One is in Europe and the UK the the need for flexibility isn't helped by the employment laws. And my colleagues in the US and some of the speakers in the US don't understand why we need the interim labor, but, you know, it can take three months to spin up a team over here. Um, so recruitment's not quite as agile as it is in the, in the US at least, and that's a big difference. Um, but the other thing is, um, change those metrics.

Um, when I've looked at organizations that are on the same journey you're looking at, I think one thing is critical. It's the leaders need to be in line with what you're trying to do. And the people involved in the leadership that you're talking about are the C I O, the C H R O or the C P O and the chief procurement officer. 'cause someone's procuring your outsource partner.

And when you try and get them to procure based on 1% outcomes and things like that, it's a, it's a difficult, difficult game sometimes because a lot of it's based on, well, what's the rate card? Um, and then if HR ISS trying to grow your capability, you need your partners to be not competing with that. But helping you build that capability and building that into a contract is quite difficult too. So getting those three leaders aligned is often I find quite difficult and often not given enough attention.

Any comments on that? Um, I, I think whenever you go through a digital transformation, leadership alignment is absolutely key. And it's not just, oh, we are aligned, we want transformation. It's actually having those workshops, putting the time aside, making sure the meetings are happening so that they can hit all of those kind of key points you, you mentioned and more.

Um, and if that doesn't happen, the message gets diluted, the processes, structures start to fall apart. So transformation has to come from both the top down and the bottom up. And that requires a leader, uh, alignment of leadership at every level. Yeah.

So what's the, do you know what the, the sort of size of the team is now? Do you have, is it a, when you've got your mixed teams, is it an 80 20 split now? Or how many perm people do you have in the teams that you It's Quite, it's quite tricky 'cause um, a lot of the teams are, um, kind of set up very differently. So we have, sorry, we have, uh, we have fully perm teams, um, and we have, um, fully outsourced teams as well.

So, um, it's quite hard, um, to get a kind of a view of that across the organization. Um, the recruitment team are working really hard to, to kind of try and dashboard that for us so we can, we can see much better how, how our, our teams are, are the makeup of our teams. Um, but on average, I would say there's probably, it's, it's tricky. Uh, we, we are looking at maybe kind of 60% perms, 40% contract.

It's Around about 50 50 mark the moment. We wanna bring that to a higher mark. Definitely. Yeah.

So I think it's around about 50 50 mark. Um, some the teams we especially work with, uh, about numbers much higher. We have, you know, 18 90%, um, in-house for the teams we personally work with. Um, but across the organization, probably more about 50 50 and wanna continue to grow that going forward.

And when you look at the, the teams that are diverse, um, one of the main cultural differences you see, um, people tripping up over or the teams tripping up over in terms of how people work and what norms they're used to? Oh, that's a, that's a really good question. Um, you know, I'm gonna, I'm gonna give you a very simple example. Um, one of the, I've had a conversation about in the last couple of days, which is we're now in a remote working world in the uk.

Um, and working with our colleagues in places like India, um, that's especially true keeping, uh, your teams or your Skype or your Slack calls video on, right? A lot of our Indian colleagues don't have 'em on all the time. And, you know, this is a cultural difference, but it's not actually just a cultural difference, it's a technical difference, but bandwidth is an issue. So, you know, I personally love seeing people face to face.

I love having conversations and that's, uh, one of my personal challenges. But as soon as you understand the why, it becomes quite obvious. Um, whatever kind of challenges you think we've, and cultural differences, I think just the, the actual kind of being able to build a team, you go do some of those team building exercises and, um, when people are fully remote, that's, that's much more difficult. And you have to be much more creative in trying to get to know your colleagues a little bit better.

Um, so we, our teams are quite good at, uh, have got quite good at being able to do that as they've been forming. And, um, we, we have, you know, some fun games as part of our standups or, you know, retrospectives to, to really try and bring the team together, find out about our colleagues a little bit more, find out about their, you know, what makes them tick their personal lives. And I always find teams that care about each other, um, really are get much faster to be a high performing team. If your colleagues care about you, um, and you care about your colleagues, if they're struggling, you are gonna be willing to go and, um, help them out and try and find a way, um, to help their day be, make their, make their day better.

And, and I think that's really important with, with a high performing team, is that the bedrock of all of that is that they actually really care about each other. So one of the most important things for me in trying to build those teams is making sure that we have those kind of team building exercises where we get a chance to really know each other and, and, and care about each other, because otherwise it makes that whole, um, that whole journey much more difficult. And that comes back to what you said earlier, it's about treating them as a member of your organization, not an outsourced member, which means that you do care that you, you have those conversations. It's not about them delivering the next piece of work, the next piece of work.

You treat 'em like humans. Yeah, there were some great points in the talk earlier on psychological safety around if you haven't got a culture where if you haven't got to the point where everyone in the team feels like they can speak out, then you're wasting that diversity in your team. Um, and Jag pal spoke earlier on his talk around the suppliers, managers feeling like they had a seat at the table. 'cause quite often you don't get that challenge, you don't get the challenge back.

You get people doing what you asked for, um, which isn't necessarily what you want. Um, also what you need. Um, so have you encouraged that sort of bringing, bringing that when you've got those cultural barriers and those contractual barriers to doing that sometimes? Yeah.

Um, you know, um, I think I can speak for both of us for this bit where I say we truly believe psychological safety is, has to be about bedrock. Um, the way I've personally, uh, found really successful is starting with saying, Hey, I made a mistake. Whenever you make a mistake, put your hands up, talk about it, clearly, openly embrace the mistake and how you mitigate and makes things better going forward. So you start shifting the conversation from no, you haven't done this right, or you can't do this to, yeah, everyone makes mistakes, let's make things better.

Let's focus on our process, our people, our projects, our technology. It's not about you failing, it's about we as a team getting better. That drastically changes the conversation when you're talking about psychological safety. Um, so that's one of the ways that I've found which have you got malted?

Yeah. So, um, don't shoot the messenger. That's a really important one, right? If someone comes to you with a problem and says, I've found this, we need to fix it.

Like, don't shoot that person because they are, they're the one that has had the courage to come up and say that. Um, and as soon as you start to, you know, apportion blame or use blame language, um, you start to build a blame culture. And that's really, really unhealthy. And people will just clamp down, um, and they will stay in their lane and they will do their thing and they will just try and get through the day.

So that openness and honesty and being willing to admit that you made a mistake and leading by example and saying, you know, it's okay to fail. Um, failing gives us an opportunity to make good decisions in the future because we have that experience now. Um, and there's a, there's a very old overused possibly kind of adage about, um, only, um, bad decisions give you experience and, and the only way to make good decisions is through experience. I've, I've probably mangled that horribly, but, um, it, it's, it is quite true.

And, and if you haven't had the ability to fail and learn from that and be supported through that, then you're not gonna be able to make as good decisions in the future. Um, and, and if you don't have that environment of safety where people can admit that and say, I was wrong, I need help. Um, you know, can someone else, can someone else take a look at this and, and make some suggestions? I'm stuck.

Um, you know, you're, you're not gonna have that, you're not gonna have that, that psychological safety that you need. And, and we've kind of implicitly talked about, you know, when things have gone wrong, but it's also about building new things, how we go and improve and create better environments, right? So it's about uplifting your engineers, both at home and abroad, thinking not just, oh, I know the solution, I'm gonna tell you. It's asking why.

Hey, has anyone else got in this team, got any ideas? Can we, can we, uh, boun these back and forth? Really start making a discussion, pulling those external colleagues into those discussions? And that starts adding to the psychological safety starts adding to the feeling of inclusion, which then changes it the narrative and, and makes them more willing to speak out for future things.

That's great. There's two things that I love about and I've learned from these conferences. One is I love the way right from the first one I went to back in 2014, Jean Kim made the speakers have three things they still need help with on the last slide because it really breaks down that I'm not an expert presenting to you. I'm a person on a journey and a learning journey, and everyone here is on a learning journey.

So I think having those three questions, brilliant. Um, and the other thing is the talks I've heard from John spo, um, when he talks about, um, blameless retrospectives and just getting rid of that, something's gone terribly wrong. The presumption is someone screwed up. And actually it's always the system.

It's never an individual, it's always the system. And I think just switching that presumption at the start of when you're looking for a root cause you're looking for the system, um, it's really helpful. Something, um, that's something actually that, that we've done quite a lot of just recently is we've been doing a lot of pre-mortems for things. So, um, if you're not aware of what, what a pre-mortem is, I would definitely urge you to do a little bit of research, find out.

But essentially you ask the question in advance, um, you assume a worst case scenario in advance and say, um, we're six months down the line, we've gone live with with X, everything's gone horribly wrong. Nobody can make any orders on our website. Um, we can't fulfill anything. Um, what happened?

And then you start doing that exercise, that kind of, that five Y's exercise and the conversation that comes out around that because it's a non pressured environment because it's, because it's not actually happened. People are a lot more free and a lot less focused on trying to, you know, fix the thing or apportion blame. Um, it just becomes an exercise in, uh, like a, a thought experiment almost. Um, and that's a really, really powerful tool to help you see problems in advance, um, and get your teams used to thinking in that way for when they, um, when they actually come up against that thing that think for real.

Um, and we've, we've had some really good conversations that have come out of some of the pre-mortems that we've done. Great, thank you. Um, if we switch to m and ss for a minute, and, uh, you've got lots of examples of really good teams that are working well, um, and in a lot of organizations they get stuck with that with lots of flashes of brilliance, but not actually able to scale it. So as you scale that and I guess make it easier for those, you've had some brilliant teams and they've got there, but not every team can be brilliant from day one.

So how do you help the others follow the trail and therefore make it scale? Um, 'cause if those first teams butt up against the governance, they get passed to break some of the rules. Um, how do you, how, how, what have you done to make those, those trailblazers easier to follow? Um, Yeah, what have you changed those, those trailblazing teams have a, have a hard job because, because they, they find a lot of things that, um, that other teams won't have to deal with.

And, and it can be a bit of a thankless task sometimes because other teams won't realize the, the, the problems and, and the effort they've had to go through. Um, something that we've, something that we've tried to do, um, is rotate people through teams. So as we're we're, we've been working on a new, a new tech stack. We've been moving, um, our old tech stack for, for our m.com website over to, um, a new framework that includes reacts and NJ, react and, and X jss.

Um, and as part of that process very early on, we've been rotating people into those project teams from other teams so they can get some experience, they can understand and they can see some of the challenges that those trailblazing teams are, are kind of facing. And we've had some really, really good results with that. And it's also, um, you know, some of those teams have been really high performing and having people come into those high performing teams and seeing the culture, seeing how it works, seeing the, um, the traits kind of firsthand of those high performing teams has been really helpful because then they can take that back over to their, to their, their home team, if you like. Um, and they can start talking about all the brilliant things that they've, they've done and they've seen, and they can introduce new ways of working.

And also we can, you know, the, the teams that come into come into, um, people that come into those teams have an opportunity to, to bring their knowledge with them and, and the high performing teams, the the ones that are the trailblazers, the ones that are leading those, the charges, they can, they can learn from that too. And we can really kinda spread the knowledge around the organization. Um, two bits to add to that. Um, one which you kinda mentioned, it's a journey.

Each team matures at its own rate. And if you appreciate that, it's not, we need you to be a high performing team tomorrow, it's, you're gonna get there at your own time, in your own pace. Every journey is different. How do we support, how do we support, how do we help, how do we make that possible?

Um, so that's a big part of it because there's no not, you are, you are not one of the high performing teams that's, you are failing, you know, that instantly puts people down. It's, Hey, how do we make it better for you? How do we help? Where are you struggling?

And high performing means different things for different people and different teams have different ways of being high performing. So really embracing the, that uniqueness, I think it's a important bit. The second thing I'll mention is processes, right? We've already mentioned it's not people that make mistakes, it's processes not being good enough.

So we put in guide rails. Um, a lot of this has to do with paperwork. Some of it's, um, our funding model to make sure that we're getting money in the right way so we can get the right teams spun up. Um, some of it's, uh, what's our DevOps maturity model, you know, what things do we believe you need to do to be heading in the right direction for those incremental steps?

And those processes haven't been made in isolation. That's another really important part. It's done collaboratively across the business so that as we are doing our DevOps journey as engineering, we're bringing the rest of the business on board with that journey and getting them excited about the transformation as well. And that means that everything gets a little bit easier going forward.

Excellent. And you talked about moving people between teams and moving teams a lot. Are you imagining to do that all without having to do a dreaded reorganization? I'm gonna give this one to you.

Um, we've had, um, we've had to do some, some reorganization. So, um, we face m and ss as, as many retailers in the UK are now facing some difficult headwinds. Um, there's energy bills that are going up, adding a, a huge amount of cost, uh, that nobody expected sort of 18 months ago. Um, and, um, inflation cost of living, all of that is really contributing to, to what we've, um, to, to some of the headwinds that we are, that we are facing.

So it's, we've had to go through some kind of a reorganization to make sure that we're, we're working on the right things and we're delivering the right value for the business. So some teams have had to get broken up, some teams have got, got moved around a little bit. We've tried to retain the core principles of, of those teams that, um, that have been moved around and, um, and move people together so that they are, um, they at least have some familiar faces and they can start to come, come together as a team a bit more, a bit more quickly perhaps. Um, so yeah, we've had to do some reorganization, um, uh, through the course of the last couple of months, but we feel that we are in a really strong place now.

We've, we've identified those value streams that are really going to help drive the business forward, and we are making sure that the right people are working on those things and we're prioritizing the right things. Excellent, thank you. And, uh, as we look at growing, hopefully moving into growth again, um, you're, there's a, there's a big war of talent with people that know how to do this stuff. What's the balance you are doing in your recruitment between, um, hiring talent that knows what they're doing and growing your own and how you're integrating the two?

Yeah, that's, that's a really good question. So, um, career progression at m and s is really important and, um, it's a, it's a key part of, um, our engineer's journey, um, during their time with the organization. So it's most important to us that, that we have a very clear career progression framework. Um, we revise it quite regularly.

We've just gone through another round of, of looking at it and we're gonna be releasing something to our teams, um, over the course of the coming weeks, um, to really help clarify some of those steps, um, and clarify what those, those roles are that are available that they can move into. Um, so it's, it's important I think that when you are, when you're hiring, you're hiring for progression as well, you are, you're not seeing just, you're not, you're not only seeing the thing that the person can do at the moment, but you're seeing the potential in them and seeing what they can grow into and then finding good ways to support that. So all of our engineering managers at m and s have been, have been challenged with, you know, making sure that every individual has a proper decent development plan so that they have, they can track their progress, um, forward through the organization. They can see what things look like for them, um, in the future and the sorts of things that they're gonna be working on their responsibilities.

Um, so yes, we do want to hire amazing talent. We always want to hire amazing talent, but we do have a responsibility and a, a passion for growing that talent internally as well. And we are, we are hiring for progression as well as, um, you know, the things that people can do right now. Excellent.

Thanks. And as well as, um, competitive pay, I think that you've got a great brand to work for, which is gonna be very attractive for you. And, uh, people like to work for a sense of purpose. I'm also seeing quite a lot of other recruitment tactics, um, especially in it, um, Topo Powell spoke about, um, uh, I think went into the Capital One open sourcing some of their, uh, work, uh, and celebrating some of the successes quite openly, the technology successes that is, so developers who were great wanted to go there and be famous for what they'd done.

Are you doing anything above and beyond the normal recruitment to attract talent? Like those things? Yeah, so we've, um, m and s has, has open sourced, um, a couple of our own plugins and other bits and pieces from the things from the web teams that we've been working on. They've been quite popular on GitHub.

Um, so that's great. That's getting our kind of name out there. And, um, we were talking, we had a, a leadership team, a leadership team meeting last week, and one of the, the topics of conversation was, you know, empowering our engineers to go out there and, and do some of these talks and, and come to events like this. And, um, you know, that's really important to us.

It gives people a sense of pride in what they're doing, um, give them an opportunity to be known more widely than, than they would, would otherwise normally be because they have a bit more of a platform to come and, and, and speak to people about some of the amazing things that we're doing. So I think that's a really, really good thing. And it's a really timely thing for us as well, because we are, it, it's something that we are really interested in making sure that our engineers have the opportunity to do if they want to do so. Excellent.

Thank you. Um, are there any other successes or learnings or things that you're trying to do that you want to talk about? Um, this completely open question, big things in your talk. That's a very big question.

Do you, do you wanna, again, uh, I don't know if there's, there's potentially so many. Um, you know, a a big thing for both myself and Rich is that culture, we've already mentioned it so many times. Um, I think another big thing is really worrying about putting the time and love into your platform, right? Making sure you prioritize that and the, the developer experience.

Um, you know, we've had challenges there. I'm not gonna lie, we've, we've grown rapidly. It's a two year journey, but making sure that we've, we've pulled all those people in and having those conversations at every level. Um, so for me, that's one of the, the places of pride I suppose, that we've come together and created something quite exceptional.

Um, and we've gone from, I can't remember the exact numbers, but our, our, um, deployments have gone from, you know, every couple of weeks to multiple times a day. Um, and that has been because of just everyone pulling together. I think that's what, for me at least, marks and Spencer's compared to a lot of places I've worked at is very different, but everyone is so very friendly and it makes it a lovely and wonderful place to work. Yeah.

And I just, I think there, there's a, there's a lot of love for, for m and s and, um, the British public really loves m and Ss, um, and our our colleagues love m and s too. And I think, I think that really comes through in, in the things that, that you see that happening within the organization. It's not a tech win, you know, this is like an organization or a cultural win is that we have, we have direct access to our, our, our c e o and Co c e o, you know, we can, we can submit ideas directly to them, um, and they will review them and, um, talk to a panel of other experts within the business about the validity of their ideas. Anyone within m and s can make change, um, if they, if they want to.

And I, and I think the love that people have for the brand within, within m and s is, is so strong they really want to see it succeed. So you have thousands of ideas coming through every month, um, to, to Stuart, our, our c e o and, and he reads every one of them and he responds and he will get the teams to, to focus on those things. We have hackathons within the organization, so, um, we've got one running this week. Um, and, um, my lovely team, hi, um, are are gonna be working on that, um, across the next course of the next couple of days.

And we've got a chance to really look into some really interesting technologies that will allow us to, to progress and, and move the business forward. And people that win the hackathon, they get funding to go, to go forward and, and take their ideas and, and make them a reality. So we have an opportunity to change things within m and s. Every person can do that.

And I think that's, that's incredibly powerful. That's brilliant to hear. And obviously you're in a very, very competitive market and you spoke about the headwinds in that market at the moment, so everyone's feeling the squeeze. Um, it was really impressive to hear how much you've invested in making the developer experience better, because the first thing to go, um, tends to be, okay, the business need this, this, and this done.

You need to get rid of this bit of technical debt, you need to improve the pipeline here. You need to stop everyone swimming in treacle here. Um, most organizations really struggled to prioritize that. How have you managed that?

We've, we've built some of it into our OKRs, so, um, you know, ok, ours that we've had over the course of the last couple of years is making sure that teams have budgeted to focus on removing some of those problems. Um, and, you know, ultimately you make the developer experience better, the developers are more efficient, they're more happy, they're more productive. We get through things faster. So if we can, there's, we can strike the right balance between building new features and removing some of the, the learnings that we've had.

I, I guess over, over time. Um, and and improving that developer experience, then it just means that everything goes, goes a bit, a bit quicker, a bit smoother. But, but I wanna kind of point out, you know, this isn't plain sailing, right? We, this, it sounds glorious when we put it like this.

It's not like that every day, uh, is a challenge, right? And that's okay too. Um, not always do we give a balance, right? But it shows out really quickly if we're steering too feature heavy, um, rather than focusing on our developer experience.

Well, we do get stuck in the mud a little bit, but the important thing is we identify that, use that feedback, and then recorrect and direct ourselves to a better path. And it's those micro corrections which make a real big difference. Yes, it's bake into our, our philosophy and our OKRs at every level. But that doesn't do it on its own.

It's that day-to-day interaction, constantly sharing, steering the ship back to its course. So a lot of organizations have the, the feature project and then the DevOps project that Dex deprioritized. It sounds like you were building some of that enhancement into the OKRs that actually run the product. So you haven't got that competition for feature budget versus tech debt budget, is that what I heard?

Uh, exactly. And so each, you know, feature team, that's part of their, their world. And then we have platform teams and enabling teams and we recognize internally how important they are if we don't have platforms where we can build things quickly, where we're gonna run out of, you know, runway basically. Um, so we've structured ourselves in a way for success as well.

Great. Well that's been really interesting and I really look forward to hearing your talk tomorrow. Fabulous. Thank You very much.

Thank you. It's lovely to meet you.