Nick Tune

[00:00:06] Thank you very much. Uh, good afternoon, everyone. I'm very happy uh to represent Theodo today, and as a sponsor of this amazing conference. Um, so I'm Fabrice Bernard, I'm the co-founder of Theodo. We're a tech consultancy of about 700 people based in Paris, uh London and Casablanca. And uh I'm also the co-author of a book, The Lean Tech Manifesto, which is about how to maintain an agile culture when you're scaling a tech organization based on our experience, but also based on 12 years of studying lean thinking and studying what uh the best tech companies do to maintain their agile culture. So you might wonder why we put this strange character on the cover. If you don't wonder, I'm still going to explain why.
[00:00:58] So this is uh a Chinese character in Japanese, it's it's pronounced Hito, which is the character for human. And it was important for us as a character, not only because of course when we talk about Agile, we talk about uh you know, empowering people to be more innovative, to to have more autonomy. But also because it's actually a very important character in the history of Toyota. Toyota being the company that inspired lean thinking. Because from a very early on, and I'm talking about 1900s, uh Toyota uh realized that there when you talk about technology and automation, there's a good way and a bad way to do it. And to really um differentiate both, he decided to create a new word. And the way you create new words in Japanese is you add characters. So the word automation was replaced with a word that is called Jidoka in Japanese, was replaced with a word called Jidoka. So for us, we don't understand the difference. But for Japanese people, it's very clear because there's another human character that was added in the middle. And so that's why if you go to and visit a Toyota factory and somebody explains Jidoka, they will say, it's automation. Because that's how they, you know, pronounce the difference. And I think with AI now, this this topic of what it means to good automation, enabling automation is very important. And I and so for us, clearly, the idea was to say that Lean Tech is about the lean culture, so empowering people with the right culture, but also providing people with enabling technology. So I'll just give you an example of what is not enabling technology. Um so this is an example of a mainframe application um that was the cause of a gigantic bug at City Group. Um so the port operator wanted to transfer, I think it was something like $81. Um but by default, the amount was filled with 15 zeros, and he was supposed, the person was supposed to delete the 15 zeros first. And at that time, the person forgot to delete the 15 zeros and so instead of $81, they successfully transferred $81 trillion.
[00:03:10] And so it's it's a I I love the example of course. This really happened by the way and it really, I mean, City Groups said don't worry, we didn't have the money so it would never have arrived at the destination, but yeah, still. Um and so these are these are extreme examples, but actually when you look at how we when we interact with technology on a daily basis, uh often it's it's really horrible. It's framing us to do really weird things uh just to like kind of be able to do what we actually want to do. And that's really an issue of technology. It's often not enabling, but on the contrary, really making our lives harder. So the good news is, uh AI is not just good for a Ghibli uh pictures. It's also actually quite a game changer for monetization. We've experienced it on multiple projects already. Uh with spectacular results on the really the translation part, so the code translation. Um so just to show you a few it's quite agnostic. So we've migrated native mobile apps to React Native, we've migrated uh some 4GL technology from the 2000s into Spring Boot Angular, we've migrated Eclipse RCP to Spring Boot Angular, we've migrated Node to Node, etc.
[00:04:20] Uh so it's not magical, clearly, if you just push the whole thing in an AI, it's not going to work. Uh but it really accelerates uh the engineering part. So if you manage to really um slice your legacy into small components that you can map to uh the target architecture and then for each mapping write the good prompt, interate on a very good prompt, that's when you really uh gain amazing uh speed improvements.
[00:04:50] Um I'm finished, so uh two takeaways. First, you can come visit our AI monetization OPA. We're in uh in Paris. We're in Boulevard de Batignol. If you don't know how to ask for the visit, it's quite simple, you go on LinkedIn, you find me and you message me. And if you're really 300 people to message me, I'll find a solution. Uh but I'll still be very happy. Uh and the second thing is after Nick's talk, uh we will actually provide a few copies of the Lean Tech Manifesto. So you you can come to our booth, the Theodo booth. Thank you very much, and now I'm very happy to introduce Nick.
[00:05:31] So, I need to do some talk before he installs his computer.
[00:05:39] So, it's it's my fault, I decided to invite a simple engineer. Like he love to say. So, but it's a bit more than that, he's a amazing writer, if you don't follow him on LinkedIn, follow him every day, some amazing story. And because he loves to write, he has written a very good book called Architecture Modernization. It's a too long book. How many pages?
[00:06:06] Uh, yes.
[00:06:07] No. No. Oh, yes. He speak French. But I don't know if he will try to do it in French. Um, how many pages do you have? No, it's too, it's too focused. It's a simple engineer. Can't do both things.
[00:06:25] He said something.
[00:06:26] How many pages do you have in in your book?
[00:06:29] I'm not sure.
[00:06:31] I know sure he doesn't know. Just right.
[00:06:34] How many? 440.
[00:06:38] 440, yes. 440. I can't finish it. It's too long. Be shorter next time. Be a simple engineer. It's up to you. Okay, thank you.
[00:06:49] Hello everyone.
[00:06:58] Two seconds.
[00:07:01] Voilà. So, first, let's just want to thank, um, the organizers. I first came to Flowcon, I think, nine years ago, when it had an old name and an old venue. Second conference ever spoke at, so got a lot of good memories from this event. I think I was talking about Yeah, that was a weird talk last time, but today I'll be talking about modernization. But I was actually thinking it shouldn't really be me here today. It should be Stefan Rottenberg. He's the presenter of a TV show called Pekin Express. And just like modernization, it's a long journey. You don't turn up on Pekin Express with your PowerPoint deck and say, this is how we're going to modernize the whole system. You have to turn up every day. If you haven't watched the TV show, uh people are in groups, in pairs, they're been on. Uh it could be a grandfather, granddaughter, friends, couples, brother and sister. They have nowhere to live, nothing to eat, and no money. And they have to get around different countries, facing all kinds of challenges. And every day it's just an ongoing battle. Like, you'll see them, like, you've got to travel 50 kilometers today, with no money, no car, no nothing, and they're like jumping in the road going, 'Please, please, please!' 'Arrête, arrête, arrête!' trying to get the cars to stop. And for me, that's just like modernization. It's really just this ongoing thing. You need to turn up every day. And just continuously face battles like your colleague Yannick seeing you in on customer bugs and things 'cause he wants your team to fix it.
[00:08:39] Um so let's get started with the talk. I wonder what would Stefan Rottenberg say if he was here right now. Let's do this together. Who knows it?
[00:08:48] Three, two, one. Let's go!
[00:08:56] So, story of my own, uh, Stefan's not in this story. I was working with a company in the US a couple of years ago with some colleagues. And the goal was to help them start modernizing. And we spent some time discussing how different teams work, what they're currently working on, what challenges they face, et cetera. And we found an area and we spoke to the team. That was an internal team, they managed internal business processes, dealing with requests from customers, managing compliance, orchestrating these complex processes. And we said, uh we understand your problems, you have to use these different internal tools. You log in here, enter some information here, then you go to this tool, and you log in here, and you log into this tool. And it takes you ages to onboard new people, you have to teach them three different systems. And so we said, okay, um it seems quite obvious that modernization here would mean replacing your three different tools, so you only have one tool. And that's the plan. We spoke to leadership and they're on board with this consolidation.
[00:10:01] And they said, no, don't do that. They said quite strongly, 'We don't want that.'
[00:10:08] And we were like, huh? What? It's not logical. Why is he saying that? They're crazy! But then they explained to us why they didn't want this new tool. Because they said, 'A few years ago, we had these two tools that we had to use. And someone like you said, we're going to modernize your systems and then you'll only have one tool. And now we have three. And we don't want four!' And they were right, basically, that's what happens in a lot of these cases. And I meet a lot of people who have very similar experiences. Different companies, different job titles. This is from a software engineer. I was talking to Christine the other day who said something very similar. And she said, 'I would rather not start this migration, this modernization, if we're not going to finish it. Because if we don't finish it, we get stuck with something that's even more complex than we started with.' And I think this is the case for I don't know if it's most, but this seems to be a very common experience. And so modernization is a bit like Death Valley. It should come with some warning signs telling you this is an extremely dangerous thing. You might be crazy if you're trying to do this.
[00:11:23] And that's why I think we have our own kind of Death Valley. I call it Legacy Migration Death Valley. Because if you start modernizing, and you don't get here, and you get stuck here, you are in big trouble. You're going to have more complexity, more problems to deal with. And it's just not a good place to be. And you think about this happening in different parts of the company at the same time. You got multiple failed modernizations in the company. And that's how people end up with these three different tools. Engineers in your company who don't want to modernize because they've had bad experiences. But that doesn't mean you shouldn't modernize. Here's my friend James. He's got ginger hair. He sunburns very easily. And he's straight in there in Death Valley, ignoring the signs. But the thing is he's not ignoring the signs, because the signs, the signs don't say don't do this. The signs say do this if you're adequately and properly prepared. And that's my job today, to show you what are the, what are the warning signs for modernization Death Valley and what do you need to do to be able to go and come out the other side of modernization Death Valley. So the first warning sign is to beware of the modernization skills gap.
[00:12:47] So, when you start modernizing, your your company, your engineers, your architects, they're going to be using probably more modern technologies and tooling. And that's very dangerous because if you don't apply these things properly, they can create more complexity and more problems for your company. This is quite an old example of what we had in the last decade when microservices was the big new exciting thing. People started using microservices, because they were everyone was hyping them up, it was the cool thing. Modernize your monolithic legacy systems with microservices, and then a few years later we start seeing these problems where people have applied them incorrectly and created more problems than they solved. And that's what's going to happen if you don't close the skills gap. You won't know how to modernize properly and use the techniques and the tools effectively. And so you can't just ask your teams to start modernizing. Like, 'Oh, you've been working in the legacy for a number of years, uh no need to start modernizing.' That's the first mistake. So you got to start thinking, how do we close this skills gap? And I'll talk to you a short example of something that we're doing at Payfit. Something that was started before I joined the company. Something that involves Christina, so please wake up for this bit, Christina. Uh, so one of the concepts that Payfit recognized is that to achieve, um, the transformation objectives they've set in terms of architecture, domain-driven design is an important skill that's missing from the company. Basically, like most companies, company wants to grow, build new products, improve its products, move into new markets, improve efficiency, improve profitability, profitability, um, those kind of things. And in order to do that, there needs to be a bit more structure in the organization and the software to decouple things so that things can evolve and grow independently, both software and teams. And that's basically what domain-driven design is, it helps you to architect your your business, your teams, and your software. So to close this DDD skills gap, there are two choices. And it's very similar for many skills that your company needs to learn. You can send a few select people on a two-day training course. Or you can invest in an ongoing and continuous learning opportunities. Payfit chose the second option, which is great. And one of the ways uh Payfit does that, for example, is the DDD Open Hours, which Christina started, how long ago? Two years. Two years ago. So this happens every Monday. It's 1.5 hours, one and a half hours, every Monday, and anyone's welcome to come. Um any team, any skill. It's not just a developer thing. We have all kinds of people coming to these sessions. Um one of the things we try to do a lot, something you can't do in a two-day training course, is really learn something and apply it to real projects that you're working on, or that are happening in your company, or things that you know something about. And that's what we use a lot of these DDD Open Hours for. For solving real problems, applying DDD to real projects. Bringing these different people together who know about different parts of the business and the software. And I think this is a great uh initiative. And I think something else that's important is that Christina and others, um, were there to support people, but we go out and we look for opportunities. And we say, 'Hey, this thing you're working on, bring it to DDD Open Hours next week. It's the perfect fit, a great, great forum for it.' And I think now there's a lot of momentum, right? And people are like, 'Yeah, can we have next week DDD Open Hours slot? Yeah, can we have that DDD Open Hours slot?' You were talking until 10:00 last night organizing a DDD Open Hours, right? That's not normal, that's a one-off 'cause it's a bit urgent, but that's the momentum that's built up around this idea. So I've got an example for you of one of these DDD Open Hours sessions. And this one is basically it was about um transforming a part of the system and it's something that touched on multiple teams. I think what we were trying to get to was to have a a target architecture where we could see how these different parts of the system would fit together, and how different teams would collaborate, how different teams would own different things, and how the different bits of the system would talk together. But we had some fuzziness on a conceptual level, and so that was what we tried to solve here, mapping out the current state processes and the different entities and their life cycles. And not just mapping them out but trying to get clarity because different people see these perspectives differently. So in DDD Open Hours, we brought all these people together, um and and nailed it basically. Something else can be, it can be very different, sometimes we have more theoretical and technical concepts like talking about event sourcing. So these DDD Open Hours are very flexible. And we try to understand what are the different challenges and opportunities to learn these concepts and apply them on real projects. Some other things that we do to support that, we think about this as comprehensively as possible, like what are all of the things we can do to help close that skills gap, to help modernization progress faster and more effectively. Um, so you know, like internal communities, Slack channels, internal blog, uh something I write on the blog and encourage other people to share their experiences on the internal blog, um as a way of sharing knowledge. We have good guidelines in the engineering strategy, which encourages people and explains the key concepts, how to apply them, where to look, and those kind of things. And I think one of the most important things that we do is having people embedded in teams. And actually doing the work with teams to help them learn and apply these concepts very concretely, very specifically in what they're working on. So much different to a two-day training course. And this is kind of what's needed for the ongoing um investment and learning in in the concepts which are key to close the gap in your company. So what's the second warning? The second warning is an inability to make decisions can be fatal. And this is something I'm sure you all have experience with. You might hear comments like this. 'We can't make a decision until something else has been clarified.' And when teams can't make a decision, what do they do? They either do nothing, or they build short-term workarounds. And the longer you don't make a decision, the longer nothing happens, or the more short-term workarounds that get built. And then these short-term workarounds become quite complex themselves, and you're you're making the system more complex again at this point, and not less complex. So being able to identify key decisions and actually make those decisions can be crucial. Um and decisions can be on different levels. The previous example was more on an architectural level, but the, uh, the unknowns and lack of clarity can also be on a business level. Like, we have these different bits of the system we need to modernize, or we think we need to modernize. But we don't know which is going to be most important. We don't want to spend six months modernizing A if the product team says, 'Okay, we're focusing on B in the next two years.' So we need we don't need 100% clarity, but we need reasonable clarity on which way the company's going in order to make modernization decisions, I think, um, and so whenever you get the chance, I think it's always good to try and narrow down the possibilities and get clarity and just say, 'Is there any chance we might expand into a new country in the next three or four years?'
[00:19:24] and these short-term workarounds become quite complex themselves and you're you're making the system more complex again at this point and not less complex. So being able to identify key decisions and actually make those decisions can be crucial. Um, and decisions can be on different levels. The previous example is more on an architectural level, but the um, the unknowns and lack of clarity can also be on a business level. Like we have these different bits of the system we need to modernize or we think we need to modernize. But we don't know which is going to be most important. We don't want to spend six months modernizing A. If the product team says, okay, we're focusing on B in the next two years. So, we need we don't need 100% clarity, but we need reasonable clarity on which way the company is going in order to make modernization decisions, I think. Um, and so, whenever you get the chance, I think it's always good to try and narrow down the possibilities and get clarity and just say, is there any chance we might expand into a new country in the next three or four years? And if they say no, you can say, okay, well, we don't need to worry too much about building an even more flexible solution, we can focus on more concrete things we already have for the countries we already support, for example.
[00:20:45] So I've got another example from Payfit, something that we worked on recently, something that I worked on, something that Christine also worked on. So, uh, someone wake Christine up a bit, please. Okay, please. So this one was about a target model, um, it was on a conceptual level, well, let's just get into the details.
[00:21:04] So I'm not going to read all of this out. I don't know why I put so much text on one slide. But the basic idea is, um, the transformation has been happening, modernizing bits of the system for a couple of years. We have good clarity on a big picture level and Christine has been influential in creating a big domain's map of the whole company. So we we understand in on a big picture and in some details the the key parts of the company, the domains, the teams that own them. But still, as you modernize and you get deeper into the details and you modernize more complex and more even more core parts of the system and you get into a new level of detail, you uncover new problems and unresolved issues that need to be solved. And if again, if if these unresolved issues remain unresolved, people can't make decisions and progress or they start building the workarounds.
[00:21:58] So, just to give some example of this in the domain of Payfit in any domain. You have lots of different concepts. At Payfit, we have things like employee, collaborator, user, account, admin, expense, roles, you probably recognize many of these from other domains. And the key challenge is we have to decide, how do we represent all of these concepts in the software? And how do these things fit together? Which team owns which piece? How can you build an API or publish some events from your software if it's not clear how the concepts relate and which team owns each piece? And that's what we started to notice that there was some on a conceptual level that we had to decide what do these things mean now. And I say now, because we have to deal with this concept of semantic drift over time. When you when you build some software, it represents the business at that time. But as the business evolves and your product evolves and people start using different terminology and thinking in a different way, your software doesn't always keep up. So in a very simple explanation, you can imagine here that we start building some new product and the domain experts talk about this concept of a triangle. And the developers are like, oh yeah, we're going to implement this feature and have this triangle in our code, we'll have a class called triangle or an aggregate, if you know DDD. And then as the product evolves and the mental model changes, it's like, well, that thing we thought was a triangle, it's more of a bit of a square. And the developers are like, well, to turn that triangle into a square, it would be a lot of effort, a lot of refactoring. We don't really have time to do that, so if we if we copy it and we cut the corner off and we turn that and we turn that bit there and reuse it. It's got four corners, it's almost the square, and the product works as we need it to, just this mismatch starts to grow. And then, as the product and the business evolves, then we have this new concept that relates to the first concept. Like, yeah, we have A, and we have B. But again, the developers are like, well, what we have doesn't really align anymore, um, how do we make this new feature work and fit into the code base we currently have? Well, if we copy that thing again and we change its color and we just wedge it in here, it kind of works, the product works and the code's not a complete disaster. So we'll take that. And so that's that's how these things evolve over time. And it's completely natural. It's not it's not judging your developers. It's very hard to have code that is always completely aligned with your business. And so an example from Payfit will be this concept of an employee or a contract. I can't give too much away and it's not a criticism of any decisions that were made in the past. It's just a natural evolution. So, you have this concept of an employee. Which has um personal information, name, address, um contract details like what's your job title, how long when you work at the company. And then, as the product and the product evolves and the business evolves, it's like an employee can have multiple contracts. So, this thing's not an employee anymore, it's now a contract. But now, the challenge here is if I'm an employee and I have two contracts, I've got my personal information duplicated on two contracts and if I have more contracts, it starts to get duplicated. And now we're at a stage where we have to start figuring out what's an employee, what's a contract, where do bits of different bits of information live. When we talk to the domain experts, they say, well, we think what really makes sense is we have a collaborator and it has one profile and the personal profile information is not part of the contracts anymore. I actually spoke to the legal teams in France, the UK and Spain, I said, is it legally required to have personal information on a contract? And they said no, great, let's take it off then. Let's let's define this target model and move the code in that direction. So, yeah, I talked about that. So what we ended up creating was this map of the key entities and how they relate to each other and what they mean now or what we want them to mean in the future. The current system is not magically going to look like this with all these words and relationships. But we have a clear target model. So, when some team's building an API or modernizing some part of the system or publishing new events, we use this target model to work out which team should be owning that. What should be the names of those APIs and events if I've got an ID of a collaborator? Can that be linked to one contract or multiple contracts? And so these are the kind of questions we answered on a conceptual level. I think this was around like August, September last year and now we use this as a point of reference to make our decisions.
[00:26:48] Um, yeah, so I think, in terms of how we went about this process, this is another set of skills you need to actually identify the problem. I think this problem came up in various ways. Um, I think Yannick was showing a problem he had in his team. We had these conversations in DDD open hours and we start to realize like, this is an unresolved problem and if we don't solve it soon, it's going to be a blocker and teams are going to start building workarounds. That there are maybe already worse on workarounds at that point, so we'd already got to a point where making this decision was critical. So the process we took, um, it can vary.
[00:27:28] We first started with the options, talking to domain experts, product people, um, other experts in the company, like what do these words mean to you? How would you organize these concepts? And we had different opinions. Even the domain experts don't always agree, what's an employee versus a contract? We had to do some work to put options together.
[00:27:49] Um, personally I was working in one team on one part of the model. And then we had to figure out, okay, we think this is what makes sense in our team. Now we have to go talk to the other teams and we have to get Christine involved to help us. So there's a lot of effort in individual team workshops, multi-group team workshops, we use a DDD open hours a lot. And then once we've mapped out the options and we're not getting feedback that encourages us to think about other options, we then start to converge at Payfit, we use RFCs and ADRs to make decisions. And I think there's just a bit of personal, you need people who can keep things moving forward and because there's always going to be, ah, we chose option one, but people are still keep talking about what if we do option two. You need some skills and some guidelines to make sure at a certain point after a certain time, the decision gets made and that's it. And then keep using this model just to make people aware of it.
[00:28:44] So there's a second warning. What's the third warning? You need to protect yourself against the unrelenting forces of anti-modernization gravity. So this anti-modernization gravity is always is always working against you. It's in this room now. If your company is modernizing, it's following you everywhere. It's in every part of your company, everything you do, this gravity is constantly pushing against you because it doesn't want you to modernize. It wants you to not modernize and just keep working and keep your current systems how they are right now. It's always there, you can't get rid of it. And we see it in these kind of comments. This is not about any particular company, it's a general observation that I've seen in a lot of places. I know we said modernizing this thing was important. But one of our biggest clients is asking us for this new feature. And we really have to do this. I'm really sorry to stop modernizing. But but don't worry, you can continue modernizing again in three or six months' time when this big new thing is being built. You, if you see this comment, if you hear this kind of comment, you know where you're going to end up, okay? That's what this means. You're heading for legacy migration Death Valley if you're seeing these kind of comments and it's starting to happen on a more frequent basis. So, in order to combat anti-modernization gravity, we need something equally powerful. And that's where we can use the anti-FO framework. So it's basically framing, alignment on tradeoffs, fear and hope and ongoing vigilance. These things can help your company to stop messing around and avoid having a horrible experience in a couple of years when all the things you wanted to achieve never actually get implemented.
[00:30:33] So framing is basically, when you talk about modernization, what what are people hearing and thinking and seeing? What does it mean to them? If it's a product versus tech thing, you are already halfway stuck in legacy migration Death Valley. Because it's always going to be an argument about product wants to build a new feature, but those tech people want to keep modernizing stuff. So it becomes this kind of compromise so the tech people can modernize even though don't really see the value. The right kind of framing we need to have in this kind of situation is it's about on a business level. We're making short-term compromises for a bigger long-term investment. That has to be the framing here, short versus long-term. So, it's kind of things like, we can have something small now and have it quickly, or we can invest big and have something much greater in the future. Like, building a new product or expanding into a new company. It's about working in the current system now where the cost of change is high versus investing and being able to build many things which are currently too expensive. If you're working in a system that has incidents and bugs and you're spending a lot of time and it's it's getting become a difficult situation. This is what modernizations about. It's about solving those problems and it always has to be linked to those things. And that brings to the second point.
[00:31:58] There needs to be alignment on tradeoffs at a strategic level, in particular, what are we saying no to? So, if we think about the framing of short-term versus long-term, 100% long-term means we're going to just only do modernization and achieve long-term objectives as soon as possible. Like if we just do modernization work, if we do 100% long-term focus, we can expand into three countries in 1.5 years.
[00:32:29] If we, um, if we go for option if we go for roadmap B, we can expand only into one new country in two years, but we get some product features in the short term. And so it's about really being clear, what are we saying no to? We need to we need to have the leadership saying, we're not doing this so we can have this longer-term goal. If the leaders are giving mixed messages, that's always going to be a problem and a source of anti-modernization gravity because teams will be getting mixed messages and they will usually do what the product wants or more product work.
[00:33:05] So I just said that. Um, so then there's fear and hope. So I think fear and hope are very, very powerful tools to help us combat the forces of anti-modernization gravity. And it's something that we can all do on an ongoing basis. It's one of those small things that we can do every day. Just to remind people, just to keep them focused, just to keep projecting that future vision of what becomes possible. So there was an example a while ago where someone said, can we build this new API?
[00:33:39] And the team I was working in said, well, we can't really do that because of the legacy constraints, um, and it was kind of awkward.
[00:33:49] But I used a situation, I didn't, I couldn't, we couldn't solve that problem then. It was a disappointing situation, so I thought, let's just try and use a bit of hope here. And I said,
[00:34:00] but if we continue modernizing or no, I said, when we finish the modernization, these things will be very simple. This would take a month to do right now. If we finish modernizing, this kind of work will just take a couple of hours. It should be that simple. So it's nothing revolutionary, but sometimes these small interactions, every every interaction's a chance to like fight off a little bit of gravity. And I think also fear is a tool that we do have to use. And it's a very powerful tool sometimes and we have to remind people, we have problems right now. We have incidents, we have bugs, people aren't happy about these things. And these are never going to go away if we don't finish this modernization. They might even get worse if we get stuck in legacy migration Death Valley. So, I think fear and hope, things that we can always use to just make small improvements, like small bits of help on a daily basis.
[00:34:54] And then there's the ongoing vigilance. And the point here is, it's just a never-ending, non-stop, um, battle with gravity, no matter how much you modernize and how good you think the vision is and how clear you think priorities are, things will always try and creep in. Every sprint planning session. I guess people at this conference probably don't do sprint.
[00:35:14] Every, uh, what's the buzzword these days for prioritizing in the lean world?
[00:35:22] Uh, prioritization. Okay, whatever you call those sessions these days where you're doing planning and prioritization, that's always going to be a chance where things try and creep in. And in fact every day, every day in your stand-ups. You probably don't do stand-ups either. But every single day, there's going to be decisions about priorities that need to be made. And the forces of modernization gravity will try and push things in that aren't modernization. And you have to be there and just every single one of those small battles counts. You might think, oh, let's just do this one thing, it will only take a couple of hours or a day. But if you multiply that over two years, it can add up to huge delays. And the other thing is, if you start giving in to these opportunities, you encourage the promotion of even more anti-modernization gravity. What you're saying is, oh yeah, it's okay to compromise. We can do a bit less modernization for this one thing. And that's just a cycle that will get worse and worse. So the ongoing vigilance, every single day, every single day when you go to work, you have to think, I'm going to fight the gravity, the anti-modernization gravity as much as I can today. Every small decision will make a big difference added up over the next three years.
[00:36:36] Yeah, so just to just to finish that point, I think the the real key here is that the teams themselves need to be able to do this. The teams need to be aligned on a strategic level. Because when teams get a request from someone who's in product, very often they will feel like, oh, I can't really say no to that. So teams need to know the priorities. Modernization versus product, teams need to be empowered to say, we don't think this is the right compromise. The teams themselves need to know, this is not the right choice, we have to fight the gravity here.
[00:37:12] I think something else that's also important with the ongoing vigilance is to try and identify, where is the, where is the power source of this particular gravity? Because in my experience, it can come from anywhere in the organization. Sometimes it might be the CEO who's saying one thing to the CTO and one thing to the CPO. And so the middle managers and the teams, they get mixed messages. And what happens? Teams will just do more product work and less modernization. Right? Because that's the safe choice and there's usually more pressure pushing in that direction. But it's not always the case. Sometimes it's the middle managers. Sometimes the the intent at the leadership level is good, but the middle managers don't understand. Middle managers, um, I've heard comments like, I think the CTO will be done in six months and if we spend some time modernizing and the CTO leaves at the end of the year, we'll have nothing to show for it. So if we just keep building product features, we're on the safe path at the end of the year, whatever happens, we'll have something to show for it. That middle manager doesn't understand that the modernization work, the long-term investment is equally or more important than some of the product work he's prioritizing. And it can also be the engineers. The engineers can get into a mindset of delivering features and even the engineers can be like, we don't see the value of modernizing, we're not sure if it will last. So it's important to to really observe, where is this really coming from? You might be seeing a request from one person to do something, but where's it ultimately coming from? leaves. At the end of the year, we'll have nothing to show for it. So if we just keep building product features, we're we're on the safe path, at the end of the year, whatever happens, we'll have something to show for it. That middle manager doesn't understand that the modernization work, the long-term investment is equally or more important than some of the product work he's prioritizing. And it can also be the engineers. The engineers can get into a mindset of delivering features, and even the engineers can be like, we don't see the value of modernizing, we're not sure if it will last. So it's important to to really observe where's this really coming from. You might be seeing a request from one person to do something, but where's it ultimately coming from?
[00:38:48] All right, so, the fourth warning
[00:38:52] is that when you are in when you are modernizing, the cognitive load that you will face, that your company will face, can easily exceed levels which any human is able to cope with. And let me explain to you where some of these pressures and stresses and sources of cognitive load are coming from.
[00:39:15] So a developer has to maybe learn a new text stack that you're modernizing to. A developer might have to learn new infrastructure, new cloud providers, uh new infrastructure tooling, things like Terraform, for example. They have to learn new tools like DDD, and maybe you're learning other things as well, maybe you're changing your process. They have to still work in a legacy, understand how it works and change it, fix bugs in the legacy, update dependencies in the legacy. Teams also are we're expecting them to work with the business experts to um identify problems in the conceptual model, to deal with the semantic drift that we talked about. We're expecting them to build new features, to deal with incidents and bugs. The old and the new system running in parallel creates more complexity, more data sources to keep synchronized. At the same time, teams don't work in in isolation.
[00:40:06] There are other teams modernizing, and other teams building new features, and they might need your help. They need you to build things for them, they might create bugs that impact you or you might create bugs that impact them. And so when someone says, why are the developers not putting more effort into learning the new text stack or why are the developers not putting more effort into this DDD stuff, because they have all this going on at the same time, that cognitive load is just insane.
[00:40:33] And sometimes, yeah, when when you're starting a modernization, you're joining a new team, and you're hearing one thing from leadership, and then you talk to developers and see what they're going through, you're like, there's I don't know how this team is even surviving this, the cognitive load is insane of trying to do all this stuff at the same time. But like I said, this isn't a reason not to modernize. We just have to make sure we have correct precautions to deal with these things. And one of the first solutions we have is platforms. So I use the terminology from team topologies here because I like the way it represents the two concepts. If we think about our platform and we think about our stream aligned teams, what we want to try and do is to take this cognitive load from the teams and push it down into platforms. What decisions the team have to make, what steps the team have to carry out, if the same thing is happening in multiple teams, let's try and push that into the platform, let's just remove that cognitive load from the teams, and they can focus on all the other things, it's one less source of cognitive load. I've seen great platforms and I've seen awful platforms and and the bad platforms can create more cognitive load, unfortunately. And I've come to the conclusion that if you want to do platforms well, especially when modernizing, you need to be opinionated, I think that is really unavoidable. You need to make some decisions and standardize on certain things. Because the more you standardize, the more you can push that into the platform and build tooling around it and take that cognitive load away from the teams. And uh yeah, I've seen platforms done well in modernization, and I think it can make a huge difference. It can really it can re it can be the reason your teams have too much cognitive load, or it can be the reason your team is able to focus on what really matters and have much less cognitive load.
[00:42:22] Something else that I think is crucial to work against the cognitive load, is really a focus on decomplexifying things as much as possible. Like I gave the example earlier with segments and their microservices.
[00:42:39] Tech people, we can really go crazy when we are given new technologies and chances to refactor and modernize things, it's like a playground. Even if we don't intentionally mean to, there's a lot of stuff to try out, new ideas, new techniques, things that we've not done before and we can actually create a lot of complexity. And so we need something equally strong that's encouraging us to identify and remove that complexity. And one of the best things I saw recently was um when Nelson joined our team, and he said and after a while in the team he said, we should spend 30 minutes every day refactoring the core parts of our domain model. That's where a lot of the complexity is for us, if we can clarify the domain model, use patterns consistently, we're going to spend a lot less time having issues, um inconsistencies in the code, reduce some kind of bugs. And we do that every day, uh it's one of the best parts of the day for me. Uh the benefits are we improve the code. But at the same time, the whole team is getting a very clear message. In this team, we value refactoring and decomplexification. We are ready to get the whole team together for a mobbing session 30 minutes every day to reduce that complexity. And that is what's needed, it doesn't have to be a 30-minute mobbing session every day, but you have to be really focused on removing the complexity that can easily build up as you're modernizing.
[00:44:10] And I think also something that maybe we don't always think about when we talk about cognitive load is that we create cognitive load. The way we talk to each other and the way we treat each other is creating or removing cognitive load. And it doesn't hurt sometimes just you might be frustrated, it's very easy to be frustrated, like I'm causing a bug and it's affecting Christina's team or Pierick's team or
[00:44:33] um, what's your name again? Max, yeah, Max's team. Sometimes sometimes I'm doing stuff that causes bugs in their team. And they have every right to be annoyed with me, but they're always like, oh, don't worry, Nick, um let's jump on a pairing session, let's jump together and gather, we'll figure out the problem and fix it. Even though they have every right to be annoyed with me and get angry and cause me cognitive load, they're choosing not to, and we all have that choice. And I think it really does make a huge difference how you talk to people. I think that has a massive impact on the cognitive load that they're facing. As I was saying before, all these small things every single day, like picking this blessed, it all builds up and just the way you talk to people can have a massive impact. So, that's those are the four warning signs, those are my four bits of advice. I'm going to quickly do a recap. And then we can do some questions if there's time.
[00:45:29] So, you want to modernize. You want to modernize your legacy systems and enable things that are currently not possible for your business. First question I have for you. Who are your Christinas? Who are the people that are going to be focused on continuously reducing that knowledge and skills gap, helping your company to get the skills you need, apply them to real projects, so that you can actually modernize effectively and not make the mistakes that will happen if you don't have the right skills. If you don't have these people who are really focused on learning and just a continuous ongoing focus to learning, I would say don't even bother, because you're going to get stuck in Death Valley, is my opinion on that one.
[00:46:12] The second point is around decisions, so again, if you're thinking about modernizing, you need to look around your company and think what are the kind of decisions that we're going to have to make. What guidelines and processes do we have for making decisions? What people in our company are good at making sure that we have follow the guidelines, we make a decision and we can stick to that decision. Who are the people in your company? If you can't look around your company and see those people, then you have to find those people or you're going to be stuck in modernization Death Valley, legacy migration Death Valley.
[00:46:48] And then there's going to be this anti-modernization gravity, it's going to be all around you when you're awake, when you're asleep, it's going to be pushing you to not modernize. And you need to have something to fight back with, to to make sure that when the forces are applying themselves against you, you can fight back. And I think that's where you can apply something like the Anti-Fragile framework. The framing. Making sure that people are talking about modernization in the right way, it should not be product versus tech alignment on the strategic goals. Are we all clear what we're not going to build in the product this year? Can we be clear on that so at any point if someone says, let's build this, there's a clear agreement that says no, we agreed not to do that, we're not going to think about that. It's not in the plan. Then of course there's fear and hope, reminding people and warning people. If we don't stick to what we committed to, bad things will happen, but if we do stick to our plans, here's what will happen and we're making progress. We've already made some steps towards it, here's what we can already show some progress. Like we've got momentum and belief, if we continue, we can have even more of this good stuff.
[00:47:57] Then there is the cognitive load. It's going to be very hard for your teams to modernize with just all of these different pressures going on at the same time. And you need to be thinking, you need to be aware of this in like I said before in some companies, they're not even aware what it's like for their developers, all the stress and difficulties they're facing. And they're wondering why we're not modernizing, why are things going slow? Because your developers are completely burnt out. So this is where we can use platforms. Good platforms reduce cognitive load.
[00:48:28] And we can also focus on decomplexification, as I said before. I think this is really, really what can make a tremendous, a game-changing, I hate the word game-changing, I didn't want to say it there, but I said it, but this this focus on reducing complexity as much as possible as often as possible,
[00:48:45] having people with that mindset, I really think that is crucial. Because again, modernization can go two ways. You can build up even more complexity and more problems, or you can use modernization to remove complexity and make it possible to work in your systems as much easier.
[00:49:07] But that it's not enough. Even if you do all of those things really well.
[00:49:15] Even if you have Christina, Pierick, Max, and Yanick, it's still not enough to guarantee that your modernization is going well. What else is needed?
[00:49:32] You have to eat well. When I joined Payfit, I had some doubts, French company, French people. Not sure if it's going to be a good thing for me. I'm not really sure about this uh different culture, different kind of jokes. But the first time I came to the Paris office, um the platform team, ironically the platform team, they did this big cooking thing. They did some cooking the night before. And they bought it into the office the next day. And we had this amazing chorizo risotto, there was also a mushroom risotto, much more into chorizo myself. We had this nice lunch together with like 20 people eating this great food and I thought, yeah, I made a good choice, this is this is the right company to work for. And so that's my key takeaway for you today.
[00:50:20] If you have good food,
[00:50:23] who cares about modernization?
[00:50:32] Is there some question? Yes. Okay, we will try.
[00:50:39]
[00:50:42] Can you give it to the guy over there?
[00:50:50] Thanks for the talk. I've one question about the 30 minutes mob programming sessions. is it not too short can you really do things in like 30 minutes coding mob programming?
[00:51:05] Where's that voice coming from? I can't locate. Ah here. Ah. So is 30 minutes too short to do a mob refactoring session every day? Um I might have thought that myself before we tried this and actually what I came to the conclusion is no, not really for for various reasons. Uh one reason is we can work in a part of the code that's not being worked on closely in other features. Um so we can work on things that are separate, so in terms of conflicts with other things that are happening, it's not a problem. We work on a branch, we don't always deploy the refactoring every day. We can have some things on the branch and that's okay.
[00:51:45] Um, in terms of context switching, not really a problem either, we worked on it yesterday, and we can look at the commit from yesterday. And you get into a habit of remembering this refactoring, it's like I'm doing this work, but this refactoring project that we're working on, it's it stays fresh in your mind as well. So from those two perspectives in terms of like code um merge conflicts, not really a problem. In terms of context switching, yeah, sometimes you spend a couple of seconds like, oh yeah, what were we doing yesterday, it's like, oh yeah, you broke the test, let's fix the tests, something like that. So um no, I don't think it's I don't think it's a problem from those two perspectives. Um. How about anything else? What might be some other concerns?
[00:52:29] and and you have the time to do the real coding, not just discussing about it and coding it later, because yeah, when I used to do mob programming, I used to do two-hour sessions.
[00:52:38] And it's like a good to be in the um coding.
[00:52:45] Yeah, it's good to get into the groove. Um, and we could do one two-hour session a week if we wanted to. But I think the 30 minutes every day is a good reinforcement, it reinforces the habits and it just like building this muscle of refactoring, of decomplexifying. Setting a good signal, it's like, yeah, we do this every day, it's a good thing, let's build this habit in the team, so for that reason, I think those compromises work really well. And I would uh say I I would prefer I would prefer to do this than the two-hour session. Maybe if we do the two-hour session, it might be more efficient overall in terms of the code we get done. But in terms of building the team's mindset and setting the sign, the signals that this constant focus on decomplexifying is important, I think for that reason it's really crucial. So in and I think also with these constant refactoring, it keeps it fresh in your mind. So even when we go back to working on features, I see this with other people as well, they still have that, yeah, we did some refactoring today, it's just always in their mind to do more refactoring. And it starts to become part of the work they're doing all day, not just in these sessions. I think even if we didn't merge the code in these sessions, just the fact of practicing refactoring every day on the core parts of the domain, on real challenging bits, I think that alone would probably be worth it.
[00:54:07] So you do it for the mindset change more than for the code changes.
[00:54:12] No, no, we do it for both, I'm saying I think the mindset change alone would be worth it, but the code benefits are great too. Uh we work on some real core parts of the codebase around some of how we model the domain, how we do things like event sourcing, for example, applying good patterns and the things that we learn in these parts, we often want to apply in other parts of the code as well. To to do certain things in a standard way. So I think both benefits would be worth it on their own, but together,
[00:54:41] Thank you.
[00:54:52] Thanks for the insights, hi Nick.
[00:54:57] No, thanks. Thanks for that, it's very very insightful and um I understand during the story that you tell that you have
[00:55:08] um a big big modernization of the all company. And otherwise, you talk about so mob programming especially in one team. So I saw kind of paradox between we need to change all the company and especially all the teams. So, do you have any tips in order to how to choose the fight that we have to do now and maybe for the next months?
[00:55:35] Yeah, that's a great question, so you know, in a company with many teams and many domains, time is limited about where you focus, it's always important to to be
[00:55:45] putting your best effort into using that time most effectively. I think in terms of where we spend a lot of our time working is related to the modernization work. So, for example, I work in a team that's quite upstream and we're expected to produce events for all the other teams, domain events, so they don't have to talk to legacy. So obviously, this is quite core and is foundational to other things, so putting a lot of effort there now makes sense. But at the same time, we have the staff engineering community and staff engineers are embedded in different domains and the staff community comes together, so we are trying to level up the whole company at the same time. But it's just that some teams will get more focus at a certain time than others, based on priorities and particular challenges.
[00:56:37] So I think in in this particular example, it was around yeah, what what's the core piece that will enable others to to modernize later. We put a bit of extra effort there for now. But then after this is achieve a certain milestone, um it could be that me and Nelson go work in different teams on on and we split.
[00:57:04] Last question.
[00:57:16] Thank you. Merci. Um you mentioned about the cognitive load that can be quite, I know, over the top for the teams to learn all the things at the same time and make decisions about things that are just learning. Um also the sheer amount of things they have to decide can be overwhelming. And that platform can make those decisions or at least take some of that load off. Uh, but we also want, not specifically here but usually we say that we want teams to be autonomous and be able to make their own decisions.
[00:57:48] Um, so you could come into a pattern where the platform makes not wrong decisions, but decisions that the team is not going to adhere to. Uh, so how do you articulate those two topics? Uh, so how do you articulate those two topics?
[00:58:02] Great question. Whenever we talk about platforms, we're always in the space of compromise and we have one platform serving many teams, who have different backgrounds, different point points of view, and we can never please everyone. And as I was saying earlier, I think one of the first key principles of the platform is we have to be opinionated about some things, which is what you were alluding to. And then the question is, you know, where do we draw the line in terms of what's in the platform and what teams own themselves. Um I had a great chance to work in the UK government uh 10 years ago when I did my first talk at Flowcon, I was working there then. And one of the speakers who spoke at Flowcon, Steve Smith, I would recommend checking his work on this topic. So he was in the UK government leading the development of a platform, and that was my first real wow platform experience.
[00:58:57] And I'll explain this example, you don't have to follow this example, but basically they standardized on Scala. Seemed like a good idea back then, probably wouldn't do that now. Um and they standardized on trunk-based development, so you couldn't work on a feature branch and deploy it to dev, it just wasn't allowed. They standardized on the web framework, which was a play framework, so a lot of standards. But if but because of those standards, you got everything you need as a team. There were 50 teams at the time and they could all spin up a new application in half an hour, an hour, a couple of hours and have it deployed all the way to production. Actually, not production, but to staging and it could be ready to go to production, you just had to have it pen tested first. You get all that stuff out of the box, everything you need to be production ready like metrics, monitoring, logging, all out of the box. And so since that since I had that experience, I'm leaning more towards platform should be super opinionated. It might upset some developers, it might constrain them in some ways. But I think just being able to to build an API and have it in production in a couple of days. Have everything you need available to actually support that and start building features for me, that's a real wow moment and I think that can only come from really strong standards at a company level. Maybe you'll have some teams who are really good with infrastructure and they can build this themselves efficiently. But most of the time, um you see examples of teams uh solving the same problem, having variations in process where it's not needed. And those teams might say, but yeah, we want to do testing this way, and we want to do testing this way, and we want to have this branching strategy, and we want to have this branching strategy. And that's when you have to decide, for us as a company, are we going to allow that and support these different ways of doing things? Or do we be more opinionated and then we can push that into the platform? For your company to decide, but personally, I'm more towards standardized and opinionated platforms.

Transcript