Daniel Jones (00:01.459) Hello, Pini Reznik, how are you? Pini Reznik (00:05.944) I'm great. Yeah, it's great to start with a new podcast. Daniel Jones (00:10.501) Indeed, with shiny new microphones go with it. Pini Reznik (00:13.364) It is first time for me, otherwise would be using a normal microphone, but hopefully this one makes it easy to understand. At least on audio, yes. Daniel Jones (00:22.576) Yeah, and pleasant for the listeners to, Anyway, so this is the Waves of Innovation podcast and Waves of Innovation is the title of your forthcoming book. Having previously co-authored the Cloud Native Transformation book, would you like to start off by explaining what Waves of Innovation is in your mind and where that title comes from? Pini Reznik (00:48.524) Right. So this is something I'm doing. I mean, I guess I'm doing it since beginning of the career, but properly in the last 10 years, since I started the previous company, consulting company in cloud native space. It's all about transformation. there is every couple of years, there is a new technology every five to 10 years, there's a new massive wave of innovation, something really big that entirely changes everything. And 10 years ago it was cloud native. So I wrote a book called actually that one called cloud native transformation. And now I'm finishing more or less finished writing a new book called waves of innovation, which is about the next wave, which is AI native. And the way I define a transformation in the book sort of in both books is that when the technical architecture basically forces us to change organizational structure due to ConvAce Wall. So it's not just another tool, another piece of technology, another programming language, but something that shakes up the entire organization and requires full, effectively rebuild of the company. Daniel Jones (02:04.081) Yeah, and you mentioned Conway's law there of the shape of your architecture is determined by the shape of your human system. And from a programmer's point of view, being an engineer at heart, it kind of reminds me of refactoring projects where, know, in a startup where we had to change, there was so much that needed changing in order to make this thing scale that we needed to not just replace the insides, but change the interfaces between things. And it was a much grander scale thing than just swapping out individual components. Pini Reznik (02:38.126) I think what we realized in the last decade is that this is actually intentional. It's by design. When a change is so dramatic and it requires change of architecture from waterfall to microservices effectively, then... Again, based on Conway's law, every team needs to support their piece of architecture and that basically pushes us from hierarchical, monolithic organizations towards team topologies and small teams. And that requires human approach, right? And not just technology. And I think the point of both books is that it can be done correctly. So it's not just a thing that you need to struggle through, but if you actually understand how transformations work, there is a particular process to go through. And if you do it correctly, then you'll save yourself a lot of gray hair and a lot of trouble. Daniel Jones (03:36.859) sounds like I could have done with that. don't how much the gray hair in the beard is showing up on this camera. Maybe I need a worse camera. But you mentioned there that there's a process and a way of doing it. So presumably that process has kind of emerged to you over the patterns of various customers that you've worked with and seeing this kind of shift from what was the nascent Docker scene going into the cloud native ecosystem. now again, with... Pini Reznik (03:39.918) So crass. Yes. Daniel Jones (04:04.707) AI native technologies and approaches. Pini Reznik (04:08.718) Absolutely. in our early days of previous company, we really tried to reinvent everything. We thought we are smarter than the world and smarter than evolution. What we realized was actually there is a particular way of doing transformations, which we, over time, working with different customers, we defined it quite strictly, which is you always need to be on the outlook for new ideas. You always need to be pioneering, so exploring different things, testing new technologies, but you don't commit to those technologies until they become properly ready. And there is a business case for you to actually adopt those technologies. And once you do, then you have a full commitment and you set up a small core team that actually builds an MVP, and then you scale to a couple of more teams and then more and more and more. And gradually, you're... reduce your legacy and scale up your current thing. And this is not something we invented. We just expressed it in the first book and now in the second book is that this is effectively the only way to go through transformation. Explore all the time and when you identify the right thing, you scale, you start small and then scale over time and then transition entirely. And I think one thing that we realized, which wasn't clear when I wrote the previous book, is that a lot of companies don't reach the maturity. So a cloud native thing, for example, which we are doing now for 10 years since Docker started, very few companies actually getting the real value out of these complex technologies, Kubernetes, Docker, and everything else. Because it requires a lot of using the tools correctly, defining the teams correctly. So there is a lot of... maturity required and companies sort of get stuck in the middle and never get there. Daniel Jones (06:07.085) Yeah, the the maturity required and the changes to actually adopt and adapt those technologies properly. That is a much slower, more human process, presumably. And also you kind of spot people that maybe have got stuck somewhere in the middle where they've they've started that journey and they get kind of halfway and then don't quite follow through on the organisational change to back it up and to to get the most out of those technologies. So they're kind of getting a little bit of the benefit, but not enough. Pini Reznik (06:37.528) Exactly. And we even use the maturity matrix to sort of show that there is variety of different things you need to consider. It's not just about adopting Kubernetes, but changing the team, changing architecture, the team processes, team topology, all these things, they need to come together. So if you're talking about agile and agility is about fast time to market and faster turnaround of features, you have to show them to the customer. because otherwise it makes no sense, no value in that. So we met lots and lots of companies that they just, they sort of like feeling all this effort with Kubernetes and everything. What's the point in it? Like it doesn't give me, it actually takes more time to babysit this complex tool set and you never really get to the point of actually properly enjoying it. And now, they're still babysitting the Kubernetes, still don't have proper observability, still struggle with continuous delivery and everything else. And suddenly there is AI. Now what? Now I need to go another way? Some of them just say, OK, I will take AI and put it inside my processes and it will fix everything. So that is very unlikely. Daniel Jones (08:02.191) Statistically, yes, probably quite improbable. Pini Reznik (08:07.71) I think it's a, this is one of the things people do. And that's exactly what people did in the past. said it takes me 12 months to deliver something to the customer. So, you know, I'll install Kubernetes, put some things in containers and, you know, I can deliver every 10 minutes or so, or maybe every minute. But actually you really need to have entirely new way of working. And we clearly saw it in cloud native. Unless you have observability, unless you have test automation, unless you have independent teams, unless you actually follow all the practices, none of it works well. And we see similar process happening with AI native. Daniel Jones (08:58.232) Yeah. And so far we've been talking about AI as applied to traditional software development. And of course there are all sorts of other places that this might cause a seismic shift. mean, you and I were talking to a manufacturing company last week who all of a sudden had lots of manual toil type processes that they could potentially automate away. And we saw lots of opportunities there to make things a lot quicker for them. And also weirdly a lot more human was one of the things that I was surprised by that. If folks want to interact with Excel spreadsheets and put data in slightly strange formats that aren't entirely consistent with LLMs, we can now kind of meet users where they are better than we could previously. And I wonder if that usability shift is going to make a massive impact to the number of solutions that get adopted. Pini Reznik (09:51.576) really think this is where we need to look really. now, I mean, we are coming from software development background. So that's why we look under our noses, right, where we are. But I think the real shift is going to happen in entirely different place, which is companies like that. Small or medium-sized enterprises that they don't have software development capabilities. It means that... They do have some automation, maybe mechanical automation, but they don't have the capabilities to create basically mental automation. Something that we are dealing with for decades. think this kind of companies that are welding, building, know, constructing things, moving things around, they suddenly have access to automation tools without actually learning full software development. I don't think it will be as natural as people think it will be, like just talking to computer and it does magic. There will be some learning required. Like when I was writing a book, it required me to learn how to instruct the AI to actually write what I needed. But this is where the real value is, because majority of the companies are not software companies. And we are sort of in software world, are entirely ignoring them unless they buy one of our products. And we also assume that none of the people who don't understand, never studied computers or didn't learn it on their own, they just cannot do software. But actually this is democratization of software development. Now, and this also indirectly answers the question, will a lot of software developers lose their jobs? I really think not. I mean, many will lose their job because there are certain tasks that will be relevant, but it's like a pyramid. people are more people joining the pyramid from the bottom, those companies who are not software development companies, and they create a lot of demand on software. So that will sort of create demand on more software development tools, on more automation, on more specialization. So I think this entire field of software development is going to explode and all these companies that are just doing non-software development work, they will find ways to automate their work and remove the toil. The toil that we are talking about, the boring stuff, digging in Excel sheets or create... writing documentation for the government, this is what AI is actually very good at. Daniel Jones (11:44.603) It occurred to me, I probably shouldn't refer to too many conversations that we've had offline, but I was giving an example of how in the desktop publishing revolution, there used to be people, paste up artists who would put printed out bits of text for newspapers and magazines on pages. And those folks did find themselves out of a trade very quickly in the late 80s, early 90s. Pini Reznik (11:51.219) Yeah. Daniel Jones (12:13.136) But one of things that dawned on me is that those folks did not know the domain. Like if you were doing, if you were the pace up artists for a computer magazine or a newspaper, it didn't matter what the words were. So the folks that are going to continue to be valuable are the ones that have domain expertise and understand the businesses that they're part of and care about business outcomes and are kind of entwined with that. Pini Reznik (12:42.606) I think you actually, this is a very good point. even a decade ago, I was talking to a colleague I had done, and we were discussing how software development is effectively automation profession, right? So we basically go to the main expert and we talk to them, we get their domain expertise and we convert it to automation. This is what software development is all about. Because there is no software development as a goal. It's just a supporting function to convert the domain knowledge into automated domain knowledge. And I think what you're saying makes a lot of sense, which is basically, what if domain experts can do it on their own? Now I think it will take a long time until they can do it entirely on their own, but they can take a long, they will take step forward. So a lot of domain experts will potentially be able to write some software, but they will also start figuring out how software works. they will also create more demand on information. So I think everyone will sort of grow with it, but generally, as software developers or people involved in software development, it's better if we know the main of some sort like banking or logistics. I think that will probably make us much more valuable. Daniel Jones (14:19.406) being able to solve those problems intelligently with the knowledge of that domain and the democratization of access to contemporary business solutions is something to be hugely excited about. think, you know, in the seventies, people could implement processes with a bit of paper and a photocopier. And then once we got to the world of distributed computing, know, VBA wasn't going to cut it anymore. Pini Reznik (14:25.484) Yes. Pini Reznik (14:34.2) Yeah. Daniel Jones (14:46.554) and things became too complicated for, you know, a smart person in the corner of the marketing department to solve. hopefully we'll see a huge uptick and maybe, you know, in terms of productivity gains that were expected from, you know, the computing revolution and the cloud revolution, maybe this will be the thing that shifts the needle. We've had all this underlying tech that's kind of building up to it. But if we can get that into the hands of everyday business people so that people in sales, marketing, operations can all save huge amounts of time. Maybe then we'll start to see the bigger productivity gains that have been promised for so long. Pini Reznik (15:16.173) Yeah. Pini Reznik (15:28.376) And it is exactly that. in software, we know that when we get to the maturity, was talking about earlier, for example, cloud native maturity, where we have great cloud native platform start to full test automation and delivery and everything, and you can deploy your changes in a few minutes to production with certainty. When you get to that point, then a lot of toil is taken away. So a lot of stupid work is taken away. And you can focus on actually building the features. And in a way, that's exactly what we met in that company that we, you were talking about. Is that... massive amount of their effort is going into documentation, analyzing the standards, preparing the forms for the government, all kinds of things that they can be automated. And then what's going to happen then? Right, so let's say, of half of their time will be freed to do something else. Pini Reznik (16:35.946) And I'm sure we are, you as humans, we will figure out what to do with that time, something useful. Or not useful, but same thing. Daniel Jones (16:46.157) I would hope hope for the former but you know, leisure time is also an important thing. We are just about getting up to time. Should we be promoting the the book and the mini book I gather there's a 40 page sort of slim down version that people will be able to acquire. Pini Reznik (17:07.246) Yes, so I will be very happy to share the mini book which is sort of a teaser for the full book, explains the concept and the model and the general idea is that the new wave of innovation is coming and we need to get ready to it and there is a process of how to get ready and what to do to be effective in transitioning to AI native. The book will be ready in about three to four months from now. So if you download the mini book and subscribe to the newsletter, then we will let you know when the book is out. And hopefully the book will help you to actually see a consistent and repeatable way how to go through waves of innovation. So whatever new comes at you, you will be ready to... to that new wave of innovation.