Nigel Kersten

[00:00:02] So first, hey, I'm Nigel Kirsten. Um, I really appreciate you all being here, second last session of the day, um, after, after you've just had lunch. Um, this, this means a lot. I wasn't actually expecting a full crowd. I, some of you might have seen, I don't know if you saw Fastflow Conf in London, the team topologies conference, I gave a version of this talk that I've updated a fair bit since. It had a different breakfast on it, it had vegemite, because that's what we have in Australia. I also realized not all French people actually have croissants for breakfast, just like I don't wrestle crocodiles in Australia in my spare time.
[00:00:38] So, I don't think, I think a lot of folks here probably don't know me. Um, I haven't been back in France for quite a while for work. I was an SRE at Google for a number of years in the mid 2000s. I joined Puppet really, really early, um, at the beginning. I used to have to try and explain to everyone what DevOps was, and by the end I had to explain to people why DevOps wasn't what they said they thought it was, um, after that 12 years. I also spent last year working at a company called Signadia who make nats.io. Um, and I highly recommend if you're looking for a cloud native message bus system, data broker, it's absolutely amazing. Go check out nats.io. What a lot of this talk is based on though is I spent 11 years, which feels a bit ridiculous looking back at it, writing state of develop reports. So in the beginning we started at Puppet, we ran for a few years, we brought in all of the Dora folks, um, we did DevOps reports together for a few years, we ended up splitting off and doing those were those were run by Google for a while. But then later on we brought on folks from team topologies, Manuel and Matt, who did really, really great work. And so there's this really good picture from the beginning of going, who is actually doing DevOps? What is it? To at the end, everyone's sort of being a bit post DevOps and going, what's next? Platform engineering, flow engineering, how do we want to think about these things? I think I'm pretty much ex DevOps now, and I got asked to do this talk after I first left Puppet, because I think it was the first time that I wasn't working at a DevOps vendor, um, and so I could perhaps be a little bit more honest, um, than I had been over the last five years, years before. Um, you can find me on Mastodon. Um, I don't, I'm on Twitter, but I don't really use it much anymore, or LinkedIn.
[00:02:20] Now, I know this is not a proper Ven diagram. I drew this by hand, well, with a diagram tool earlier today and realized it's not overlapping correctly. But you're going to, I'm going to talk a lot about DevOps in this thing, but you can substitute in a lot of ways, I think, flow, platform engineering, Agile. A lot of these things are about not necessarily the technical practice, but the how we work, um, and they're all, I think they're all movements that have all learned from each other.
[00:02:45] You know, brands are important, um, every so often you've got to refresh your brand, and I think this collection of people, you know, I believe this conference started as a Lean Kanban conference, now it's a flow conference, it's all the same subject matter. So when I say DevOps, sort of substitute in what you think makes the most sense for you.
[00:03:05] This is Diogenes, who founded cynicism, um, that's the infinite DevOps loop for those of you who haven't had that thrust down your throat by vendors over the last decade or so. Um, I'm not super cynical about DevOps. I actually genuinely believe in all of these things these days. I'm a little bit over some of the hype of a lot of these movements, but I do think that taking a step back and thinking about how we work, and not just the work that we're doing when we're typing on the keyboard is super important. And it's what lets us do work better, but also be happier at work. So I'm, I'm somewhat of an idealist, really.
[00:03:41] So if you didn't understand the topic title that I started with, software eats culture for breakfast. Peter Drucker, who basically this American management consultant CEO, who just had the most incredible pithy little statements. Like he'd say little things and capture quite a lot of sense in them. And his big one was, culture eats strategy for breakfast. And what he meant by that was, a company with a really good culture that works together, that can focus on ideas, can go and get things done, is all with a poor strategy, is going to beat a company that's dysfunctional, everyone hates each other, but has a great strategy. Um, I think it's true, somewhat. But I also think we can sometimes in the space that we're all in, the thinking about how we work space, we can think too much about culture and sort of forget that we work in a tech industry and the big changes that actually can happen are largely due to technology. They offer us the opportunities that we can go and grab. So I'm essentially saying that I think in most big organizations in particular, deliberate efforts at driving cultural change tend to fail unless some technology has made that change possible. So I'm going to go through a few examples there.
[00:04:56] How many of you have seen this quote?
[00:05:00] Come on, you've got to be honest. 70% of all organizational change management fail. When I first wrote this talk, I was like, yes, this is a great spot to start.
[00:05:10] McKinsey quoted, the Harvard Business Review, Forbes, Accenture, Cognizant, all these different companies. It's not actually true at all.
[00:05:19] There's a really great video David Jay Wilkinson did. But essentially he went through trying to find the original source of this, and it turns out, it's an absolute myth, and there's no evidence really behind this at all. It's not a data driven statement. And if you look at the original statement, because I spent a while going through links in his video and hunting it down. It's that these guys writing a book in '93 about re-engineering the corporation, before digital transformation was a thing, before change management was the thing, our unscientific estimate is that as many as 50 to 70% of organizations that undertake a re-engineering effort do not achieve the dramatic results they intended. And then you unpack that, and it's like, if you thought you were going to do amazing things, but you were just good, that counts as a failure. By the time this statement made its way through the game of telephone, if that's the game that you'll describe it here, um, 30, here we are, 30 odd years later, people are still repeating this over and over again. But, I do think that way more deliberate large cultural change efforts fail than succeed. Um, this was a large part of what I was doing at Puppet for the last five years, was working with pretty big multinationals, not just implementing technology, but doing the dreaded consultancy thing, because it turns out you can't just implement large-scale automation across a 30,000 person company without having to change how you actually work.
[00:06:45] If you keep following the same old processes, you're going to get the same old results, even if there's some small part of it that's been optimized.
[00:06:55] And so I think, I feel really strongly about this, that if you look at where we are today, all of the things that we're actually able to do, when we're trying to do fast flow, when we're trying to do platform engineering, trying to do DevOps, trying to do Agile. Most of these things are actually really, really hard without some of the big advances in technology that we've had. We had a conversation earlier in Dragans talk about Git versus SVN, and like distributed version control fundamentally changed, like how we could work. Some things like GitHub and better worse rather than better, um, but I think when you go back to the old days of using RCS, Perforce, CVS, like they were not great. There was lots of wasted time and high cognitive load. So I was curious about this, I googled for DevOps culture. Um, I don't know, I'm starting to get to be an old gray bearded man now, and, but I think 12 or 13 years ago when I went to the first DevOps days in Gent, that pattern really started about people talking about culture. And it became this thing where everyone would just, there would be culture talks, culture tracks. And it started to really bug me because my, my background's actually in philosophy and linguistics. And so I was like, we don't actually have a good meaning for this word, the way we're all throwing it around.
[00:08:10] So I'm just going to go through, you can find just about every possible PowerPoint template has been used to create a culture automation measurement and sharing slide. We have the round wheels. We have the Greek pillars here going where people started throwing lean in when Jez Humble did it. We have little various not quite sure they actually make sense icons. We have another PowerPoint presentation, another PowerPoint template, we have a different one. We have courses on this, we have pyramids, we have virtual circles, we have terrible puns about English wartime posters.
[00:08:48] And then this one where you can actually get certified in DevOps culture and I blocked out the company. For those who don't get this reference, if you've ever heard the phrase jumping the shark in English. It dates back to a Happy Days episode, which is a very, very old TV show, where in a desperate attempt to boost viewership, they had the star of the show jump over a shark on water skis. Um, this guy previously was like a leather jacket hoodlum, so it made absolutely no sense. So that's the fons, jumping the shark.
[00:09:19] I also took share in this blame. I spent years and years writing these state of develops reports, and for a long time we talked pretty unquestioningly about culture. Because you know, we thought we knew what we meant when we said culture, but it turns out most of the time people didn't. They just didn't actually know what it meant. So I ended up chatting to a few friends who did anthropology, literally the study of culture. And it doesn't even have a useful definition in this sense. Culture is that complex whole that includes knowledge, belief, art, law, morals, custom and any other capabilities and habits acquired by humans as members of a society. That's literally everything we do at work. It's not particularly useful. Um, there's a couple of different attributes here which start to get a little bit more useful. But I think what we saw with the whole, and this is where I do get a bit cynical, um, Devrell folks around the develop vendor space, like people who weren't necessarily from the technical deep backgrounds, started to talk about the cultures they were trying to get to without understanding what was actually going on. And but when when I say technical here, I sort of hate how it gets used as a weapon inside the tech industry sometimes. I just mean people are aware of how we build software, which is an awful lot more than just programmers.
[00:10:35] Manuel, I think it was from team pathologies, came up with a quote for one of the last state of develop reports I did, that I thought was absolutely brilliant where he was like, thinking about your organizational problems as culture, it's not useful or actionable. And I'd seen this in big organizations a lot of the time, you'd be like, let's go and implement this thing. They're like, well, no, we can't, our culture doesn't do that. It starts to become like climate change, where you feel as an individual, your, you're powerless. It's too big a topic to actually take action on and improve. So, where did this all sort of come back to?
[00:11:09] One of the things we did many years before, and you've probably seen this in the accelerate book, a lot of this came out of the state of develop reports that we all did together. Was Nicole was the first one I think who found Western's model of organizational culture.
[00:11:23] And they had a really specific meaning. The organization's pattern of response to the problems and opportunities it encounters. That's much more specific than the anthropological definition. And you might have seen this idea of having different kinds of models cultures, the power oriented, the rule oriented, and the performance oriented. And we started all sort of following this almost cargo cult of we should be heading towards the right here. I'm going to argue here that a lot of these things you can only really fix in a big org, not not a company that you're building from scratch, because in many ways that's easy to implement new ideas that, but if you're trying to change a big organization, you can't actually do most of those things and move from the left to the right without technological change.
[00:12:10] And I think it's software that creates these possibilities. Now, I don't want to make you think that I think that all of the, you know, clearly I don't think the humanities and the liberal arts are rubbish, you know, that that's what I spent a lot of my life doing. But, and I don't think technology answers absolutely everything, but I think it creates the possibilities. And particularly if you're in a leadership position, starting to think about the social aspects of technology as you're deploying it, inside your organization and with your customers, is one of the most useful things you can do. I am not a techno libertarian utopian. I don't believe that we're going to, if we all just put government on the blockchain, suddenly democracy will work properly. I just think humans are much messier than that. But I do think technology drives progress in useful ways. It's not always good, um, but it offers us opportunities. So if you're a team lead, an executive, a manager, a senior person in your company, looking at what technology does for how people change interactions with each other, I think that's super, super important.
[00:13:14] If you don't know who Taylor is, he's the guy who invented scientific management, which was essentially assembly the precursor to assembly lines with Henry Ford. The whole idea of you take a job, divide it up into small parts and just go, your job is just to do this. You stamp this one little bit, you stamp this one little bit. And this was the predominant mentality for building software in the 90s when I started working. It was that you would have specialist people who had specific roles in the pipeline, the waterfall delivery method, and they optimized for that. But I think as we've seen, we saw in the last keynote, you know, local optimizations suck, they reduce the efficiency of the overall system.
[00:13:56] There are things software doesn't fix. Um, just so you realize, there are still things we should work on, sexism, unkindness, favoritism, ableism, fear, lack of clarity in objectives, being terrible at planning and communication, not being able to write things down so that other people understand them. All of these things you can't really fix with software. But there's an awful lot of things that affect how we interact with each other that you can fix. You can fix your feedback loops, how easy it is and quick for you to experiment, how how possible is it inside the org for someone to go, you know what, let's try out building a new feature, see if it works like this or a whole new product. Technology can enable those things. It doesn't make it it doesn't make it automatically happen, but it does make it easier to start doing.
[00:14:44] So we've got to think about the social impact of technical choices. I feel like I've got lots of caveats and sort of here because I think it's really easy to as technologists fall in love with technology and sort of think that it actually fixes all of the problems. But I'm sure someone at this conference, I haven't seen one yet, talked about sociotechnical systems. It's been very, very big for a while now. But the reality is,
[00:15:08] if you change the work people do, the tasks, it changes the people, you learn to do new things, hopefully, not always doing the same thing. Um, if you implement new technology, it changes the tasks that can be done, it can change the structure of the org, these things all bounce off each other. Um, and I think this is the most important thing for us to realize that we don't just deploy technology, we're sort of modifying a large sociotechnical system for anything that's more than, you know, two people sitting in a basement writing software. So, I, this is essentially the thesis. After having tried to do this at a lot of orgs, and I think it can be difficult when you're in the consulting business, because no one really ever wants to talk about their failures, but I've never really succeeded in fundamentally changing how an organization worked.
[00:15:56] without changing what technology was deployed there. It's too hard to remove the organizational scar tissue. I, one of my fundamental beliefs is that the best thing the cloud ever did was allow people to blow up their org charts. It allowed them to go, you know what, maybe we don't need the network team, the storage team, the compute team, the security team, all these separate approval stages. Once things become self-service and there's an API behind them and we can sort of put guard rails around things but give more people access, it allowed people to blow up their org charts. And I think some of the reason we're seeing people move back from the cloud is not just because big cloud companies are kind of evil, but because it's expensive, but also now they've learned that there's different ways of working. And I think I can't think of an example where I've ever seen an organization go, you know what, we're going to fundamentally change how we do everything without changing the technology that you have deployed.
[00:16:58] So this was one of the big things that sort of started to get to me, where I was thinking, you know, if you think about, I don't know how many people in here are operations people or SREs, but if you look at what tools like infrastructure as code did. What they did is they took this stuff that was previously the knowledge of the high priests of the sys admins who had to go and make your changes by yourself. Um, and they always had to respond to a request from someone else, do work for them, that is somewhat antagonistic relationship. But I think if we look at one of the biggest things that happened in the DevOps movement was the joy of things like
[00:17:33] ansible, chef, Terraform, Puppet, even helm charts, like they start to create these abstractions that you can hand over to other people. And you've got to get that level of abstraction right, because when it's wrong, it's painful for the people providing it, and it's painful for the people consuming it. But I think what we've got to be really careful about when we're trying to progress the culture of how we work, that we don't try and do it without thinking about the technology.
[00:18:02] I don't think you could have done DevOps or even modern, you know, platform engineering or flow engineering or any of these things without these technologies. For those of you old enough to remember what it was like before we had virtualization and cloud, like you were fundamentally limited. To install a new system, like pre-Pクシー boot, pre-all of these technologies we had, people were literally walking into data centers with earmuffs on because it was so noisy, sticking CDs in, typing away painfully for 20, 30 minutes, leaving and coming back. How do you do continuous delivery like that? How do you stand up test environments really quickly? Some people managed to do it, but it certainly wasn't easy, and they were fighting the technology all of the way.
[00:18:46] I think this is a side note for me. I think one of the biggest things that changed our whole industry was simple rest APIs and better higher-level languages. You know, in the 90s when I started using software, you know, you were writing basic, you were writing shell scripts, or you were writing C++ or Java, you know, like there wasn't a lot of space in between. Pearl appeared, but you know, Pearl's a write once, never read language. Um, but then we got Python, we got Ruby, we got a whole bunch of other things that were much easier for people, and APIs became simpler. You weren't doing XML RPC, you weren't doing soap. And I think this, as you make things simpler and expose them to a bigger audience, you get new use cases and movements like DevOps wouldn't have happened, I don't think, without all of these sorts of things. I don't know for me. I think one of the biggest things that changed our whole industry was simple rest APIs and better higher level languages. You know, in the 90s when I started using software, you know, you were writing basic, you were writing shell scripts or you were writing C++ or Java. You know, like there wasn't a lot of space in between. Perl appeared, but you know, Perl's a right once, never read language. Um, but then we got Python, we got Ruby, we got a whole bunch of other things that were much easier for people. And APIs became simple. You weren't doing XML RPC, you weren't doing SOAP. And I think this, as you make things simpler and expose them to a bigger audience, you get new use cases and movements like DevOps. wouldn't have happened, I don't think, without all of these sorts of things.
[00:19:33] One of my big bug bears is when people are trying to, there's always someone who's, you know, the happy shiny person inside an org going, you know what, we all just need to collaborate more. Um, collaboration is kind of awful.
[00:19:44] when you're trying to work. We don't use, if you're thinking about platforms, for example, you know, you're not all using Google Cloud or Azure or Amazon because they're collaborating with you. You're using it because you never talk to a person. And you just get to click a button or hit an API call. I think one of the things we sort of over-rotated on and started being too fixated on was, it's all about people interactions. And you know, I need to be able to talk to this person and then we work out what's best and then we'll go and fix something. What's better is never having to talk to anyone in many ways. Like not all of the time, but for a lot of your work, you don't want to wait on someone else. You know, like you want to either be there with them, working on the thing together, or you want to be able to do something and have it automatically happen. This was, I think, the big joy of automation. So collaboration is not always a good thing. I ranted about this a little bit, there's a bunch of problems around collective brainstorming. If you've ever been in a useless brainstorming session, it's one of the most painful things in the world. Like it's not, a really good guided ideation session can work really well. But this is one of the biggest things. Solomon Asch, who's like an amazing psychologist, life in society requires consensus. We've all got to get along, we've all got to agree. But for productive consensus, every individual has to be able to contribute independently. Because it turns out we're all actually stupider when we're all in groups. Um, some people are afraid to come up with their best ideas. Some people think quickly, some people think verbally, and so they always win the awards. Other people are like slow, they take a while and they come up with a better idea. Real time brainstorming sessions are often really, really terrible way to come up with new ideas. This is one of the big things you see, there's all this data showing this up, regression to the mean. Most people want to fit in. They don't actually really want to show off. And so the your smartest people will often sit there and be just as stupid as the average person. Because it's easier socially and the overall rewards for them are better. Um, there are many good ways to do ideation, get people to come up with ideas, bring them, bring them into a group and debate them all together. Let that, let that happen asynchronously and then have the actual prioritization happen synchronously.
[00:22:06] But brainstorming is not a good thing for all the time.
[00:22:11] So a lot of this, one of the last day DevOps supports we did, was focus working with the team topologies folks, which I think is most interest to this group. And basically we surveyed, I think, what did we work out it was, 140,000 organizations over the 11 years. Going back through the data, we showed that most orgs were held back from evolving to higher levels. I don't like using the word maturity model because it implies there's a mature state where you're done. I think it's more about creating a state where you're continuing to evolve. Org structure and dynamics is what holds most people back. And anyone who's worked in a big organization, um, this feels, this should probably resonate with you. It certainly did for me when I worked inside big, very bureaucratic organizations. The data showed that most organizations that worked really, really well had platform teams, whose job was to build something for internal people to consume.
[00:23:08] And stream aligned teams, where they were like, our job is to ship a certain amount of value to someone. I could have stuck value streams on that original diagram along with Agile and DevOps, because I think a lot of these ideas are starting to converge. The big thing though, that we saw that I thought was really interesting was, the most evolved organizations had well understood mandates for their teams. If I'm in this team, I know what my job is, I know what this team's job is, and we know what our dependencies and relationships are for each other. Everything else, like you could be using terrible technology, you could be actually having a following a bad strategy, all of these different things. But if your teams actually understand, what is the point of this team and what is the point of that team and how do they relate to each other? That's the biggest amplifier. And so there would be some one one tip for folks that, if you're in a big org and you don't know that, that's management's job. That's leadership's job to go and sort that out for you. Like, and hopefully this sort of resonates for folks that, if you did know this, you'd feel like you're in a more productive organization. So this is the successful pattern we see in flow and platform engineering.
[00:24:24] So why does this solve problems, this idea of a platform team? How many people know the team topologies stuff? I'm assuming.
[00:24:33] Okay, so quite a few. So let me cover that quickly for those of you who don't know it. So, um, there's essentially team topologies folks, one. You know what, if you just have a small number of team types inside your organization and well-defined interactions between those team types, everything else sort of becomes easy. And the big one people focused on is platform teams. So rather than having a sysadmin or an SRE responsible for some system, your job is to build a platform for other people internally to consume.
[00:25:05] You have platform teams, stream aligned teams, complicated subsystem teams, and enabling teams, that's the other one. So enabling teams are the ones who go around coaching, going, hey, you know, so there's probably a lot of you here who are agile consultants who do that in your organizations. You go and help people get better at a specific thing. Complicated subsystem teams are things like where there's just really specialized knowledge that it makes no sense for everyone to know, um, and so you, you bury that in your org structure.
[00:25:36] Now, the reason this basic idea, because I think the two big ones are platform teams and stream aligned teams, works. is because handoffs between teams are expensive. Capturing context, like this is one of the things that I think has been so frustrating in IT departments. is the dreaded change control committee, where you're having to go, I'm doing a thing. Now I need to explain that thing to someone who's never done that thing.
[00:26:01] I need to explain all of the context around what I'm planning to do, if it goes wrong, what I will do if it goes wrong, write all this down in a more linear way. than I actually think about it in my head, give it to them and then they'll misunderstand it and go, no, you need to do something else. Conveying context is really, really expensive. This is why I think autonomous teams actually make the most sense. of you create these value stream teams, give them all the context around the business, but let them make mistakes, but let them own their mistakes and own their success. Because the expensive thing is going, what am I doing and going and explaining that to someone else rather than actually doing it. So conveying this stuff is expensive. If you have the traditional IT org of storage team, network team, security team, that still exists in an awful lot of big conservative companies that I worked with. You naturally have to part the context about what you're trying to do, has to get conveyed from one person to another, because all of those people are functionally split up. Collaborating between these groups doesn't actually solve this problem.
[00:27:10] So could we actually do any of these things without all of these technologies? Um, I was talking at the speaker dinner with someone about how, I grew up as an operating system nerd, you know? Like, got my hands on Solaris, and the next step, and AIX, and Linux appeared and and now kids just don't even touch operating systems. Because to be honest, they're a pain in the neck and you've got to know all of this obscure knowledge to actually get to it. We instead invented containers and went, you know what, we're going to take the OS and we're going to shrink it to this. And that's the bit that people actually need to care about. And if we get to, you know, people are getting to smaller and smaller and smaller surface areas here. And this is good because it turned out trying to abstract across the whole operating system, like the ways we did it with tools like Puppet Chef, just it doesn't actually work because the OS was never really built to be programmable. Um, but layers above something like Docker can be. But could we do any of these things, you know, software defined networking, you know, storage, all of these things, technology has actually made these things possible. where people can start to have self-service interfaces. Um, this is why, you know, Amazon were clearly a decade ahead of everyone here as far as doing this. But it was very rare, like even I joined Google in what 2006, 2007 and they had self-service interfaces where you could request compute. I'd just never dealt with anything like that before. I felt like magic, alien technology.
[00:28:34] So if we look at Flow, you know, all of these things, we, I think we've started to forget that there was a world before continuous integration and continuous delivery. Um, and I think we often combine these two things. We've gotten so used to CI/CD that we sort of forget that they're actually two quite separate things. But if you look at, this is not that long ago really. 91, you know, had Grady Booch going, you know what's a good idea, merge to main multiple times a day. People are like, whoa, burn him, he's a witch. Um, 97, you know, extreme programming. I think we're still relearning a lot of the lessons of XP that are going on. He's like, you know what, we should release multiple times a day. People are absolutely crazy. It's only been 20 years. Like we've had computers a lot longer. We've had virtualization, but continuous integration and particularly good accessible open source ones are not actually massively old. I remember in 2009 when Tim Fitz came out with this post where he was, it was, I think, one of the first big Hacker News articles to really blow up all over the place. It was like, we're deploying to production 50 times a day. It just seemed absolutely ridiculous when he said it. And he was like, they described the whole system they'd built, all of these things everyone just does nowadays, like it's just not that big a deal to be able to deploy 50 times a day.
[00:29:54] Um, I don't think we could do flow and platform engineering without all of this tech. Could you actually do the sort of work that we're all talking about?
[00:30:02] without having some of these huge technological advancements? Now that being said, I've worked inside organizations where CI/CD is the biggest bottleneck on the planet, where it's like everything must run through Jenkins. And you know what, there's a small group of five people, and they're the only people who can install extensions and no one knows how to actually maintain the thing, and it's an absolute, you know, rat's nest of spaghetti code. The technology doesn't automatically fix everything. But something like CI let developers change their relationship to each other and let feature teams change their relationship to each other.
[00:30:36] So let's go back to Westrum. Um, what does tech actually make possible on that list?
[00:30:48] I didn't have a picture for this one, so this is a terrible joke of mine of This one's Atkins, who's one of the godfathers of techno. Um, it's not even that good a joke. So, I tried to use sort of thicker lines, thinner lines to sort of describe things here, but if you look at this, like, technology sort of lets us improve a lot of these things that would be really hard in a IT sense, if you're inside a software organization, which most of us, I imagine, are these days. Um, bridging, the idea of working across teams. Um, bridging, the idea of working across teams, narrow responsibilities, sharing your risks, actually having collective responsibility, being able to cooperate across projects. We couldn't actually do this without a lot of this technology. Without, you know, CI/CD, distributed version control, test frameworks, deployment frameworks, making it fast to do deployment, really quick feedback, all of these kinds of things.
[00:31:46] So, one of the things, this is sort of the main area I end up consulting with folks on where they're starting to work out how to build out, you know, they're like, we've got an IT team, we've got an infrastructure team, but we want to deliver stuff as a service internally. Um, this I think is actually the most critical thing for sort of unlocking a lot of the flow inside organizations. Where you have people who are domain specialists, they have to be able to produce a service that's consumed by other people. This is how you start to make it so everyone can run at their own pace.
[00:32:16] And you need to create the right levels of abstraction here. Um, this was for those any of you who are building these sorts of services internally. Um, you've got to be able to have it so that there are guard rails. I think one of the worst things you can do is just open up a self-service API. I saw many organizations destroy their either their infrastructure by opening up VMware to everyone or destroying their financial books by opening up AWS to everyone. You've got to put in guard rails in some sense, and the experts are the ones who get to define that. You have to though also, and we've seen a few mentions of this in other talks, this is where communities of practice and horizontal groups are really, really important. Consumers of services have to be able to customize them and compose them together to come up with new ideas in how to solve problems. Because they have the context about what they're actually trying to get done. And finally, you've got to actually instrument the hell out of the thing. If you're not, if you're going to avoid having to go talk to people all of the time, you actually need metrics, you know, what's working, what are people actually using, where is it failing? It doesn't, it's no substitute for talking at the design phase. But you've actually got to be able to get those metrics. There's a reason we all build SAS software these days because we can actually tell what users are doing. Having been in the business of shipping on premise software, it's you're running blind, you're you often don't really know.
[00:33:36] So software can tightly couple teams together. Um, we've seen, I'm sure some of you have worked in areas where this was a pretty standard architecture not that long ago, where you had a load balancer, you're going through a whole bunch of legacy applications, you had of commercial off the shelf software, databases,
[00:33:52] you'd start doing microservices, and a lot of this stuff was kind of a mess. And it became really, really difficult. If you look at a diagram like this and you have functionally organized teams, like, no wonder everything is slow because you don't know where all your dependencies are. So then people came along and went, let's build an enterprise service bus. Um, we'll have a small team, everything will run through this. Um, it turns out that small team becomes bigger and bigger and bigger and you end up just having to massively invest in that and it fixes some of the problems, but not all of them.
[00:34:27] Then, you can also see much freer architectures people have. So this is using like for that same sort of architecture, a modern message broker. You know, you start to actually go, you know what, there is a thing out there, people can push data to it and people can get data from it. You know, you start to put schema schema registries in, technology can actually fundamentally change how teams interact. If you go back to this, it's really hard to layer a value stream oriented team in top of an environment like this. Because every time you want to change something, you're going to have to go find that information, go get context or provide context to someone.
[00:35:05] If you have teams like this, you can actually have, you know, you can descend into microservice hell if you want to, um, or you can try and keep a pretty sane architecture going.
[00:35:14] So the summary of all of this for those who've read team topologies, um, they base, their basic argument is,
[00:35:22] Conway's Law says that you, the software architecture that you deliver, mirrors the organizational architecture inside your company. And so what I'm arguing here is that new technology enables you to come up with new organizational topologies and those allow you to execute better on doing new things with software. Thank you very much. Happy to do questions.
[00:35:57] I tried to use sort of thicker lines, thinner lines to sort of describe things here, but if you look at this, like, technology sort of lets us improve a lot of these things that would be really hard in a IT sense, if you're inside a software organization, which most of us, I imagine, are these days.
[00:36:05] Uh, hi, so I was wondering how you think that the, uh, well technologies are evolving faster and faster, you know, so how do you think this is going to impact organizations?
[00:36:18] Yeah, so someone who's tried to sell been trying to sell technology to all, I think this is technology comes into most organizations via practitioners. Um, has anyone, stick your hand up if you've ever been at part of an org where someone top down has gone, we're all going to start using X, and it actually worked out well. I should have probably not phrased that quite so negatively.
[00:36:42] But, but I just don't think it works. Like I think we, we operate in such a complex environment that the people who know what tools are best are the people who are doing that job. Now it doesn't mean let everyone run one of everything because that can turn into an actual absolute headache.
[00:36:59] Um, this is where I am going to get a little cynical. I think this is unfortunately where open source is these days, most ways. It's not really about community and collaboration. It's about the fact that people recognize, you only really get in at the ground floor in organizations, if there's a big open source component. Um, because no one wants to adopt freemium software or, you know, like a commercial but free bit of software and then base their whole business on it and then go, oh crap, now they want us to pay them millions of dollars. So I think people see open source as a pragmatic choice there. So I think what this ultimately means is that practitioners, because jobs are more fluid, people change jobs more often, they bring new ideas with them, new tech appears. I think it has to become your job if you're a CTO, your VP of engineering, to listen to people, like give them the space to experiment.
[00:37:50] Um, but to be visible about it. And so maybe you try and make the responsibility and authority go both ways where you go, you know, you're all free to experiment with tools, but you've got to get up and have on demo day we do every second Friday or whatever, give a 10 minute presentation on it. Um, so I think there's no holding it back, I guess, is. Is that, is that answering your question?
[00:38:14] Um, well, in a sense, if I kind of rephrased what I understood from your answer is that, well, humans are the one that are promoting technology, so in a sense, we are going to be the bottleneck.
[00:38:30] No, let me re, let me maybe rephrase it then, because I don't think I quite said it. Um, new ideas and new technologies are going to come into your organization, no matter what you do. Um, but I think if you're a senior leader, your job is to look at that and not just think about, because someone's brought it in because they're like, hey, look, this makes code review easier. Um, and so don't just analyze it and evaluate it on that basis. But think about how does that actually change how teams interact with other teams, um, and how can I maybe take advantage of that.
[00:38:58] Um, so I think security and compliance is a big space for those of you who work in it, where this has been a big deal. It used to be you had to have external people. Um, but we've just got better and better with tools like Snip, you know, if you're trying to do sock 2, with Vanta, like all of these sorts of things actually made it simpler to do jobs that required a specialist team before. Um, they allowed us to distribute the responsibility. So I think, try and I'll try and sum that up a little more peppily then. Um, so I think, try and I'll try and sum that up a little more peppily then. New tech coming in is inevitable. It's your job as a senior leader to think about the social impact of that and try and take advantage of it.
[00:39:41] I promise to take less time answering the next one.
[00:39:44] Hello, thank you. Uh, did you think people think about climate change and technology around your space?
[00:39:51] Yeah, so I used that line quite deliberately because I don't know about you, but um, I feel helpless and sort of depressed when it comes to climate change. Like it doesn't really matter how much I recycle or if I catch the train here or play, like society overall has to change. Um, I feel like everyone's getting much more aware of this. Um, I have to say big shout out to these conference organizers, like minimal plastic, no, like, there's not rubbish swag out everywhere, I'm not going back to my hotel throwing out a million bits of plastic. Um, the hotel they put us up in as speakers, zero plastic breakfast. I just think we've all yeah, I I don't think I've got a good answer for you there. Um, if anyone does, please come let me know and help me sleep better at night.
[00:40:48] So just regarding what's written here, uh, based on what you see or you think, what are the next technologies that are coming in the next five years that will influence the organization and the software architecture?
[00:41:03] Yeah, I think so honestly, um, all the people in the space that Syria's in, um, I left because I needed a break in between jobs. I hadn't, I hadn't had a break for about 18, 19 years. Um, message buses, like we've tried doing this before, you know, we've we've had heavy weight ones. I'm sure half of you have probably worked with Kafka at some point. and there's probably some poor person inside your organization who has to maintain it, um, and deal with partitioning and all of that rubbish. But I think these sorts of things, like this the idea of being able to push data and consume data, I think fundamentally changes things. Um, what's the most popular service everyone does when they go to the cloud? Database as a service. Because you know what sucks? Maintaining databases. Like it's just the worst job ever, sorry, any database admins out there. Um, So I think, yeah, I think these sorts of things are going to be bigger and bigger. I think we haven't we've yet to see where serverless really goes. And I think we're going to see the constraints that edge computing puts on, you know, I know this is a huge buzzword of we've been hearing IoT and edge for years and years. But I think there are many things pushing us towards edge computing, but that's going to mean smaller, more environmentally friendly units of compute, that you can turn on and off and that are more flexible at communicating across large distances. I think that's going to change how we can organize.
[00:42:30] Cool. Thank you very much.

Transcript