Ep 23: Scale Demands Strategy! With Tech Veteran Jon Berger 的完整文字稿

training course is something you outsource. So, you know, wasn't that just crazy talk? Jon Berger: I I I I I think we got so much value from doing that. And and it and it wasn't just me. but but I did a lot of that and I wrote wrote courses. But I tried to also, when I was delivering those courses, rope in other senior leaders in the organization to deliver bits, partly just that it wasn't all just me, but but I I thought there was lots of value from that. And Even even years later, folks would come up to me and saying how much they remember and appreciate those courses because it it was real. When you get someone from outside the organization coming in, like that is a lot better than not doing any training at all. A lot better. But those people don't really understand the context of what's going on and the the value that you get from showing people that the senior, that the reason why they're Doing this training is because senior leadership really believe in it and they're willing to spend significant amounts of their own time to help other folks in the organization get better in in in whatever whatever that means for them. that that's really powerful. But it's also a way of building that building trust, building relationships across people that maybe wouldn't often talk to each other. I mean, if if these were people in my organization, in my teams, then obviously I'd be talking to them a bit as well. But but a lot of what I did was cross company training and that was people who I just wouldn't otherwise have talked to at all. And you you learn from them and and they learn from you. And that's that's really powerful and really enjoyable. Anne: Yeah, it's a so obviously this episode has an interesting relation to the last episode, which we're going to talk about a lot, which is Matthew Skelton, co-author of Team Topologies, talks a lot about kind of like modern good practice. But we also talked about the fact that he wrote a book specifically about it was it that came out about the same time as Team Topologies called Internal Tech Conferences, that specifically Was written about the tech conferences that you were a massive part of at MetaSwitch Networks, where you were a senior person at time, before you were bought by Microsoft and disappeared out of the world. And it's it is really his book is very good at saying, look, that there are enormous advantages to internal conferences. But it's interesting because I I was talking to to you about what you considered to be the the advantages before I spoke to him on the podcast. And you both said exactly the same thing. You were you were s ironically singing from the same hymn sheet, and it was about singing from the same hymn sheet. It was all about alignment that that that you saw the internal tech conferences and he saw the internal tech conferences as being about alignment. He talked about alignment a lot. What is alignment? 'Cause you talk about it a lot in your book as well. What does it mean? Jon

Berger: i it it th there are a few I mean the answer is it depends. Anne: Yeah. Jon Berger: and and there are there are a few different things you can be aligning on. one of the big picture things is is where you are going. what is the strategy for the company? What is the mission for the company? What is the what are the goals that you're trying to achieve? Is everyone in the in the short to medium term pointing in the in a direction which the leadership team have decided that the the company should be going in. And and we we should go into more detail on what that sort of alignment means, because normally that's what we we mean when we talk about alignment. But there is another sort of alignment as well that happens at at these internal tech conferences, which is a which is a cultural alignment. And it might be Irrespective of where we're actually going or what our current strategy or goals are, this is the way we want to get there. We want to be a learning organization, for example. It's something that Matthew talked about and and is really interesting. we want to learn from each other, we want to support each other, we want to only do internal tech conferences and never bring in ideas from the outside or you know, there are lots of different cultural communications and relationships that you can build up in these in these tech conferences, which make them hugely valuable, really enjoyable. And and actually alignment is super important. But you'll never be able to, you know, use alignment to answer everyone's questions up front. But what your culture is going to do is be supply the default answers when when leadership hasn't. And so investing in culture as well as direction is is hugely valuable. Anne: Yeah, and it's interesting. So I mean it so so Meta Switch Networks, it was one of the three companies that Matthew studied for his internal tech conferences book. So it was it was MetSwitch Networks, the Financial Times, and Klarna, I think was the third one. I mean the irony is that I also studied the Financial Times quite totally. I had no idea that Matthew was doing it, although I did know him at the time. and he was working with The same person that I was working with, which was a woman called Victoria Morgan-Smith. and I was working on with her and Sarah Wells about how the FT was adopting modern practices much better than most other companies were doing at the time. They were they were moving to cloud native very quickly, and it wasn't an Like in common with all the other people that I interviewed for Cloud Native Attitude, which was a book about movings cloud native, they were making they were having to be incredibly resilient. They were doing doing they were making mistakes, trial, they were trial and erroring everything over and over again. They had to be incredibly resilient. And it's interesting that they were also sharing and aligning themselves through internal tech conferences. Jon Berger: of the things you get out of internal tech conferences, you get people who are happy to stand up and talk about what they're doing, and you get to practice the communication of that. both so you're a little bit less nervous about doing it, maybe, but also you've just refined your material. Once you've done that and people haven't said that's rubbish. You know, that that's that makes it an awful lot easier to go and do that again. and so what if you've got people who are used to presenting what they're doing and refining that message, then it's an awful lot easier for them to be talking to the outside world about what they're doing. and you know, that's where that's where you come. Anne: That's true. So the interesting thing about your book, which is it it there was a heck of a lot, years and years and years of work going that went into deciding what the message was and then refining how you communicated it. So as you say, you you didn't you didn't just I mean you did you read a load of books, but you also tried out loads and loads of the different management techniques at all these different kinds of levels of scale over your 30-year career from like just you being on your own to you being a a small t having a small team to you having a larger team to you managing managing whole sets of teams to you managing large numbers of people and then to you managing larger numbers of people within a within a huge organisation. So loads of different scales, loads of different types of products and and you kept you know and you had to lead it was your responsibility to make sure that the that the products delivered. And you tried all kinds of different management techniques on it. And and what you learned was that there's loads of good books on management, and you learned loads of stuff from those books, but you couldn't apply the same tools, the same management techniques or leadership techniques in all of those, in all of those different environments. You had to suck it and see, didn't you really? Jon Berger: Yeah. I I think the the context is so important. and now one of the things you can do if you're at a company for a long time that is relatively stable is you you can get just very good at understanding that particular context and working within it. and And to some extent I did that for a bit. That was that was a bit of what I was doing. But the problem is once the context then changes, you find that what you were doing before can be actively unhelpful rather than helpful. and so, you know, latterly in in my career, I spent much more time trying to observe the context, working out what the differences were, saying what, you know, it just asking questions like this thing I've just learned seems totally crazy. But what if it was absolutely the truth? Or what if this perfectly sensible seeming thing was absolute nonsense? What what what would have to be true for this person to have told me this thing that I think is wrong? What would have to be true for them to be right? And you you learn so

much from that. You and that it's a really useful source of ideas, but it's also really helpful for improving communications and building those relationships because then it allows you to to iterate on those on those concepts and those ways of thinking about it and it helps other people to see how they're coming across as well and and you can you can work on those things together. Anne: Yeah, so I mean so the interesting thing is that I mean your the book is is very hard won, kind of like here's a toolbox of all the leadership and management techniques that I tried or I've read about and and seen other people try and here are some stories about where they worked and where they didn't work and and you know where I thought this was gonna work then it didn't work and then I tried this other thing and it did work. but so there's loads and loads of of hard work, what painfully hard won learning. in all of those lessons that are in the book. And it's very it's funny, it's really, you know, it's quite self-effacing. It's very funny. but also the interesting thing about it is that was j that in itself wasn't enough. You didn't just collect all the stuff. You then spent years and years refining how you communicated that, you know, through all these internal conferences, through the training sessions, through writing blogs, through writing a book itself and then getting all the feedback and reviewing feedback on the book. But it's not just that you just there's a lot of value in this book because it's not just all those hard won learn thirty years of of hard won trial and error learning. There's also decades of trial and error learning and how you communicate that trial and error learning. Jon Berger: Yeah, I I mean as as I scaled up what I was doing, I it it became more and more obvious to me that most of the time when the work was going on, I wasn't in the room. And I wanted to be able to influence the folks who were in the room. And you know, at low scale, that was a direct communication between me and them. And as the scale got higher and higher, that became less true. And so one of the things I was thinking about was more sort of broadcast communications, having meetings with with hundreds of people in them where you explain what's going on. And that has its place. That's part of what you're doing. but it's not as powerful as the written word, just because that just scales infinitely. You don't have to be in the same time zone as people. They've always got it there to refer back to. And so One of the things I I explicitly set out to do many years ago was to to improve my written communications by writing a blog as a way of trying to reiterate through through that. and it worked really well. And that that that that did culminate in the in the book. But as I it's not it's not just that, the cultural stuff as well. Like the training courses were all about how I could help someone think about things and move in a direction that that we we both wanted them

to move in and help them to go off and deliver a training course which would help other people to keep moving in the same direction. And that's that's you've got training and you've got culture and you've got the directional alignment. All they all mutually support. They all go together. When those things work, the other things work better as well. And so you build up that virtuous circle. So We talked about alignment earlier, for example, and the sort of like what direction do we want to go in? Yeah, what what does that look like? and and and it might just be as simple as picking a goal. Like there is nothing more powerful than just picking a good, clear, that's where we're going. That's what we want. We're building this product for this reason, or or we want to get over there, whatever it is. If people understand where they and everyone else in the team is trying to get to, they will there's a lot of work they can do to help you to get there. Often it's it's more about this word called strategy that people use, which means lots of different things to different people. but I think The way the way I think of strategy is is it's the answer to three questions. What are we trying to achieve? What is difficult about achieving it? How are we going to approach that difficulty? If you can answer those three questions, you build a lot of trust and a lot of clarity and therefore alignment from people because they Know where they're trying to get to. So they can do that when you're not in the room. They know that it is understood that that is difficult. And therefore, we need to think about this and we're being realistic about those difficulties. And we're aligned on the approach we're going to take to overcome those difficulties. So that combination of goal plus challenge plus approach is really powerful for alignment. And You you and Matthew talked a lot about alignment in in that in that really good session you had. I I think so much of alignment is just defining those things. Often just defining the goal, and people will align for you more often than not Anne: so that's that's all very interesting. So team topologies. I mean l the last episode was mostly about team topologies, which is a team structure. was that a strategy? Was assuming was adopting team topologies a strategy? Jon Berger: yes, it it it absolutely it absolutely can be part of your strategy. So obviously it is not the point of a company. go on. Anne: Yeah, I was about I was about to say I I it's like I've segued straight into talking about Team Topologies, why don't you explain what Team Topologies is? And then we can talk about whether or not it's a strategy. Because I should have done that, but actually you're better at doing that than I am. Jon Berger: Team Teams Topologies is is a great book, written by Matthew Skelton and Manuel Pais and they they describe essentially how to how to set up an organization. so it's this is a level beyond just a single team. This is not how you make one team work. This is how do you make an organization composed of several different teams scale and work together. without treading on each other's toes, while all pointing in the same direction. and there's a lot of different people have tried coming up with with approaches like this, but Team Topology is is by far and away the best description I've ever seen of both how to set up the teams, giving real clarity to what and purpose to each team. So they know what they're doing and what good looks like for them. and that alone is like a better description of how to set up those teams than than anything else I've tried, I've seen people try to do. But it goes way further than that. It then talks about the interfaces between those teams and what good looks like on those interfaces between the teams, which is super powerful thinking and really really part of making that. deliverable, making that the book usable rather than just a sort of thought a thought experiment. And it also, and and I, and I spend a fair bit of time in my book talking about this, introduced to me the concept of team cognitive load, like the amount of just brain space that you end up taking up or or wasting and and the challenges in just adding adding more cognitive load to people and and where things break down there. And those different bits of the book, I I just found all all of them really useful. I think it's it is a great book. Anne: Yes, but so so going back to the question I had, which is excellent description of team topologies, is it a strategy? And where is it a strategy and where isn't it a strategy? Jon Berger: Yeah, so it's it's it's it team topologies could absolutely be part of your strategy, right? The team topologies is organizing your teams is not why your company exists, right? The the teams exist to do a job. but one of the things that might be getting in the way of them doing the job is that team organization. It is a it is a difficult question that you need to answer. So if You're saying, well, we've got, you know, we've got a hundred people in our engineering org and they've all got to work together to do a thing, but clearly that is not one team. That's like we've got to break those down and we've got to give each of those those those units a job to do so that they understand what they're doing and what that group of, I don't know, six, eight, ten, whatever people are doing. Then you might say, Okay, our goal is to deliver X. The challenge with delivering X is It's got all of these different bits and we don't know how to organize our teams to make that happen. And the approach can be team topologies. So it absolutely can be part of your strategy, even though it's not what you're doing. And then at the next level down, you might give to one of your one of your subordinate leaders the the goal of delivering a team topologies organization. So that at the next level down could be a goal for them. And they'll go, well, what's the difficulty with creating that

organization? And one of the difficulties might be understanding team topologies and one of the difficulties might be getting everyone else's buy-in and this being the right thing. So, you know, you keep iterating down the the problems so that you've got something you can bite off and you've got clarity as to what what individual leaders are trying to do to deliver on. Anne: Yeah. I it's 'cause I remember you saying we're in response to having read it, that because you read it just after you had effectively retired from managing a very large organization. And I remember you saying, I I really wish I'd read this while I was managing my very large organization. Jon Berger: Yes. And I did recommend it to to to a lot of people. Anne: Yesyou doing your book. So I mean, your book is full of recommendations about other books. So yeah. Jon Berger: Yeah. That's I do as I yeah. Yeah. Anne: If you read John's book, which is quite short, your book's quite short and easy to read. I've I've say I've read it multiple times, and it doesn't take me all that long to read. It's and it's quite it's kind of divided up into bite-sized chunks as well. So you can just read one bit and learn something. I can do something with it. but yes, team topologies was. was one of the books that you recommended. There were there were quite a lot of which I mean you obviously really enjoyed you enjoy getting bringing your ideas into your head. so reading things like Teams apologies, although you kicked yourself that you hadn't read it two years earlier, or even actually probably five years earlier. Jon Berger: Yeah, ten years earlier probably would have been great. yeah, there there are lots of yeah, as we said, the book isn't about one thing. So there are lots of different ideas in here, lots of different book recommendations in different areas. Anne: This is your bo your book, isn't about one thing. Jon Berger: Yeah. and was it Team Topologies is about solving a specific problem. So it sort of is about one thing. My book is is not about one thing. It's you might have lots of different problems. If this isn't your problem, fine, move on. And you know, there there are lots of other ideas that that that will be helpful there. yeah, I I enjoyed I enjoyed Matthew's description of sort of what's coming next and how he's evolving team topologies and thinking about teams in the age of AI with with very fast movement. Anne: And this is this is him you enjoyed his discussion of what's coming next in our previous episode of Asynchronous and Unreliable the the Matthew Skelton and I one Not in his book, because he was he wasn't quite so foresighted as to what discuss what was going on after the team topology is in the book, but he talks about what he's what his his ongoing thinking was in our podcast episode. Jon Berger: Yes. He did. and and I I I'm looking forward to what he does there because I I I I I I find his his thinking very useful and very interesting. and you know, as we know, lots of people are struggling in the age of AI to work out what that does to their teams. And it will be interesting to see what ideas he ha he comes up with for for for how to to move really quickly. I think you and I have discussed in in the past how how adoption of AI, particularly on the on the side of teams who are engineering teams, writing code, where an an area where the AI can do already an awful lot of the job. And at some point in the future, possibly all of it, how does how do you iterate towards that? And that's one of the things that I'm interested in. sort of the evolution of of teams in i in a in a team topologies context, how how those teams evolve. I think the teams topology structure itself naturally leads very strongly to teams being empowered to evolve themselves to do the job that they need to do, which I think is great. I mean one of the things I always I always struggled with at work was when I found like I'd got a team set up really well. I sort of had a microsecond of great, I've got a team set up really well, followed by a, but I'm gonna have to break it now because things change. You know, people develop and this role that was perfect for them for the next 10 minutes is then becomes something that's too easy for them and they need challenging and and breaking that. And and if you're doing that in an evolutionary sense, giving the teams themselves the power to do that makes sense. My my worry with AI is that there are significant discontinuities. and that that team that needs to, you've got a bunch of teams that are delivering code the way it works today. And you've got a product and you're supporting it, and you those teams are evolving, and that's great. And they're probably using more AI now than they were two years ago, and they've evolved to do a bit more and a bit more and a bit more. But that's not the same as a team that is basically just said AI is the future, and the AI is just doing all of it, and we're just managing the AI. The AI is the team now. and that I think I I I I feel like that that team, that that future AI team, that is not a team that you evolve to, it's a team that is set off with that that parallel mission. Maybe that works fine in a team topology sense because it is just Is a copy of of the organization you have already. but that feels dangerous to me in terms of how they might interact. So I'd I'd love to know. how that works. All right. Anne: It's interesting because because we we both the several of the guests on this podcast are kind of experimenting with with AI. And you know I mean you know Martin Davidson very well indeed. and you've certainly met Justin Cormac on on multiple occasions. And they both sounded like they did. I mean, I think one of the discontinuities that you see is the discontinuity between even looking at the code to looking all the code, a code review, looking at all the code to looking at none of the of the code. Now Jon Berger: Absolutely agree, yeah. Anne: both Martin

and Justin have moved through from I'm looking at the code, because they were i early enough that they started out with their experiments with AI looking at the code, and now they don't look at the code. So they are examples of people who've who have passed through the discontinuity without their heads exploding. But they are quite I mean, obviously they're they're they're quite open to new ideas because they went out to to seek out the answers to these to these questions. yeah, but you think that there's going to be a I mean, having managed you and and led so many teams and so many people, hundreds and hundreds and hundreds of developers over the years, you don't think that all developers will be so will move over that discontinuity or teams quite so straightforwardly. Jon Berger: I I just it the it feels to me like it evolution works really well when there are incremental steps that that you're taking and empowering your teams to make those incremental steps as fast as possible is most of what you're doing most of the time. But when your the steps you're taking are not incremental, I don't think the same thing applies. And Anne: and it's interesting because with Martin and Justin, because they started so early, it was incremental for them. They were using the versions of AI that couldn't produce the code that didn't need a code review. And then they moved into a new version came out and they realized that they so, in some ways, there was they did not face that enormous discontinuity that somebody now who was doing things would face. You'd go, like, well, bring in, you know, the new version of Whatever, codex, whatever, and and you move s you're moving straight into that mode. They didn't actually have to face that giant discontinuity. Jon Berger: Yeah, maybe, although I think that's a little bit I mean, really the w early on they weren't they weren't building product. I mean they they were just experimenting. And so I just think an experimental team is just a different thing, right? And if you're not maintaining and shipping and getting paid for what you do, it's like that that that's not comparable with a team that is supporting a service. but To go from a if you're a team that's supporting a service, by by if you're doing that successfully, really today, you're you are you're very incremental, you're doing lots of you're doing trial and error, you're you're you're iterating significantly. You've got lots of different loops you're iterating through. but if it's not obvious to me that there aren't discontinuities between Lots of small scale changes, which is what you're doing at the moment, to a point where you're not looking at the code. I agree that feels like a discontinuity. Maybe I'm wrong. where a new iteration of the code is essentially not a small change from the previous one, just but just a rewrite. You know, where you you've added where where where because the AI can. It essentially every code change is a refactor of ballpark all of

it. Then, like the differences between two code bases are are just sort of meaningless, which I think is a great place to be, right? Because it means you have you are not shipping history. You know, history in your code is is another way of talking about tech debt. If you don't have to ship history, you're not shipping tech debt. That's not all tech debt, there are other types of tech debt as well. But that's a good thing. Anne: Think I think I might I might ask you to explain that a little bit more. Because you know, history and the code, there's there's when I was a supports engineer, I I always used to say, right, I did this because of this, because my future self would come aga would would make the same mistake again if I hadn't it was like, Anne don't do that because of this. And you go, I remember now. Otherwise I would have just Jon Berger: Yeah. Anne: made that same mistake again. Jon Berger: So that's there are two different so so I think we're talking about lessons learnt here. And there is there are lessons learned that you do want to encode in the in the in your product and and lessons that you don't. So the lesson and it's whether they're a positive or negative lessons. It's like we need to do this. We we you know we we thought the code. We thought the product should do this and now we think it should do this. for the for the audio. We think your product the product should go left, but it should actually go right. now the the product should go right is important and it should be encoded in your test suite and it should be shipped in the future product. The fact that we used to think it should go left is is unuseful history. And shouldn't be encoded in the product. But it might well be if an awful lot of the product is designed and coded to go left, and then at the end you go, and actually it goes right. Then you're shipping that that the fact that it used to do something else is is tech debt, is history, is unuseful history. Or put it another way: if you were going to rewrite the code from scratch today. In a microsecond, knowing everything you know now, that the fact that you used to think it was should go left wouldn't be any part of that, wouldn't affect the code at all. So if the code you've got today isn't what you would write from scratch, then you're shipping tech debt, you're shipping history that is unuseful. And the AI potentially allows you to just write the code today, which is what you wished you had written. because it can do it really quickly. In which case the delta between today's code and yesterday's code arguably is not helpful. Anne: Okay, that's that was a good explanation. cool. Okay, right. Well we've we've talked for quite a long time today. We've covered a lot of stuff. Is there anything else that you think we should talk about before we draw this episode to a to a conclusion? Jon Berger: I think my my brain is full I know anyone wants to introduce a new topic right now. Anne: No, I I my my brain is also full. The the the the cognitive load analogy, which I think Matthew says he didn't he didn't define it. It comes from his background in brain science and neuroscience. The but the Use applying it to teams as well as to individuals is is an interesting one. that was new. Yeah, that's Jon Berger: Yeah, I think that was their insight was that that there's in addition to the cognitive load that an individual has that people were already aware of, the the team has a cognitive load. And and and when you know, when I first read that, I like, Yeah, of course it does. That's just a that's a really s really useful insight. Anne: Yeah. So what I think we're saying now is our our team, Cognitive Load, has now maxed out. So so let's let's end by reminding everybody about your book, which I totally recommend. It's a it's amazing. You know, read you can read that so that you don't have to live the life that Jon lived with painful and incremental learning at all different types of team sizes and contexts. and then having to teach you all and working out how what what how you write it all down, how communicate it. so what happens when you're not in the room? it comes out on the first of September. Jon Berger: First of September and until then if you go to Jon Berger Leadership dot com, you'll be able to sign up for a free chapter so that you can see that in advance before the book goes on sale. Anne: Well, thank you very much indeed and for coming on the podcast. And thank you once again to all our listeners and watchers of Asynchronous and Unreliable Podcast. I will catch you again on a future episode. Thank you very much. Jon Berger: Thank you.