Shownotes

What Happens When You're Not in the Room with Jon Berger

Anne Currie talks with Jon Berger about his upcoming book on leadership and management, shaped by 30 years of experience across startups, scale-ups, and Microsoft. The conversation focuses on why context matters, how to build alignment, and why internal teaching, writing, and speaking can make leaders more effective when they are not physically present.

They also discuss Team Topologies, internal tech conferences, and how AI may create a real discontinuity in team evolution and software delivery.

Key topics

• Jon Berger explains that his book, What Happens When You're Not in the Room, comes from three decades of building, growing, and leading teams at many scales

• Anne and Jon discuss why management advice often fails when it is treated as a universal template instead of something that depends on context

• Jon describes the value of internal training courses, brown bag sessions, and company blogs as ways to build trust, spread ideas, and sharpen communication

• The episode revisits alignment as both a strategic concept and a cultural one

• Jon breaks strategy into three questions: what are we trying to achieve, what is difficult about it, and how are we going to approach that difficulty

• Team Topologies is discussed as a way of organizing multiple teams so they can scale, stay aligned, and avoid stepping on each other’s toes

• Jon highlights team cognitive load as a key insight from Team Topologies and one that matters in real organizations

• The conversation turns to AI and whether engineering teams can evolve incrementally toward AI-assisted or AI-led workflows, or whether that change may be a discontinuity instead

• Anne and Jon compare incremental experimentation with a more abrupt shift where engineers stop reviewing code and AI becomes the main producer

• Jon reflects on the difference between useful history in code and tech debt that should not be carried forward

Action items

• Think about whether your team is solving for the right goal, the real difficulty, and the right approach

• Use internal speaking, teaching, or writing to help ideas survive after you leave the room

• Review whether your organization has useful alignment at both the strategic and cultural level

• Consider whether AI adoption in your team is incremental or whether it may require a more deliberate rethinking of team structure

Transcript

**Anne (00:00)**

So, hello and welcome to episode 23 of Asynchronous and Unreliable, a weekly podcast where we discuss the latest ideas and concepts in tech. I'm your host, Anne Currie, co-author of *Building Green Software*, *The Cloud Native Attitude*, and the *Science Fiction Panopticon* series. And today I have the great pleasure to welcome my irregular co-host, Jon Berger, tech veteran and author of a forthcoming book on the tools of leadership and management. So, Jon, welcome to the show and remind us what your book is called and when it comes out.

**Jon Berger (00:33)**

Hello, great to be here again. My name is Jon Berger, author of *What Happens When You're Not in the Room*, which is a book on leadership. What is leadership, how you do it, how do you get better at it? And it comes out on the first of September.

**Anne (00:49)**

So it's interesting. You mentioned a lot of authors in the book. One of the authors that you mention is actually a favorite of mine, a business author, Dale Carnegie of *How to Win Friends and Influence People*, which is kind of a joke—people think that that's a silly book. It's actually a very good book on presentation, on presenting yourself and doing well. He wrote another book which I utterly love, called *The Quick and Effective Guide to Public Speaking*. In that, he said, look, there's really just one lesson that you need to learn to be a good public speaker. And that is always speak on subjects that you have every right to speak about.

It's not necessarily a gatekeeping thing. People get confused. They say, "Well, I can't talk about Rust because I'm not an expert Rust developer." You just talk about what it was like for me to learn Rust as a newbie Rust developer. 

Speak or write on something you have every right to speak or write on, I think, is a really good rule of thumb. So why did you write this book and why did you have every right to write this book?

**Jon Berger (02:16)**

So this book is based on lessons I've learned in my 30 years in the tech industry, where I've built, grown, and led teams, from tiny teams through to hundreds of people, from small companies up to Microsoft. Across that time, I worked with lots of different people, worked lots of different projects, and tried lots of different approaches. I failed in lots of weird, wonderful, and annoying ways, and I sort of started to appreciate the different contexts that I was working in.

So alongside leading the teams, delivering the product, and supporting the services, I developed courses on management and leadership. I coached people, presented at conferences, and wrote a company blog. All of those were ways of me experimenting with new ideas, seeing what worked, and bringing ideas into my head from the outside world in lots of different ways. But also alongside refining the ideas and the leadership concepts, refining how to communicate them as well, how to get them across to people in different ways.

So the book is really the culmination of all of that experience, all of those ideas, and all of those different ways of presenting these things that I've come across in that time. It's designed to be easy to understand and applicable in lots of different ways in lots of different contexts. It's not just one thing.

**Anne (04:00)**

Because I kept asking you before—because I knew you were writing the book. Obviously, I was one of the editors of the book. Editorship 101, you know that someone's writing a book. But I did keep asking you in the early days before I'd read it, "Yeah, but what's your one thing?" You know, like grit or whatever, what's your one title that's going to go across? And you kept saying there isn't just one thing. I'm thinking, a management book, and it's not just one thing?

But I know full well that there isn't just one thing. Sometimes we brought in management consultants when I was a head of IT. I always liked them personally, but sometimes they did tend to have a shtick. And you always thought, for goodness' sake, you really just want to do the thing you did in your last company, and this is not your last company.

**Jon Berger (04:54)**

Absolutely. I've worked with people like that. They have their one way of working and when it doesn't work, they just do it harder.

**Anne (05:03)**

[Laughter]

**Jon Berger (05:04)**

It's not impossible that that will work, but for me, the answer to most questions in this area essentially is: it depends. That can be quite annoying, but it is a step on the way to something that is usable and something that you can do something with. The book has lots of different ideas in it, lots of different models, lots of different ways of thinking, and lots of questions to help someone reading it actually get something useful out of it.

**Anne (05:42)**

I really enjoyed the book. I thought it was really easy to read. That is not surprising because you refined the content over years by constantly being part of these internal conferences, and running your own training courses.

At your company, you ran a whole load of training courses. You were one of the most senior engineering leaders and managers at the company. You had loads of things that you needed to be doing, but you ran a whole load of training courses. Generally, training courses are something you outsource. Wasn't that just crazy talk?

**Jon Berger (06:25)**

I think we got so much value from doing that. It wasn't just me, but I did a lot of that and wrote courses. When I was delivering those courses, I tried to rope in other senior leaders in the organization to deliver bits—partly so it wasn't all just me, but I thought there was lots of value from that.

Even years later, folks would come up to me and say how much they remember and appreciate those courses because it was real. When you get someone from outside the organization coming in, that is a lot better than not doing any training at all, but those people don't really understand the context of what's going on. The value that you get from showing people that senior leadership really believes in this, and that they're willing to spend significant amounts of their own time to help other folks in the organization get better—that's really powerful.

It's also a way of building trust and building relationships across people that maybe wouldn't often talk to each other. If these were people in my teams, then obviously I'd be talking to them. But a lot of what I did was cross-company training, and that was with people who I just wouldn't otherwise have talked to at all. You learn from them and they learn from you, and that's really powerful and really enjoyable.

**Anne (08:09)**

Obviously, this episode has an interesting relation to the last episode, where Matthew Skelton, co-author of *Team Topologies*, talked a lot about modern good practice. But we also talked about the fact that he wrote a book around 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 before you were bought by Microsoft.

His book is very good at saying that there are enormous advantages to internal conferences. It's interesting because I was talking to you about what you considered to be the advantages before I spoke to him on the podcast, and you both said exactly the same thing. You were singing from the same hymn sheet, and it was about alignment—that you both saw internal tech conferences as being about alignment. He talked about alignment a lot. What is alignment? Because you talk about it a lot in your book as well. What does it mean?

**Jon Berger (09:32)**

There are a few—I mean, the answer is, it depends.

**Anne (09:36)**

Yeah.

**Jon Berger (09:36)**

There are a few different things you can be aligning on. One of the big-picture things is where you are going. What is the strategy for the company? What is the mission? What are the goals that you're trying to achieve? Is everyone in the short to medium term pointing in the direction which the leadership team has decided the company should be going in?

We should go into more detail on what that sort of alignment means, because normally that's what we mean when we talk about alignment. But there is another sort of alignment as well that happens at these internal tech conferences, which is a cultural alignment. 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 it's really interesting. We want to learn from each other, we want to support each other.

There are lots of different cultural communications and relationships that you can build up in these tech conferences, which make them hugely valuable and really enjoyable. Alignment is super important. You'll never be able to use alignment to answer everyone's questions upfront, but what your culture is going to do is supply the default answers when leadership hasn't. So investing in culture as well as direction is hugely valuable.

**Anne (11:32)**

It's interesting. Metaswitch Networks was one of the three companies that Matthew studied for his *Internal Tech Conferences* book. It was Metaswitch Networks, the Financial Times, and Klarna, I think, was the third one. The irony is that I also studied the Financial Times. I had no idea that Matthew was doing it, although I did know him at the time. He was working with the same person that I was working with, a woman called Victoria Morgan-Smith. I was working with her and Sarah Wells about how the FT was adopting modern practices much better than most other companies were at the time. They were moving to cloud native very quickly.

In common with all the other people that I interviewed for *The Cloud Native Attitude*, they were having to be incredibly resilient. They were making mistakes, trial-and-erroring everything over and over again. And it's interesting that they were also sharing and aligning themselves through internal tech conferences.

**Jon Berger (12:52)**

One of the things you get out of internal tech conferences is 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, but also you've just refined your material. Once you've done that and people haven't said it's rubbish, that makes it an awful lot easier to go and do that again. So 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 that's where you come in.

**Anne (13:31)**

That's true. So the interesting thing about your book is that years and years of work went into deciding what the message was and then refining how you communicated it. You read a load of books, but you also tried out loads of different management techniques at all these different scales over your 30-year career—from just being on your own, to having a small team, a larger team, managing whole sets of teams, and then managing large numbers of people within a huge organization.

Loads of different scales, loads of different types of products, and it was your responsibility to make sure that the products delivered. You tried all kinds of different management techniques. What you learned was that there are loads of good books on management, but you couldn't apply the same tools or leadership techniques in all of those different environments. You had to suck it and see, didn't you really?

**Jon Berger (14:54)**

Context is so important. One of the things you can do if you're at a company for a long time that is relatively stable is get very good at understanding that particular context and working within it. To some extent, I did that for a bit. But the problem is once the context changes, you find that what you were doing before can be actively unhelpful rather than helpful.

Latterly in my career, I spent much more time trying to observe the context, working out what the differences were, and 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 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?

You learn so much from that. It's a really useful source of ideas, but it's also really helpful for improving communications and building those relationships. It allows you to iterate on those concepts and ways of thinking, and it helps other people to see how they're coming across as well so you can work on those things together.

**Anne (16:34)**

The book is very hard-won—kind of like, "Here's a toolbox of all the leadership and management techniques that I tried or read about and saw other people try, and here are some stories about where they worked and where they didn't." There is loads of painfully hard-won learning in all of those lessons. It's funny, it's quite self-effacing, but there's also decades of trial-and-error learning in how you communicate those lessons.

**Jon Berger (17:53)**

As I scaled up what I was doing, 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. I wanted to be able to influence the folks who were in the room. At low scale, that was a direct communication between me and them. As the scale got higher and higher, that became less true.

One of the things I was thinking about was broadcast communications—having meetings with hundreds of people where you explain what's going on. That has its place, but it's not as powerful as the written word, which scales infinitely. You don't have to be in the same time zone as people, and they've always got it there to refer back to.

One of the things I explicitly set out to do many years ago was to improve my written communications by writing a blog as a way of trying to iterate through that. It worked really well, and that culminated in the book. But it's not just that—it's the cultural stuff as well. The training courses were all about how I could help someone think about things and move in a direction that we both wanted them to move in, and help them go off and deliver a training course to help other people keep moving in the same direction.

You've got training, you've got culture, and you've got directional alignment—they all mutually support each other. When those things work, the other things work better as well, building that virtuous circle.

We talked about alignment earlier and what direction we want to go in. It might just be as simple as picking a goal. There is nothing more powerful than picking a good, clear direction: "That's where we're going, that's what we want, we're building this product for this reason." If people understand where they and everyone else in the team is trying to get to, there's a lot of work they can do to help you get there.

Often it's more about this word "strategy," which means lots of different things to different people. The way I think of strategy is as the answer to three questions:

1. What are we trying to achieve?

2. What is difficult about achieving it?

3. How are we going to approach that difficulty?

If you can answer those three questions, you build a lot of trust, clarity, and alignment, because people know where they're trying to get to. They can do that when you're not in the room. They know that leadership understands it is difficult, so we're being realistic about those difficulties, and we're aligned on the approach to overcome them. That combination of goal plus challenge plus approach is really powerful for alignment.

You and Matthew talked a lot about alignment in that really good session you had. 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 (21:52)**

That's all very interesting. So, Team Topologies—the last episode was mostly about Team Topologies, which is a team structure. Was adopting Team Topologies a strategy?

**Jon Berger (22:12)**

Yes, it absolutely can be part of your strategy. Obviously, it is not the point of a company.

**Anne (22:24)**

Why don't you explain what Team Topologies is, and then we can talk about whether or not it's a strategy? You're better at doing that than I am.

**Jon Berger (22:40)**

*Team Topologies* is a great book written by Matthew Skelton and Manuel Pais. They describe essentially how to set up an organization—this is a level beyond just a single team. This is not how you make one team work; it's how 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.

Lots of different people have tried coming up with approaches like this, but *Team Topologies* is by far and away the best description I've ever seen of how to set up teams, giving real clarity and purpose to each team so they know what they're doing and what good looks like for them. That alone is a better description of how to set up those teams than anything else I've seen people try to do but it goes way further than that. 

It talks about the interfaces between those teams and what good looks like on those interfaces, which is super powerful thinking and makes the book usable rather than just a thought experiment. It also introduced to me the concept of team cognitive load—the amount of brain space that you end up taking up or wasting, and the challenges of adding more cognitive load to people. I found all of those different bits of the book really useful.

**Anne (24:48)**

So, going back to my question: is it a strategy? Where is it a strategy, and where isn't it?

**Jon Berger (25:01)**

Team Topologies could absolutely be part of your strategy. Organizing your teams is not why your company exists; 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 difficult question that you need to answer.

If you say, "We've got 100 people in our engineering org and they've all got to work together to do a thing, but clearly that is not one team. We've got to break those down and give each of those units a job to do so they understand what they're doing." Then you might say:

* **Goal:** Deliver X.

* **Challenge:** It's got all of these different bits, and we don't know how to organize our teams to make that happen.

* **Approach:** Team Topologies.

It absolutely can be part of your strategy, even though it's not what your product actually does. Then at the next level down, you might give a subordinate leader the goal of delivering a Team Topologies organization. For them, that becomes their goal. They'll ask, "What's the difficulty with creating that organization?" One difficulty might be understanding Team Topologies; another might be getting everyone else's buy-in. You keep iterating down the problems so that you've got something you can bite off and clarity as to what individual leaders are trying to do.

**Anne (26:49)**

I remember you saying in response to having read it—because you read it just after you had effectively retired from managing a very large organization—that you really wished you had read it while you were still managing that organization.

**Jon Berger (27:08)**

Yes, and I did recommend it to a lot of people.

**Anne (27:13)**

Your book is full of recommendations about other books. If you read Jon's book, it's quite short and easy to read. It's divided up into bite-sized chunks so you can read one bit and learn something you can actually use. *Team Topologies* was one of the books you recommended. You enjoy bringing new ideas into your head, although you kicked yourself that you hadn't read it five years earlier.

**Jon Berger (27:58)**

Ten years earlier probably would have been great! *Team Topologies* is about solving a specific problem, so it's about one thing. My book is not about one thing; it's for when you have lots of different problems. If one specific model isn't your problem, fine, move on—there are lots of other ideas in there that will be helpful.

I enjoyed Matthew's description in your interview of what's coming next, how he's evolving Team Topologies, and thinking about teams in the age of AI with very fast movement.

**Anne (28:49)**

You enjoyed his discussion of what's coming next in our previous episode of *Asynchronous and Unreliable*. Not in his book, because he wasn't quite so foresighted as to discuss what was going on after *Team Topologies* in the book itself, but he talked about his ongoing thinking in our podcast episode.

**Jon Berger (29:10)**

Yes, he did. I'm looking forward to what he does there because I find his thinking very useful. Lots of people are struggling in the age of AI to work out what it does to their teams, and it will be interesting to see what ideas he comes up with for how to move really quickly.

You and I have discussed in the past the adoption of AI, particularly on the side of engineering teams writing code, where AI can already do an awful lot of the job, and at some point in the future, possibly all of it. How do you iterate towards that? That's one of the things I'm interested in—the evolution of teams in a Team Topologies context.

The Team Topologies structure itself naturally leads strongly to teams being empowered to evolve themselves to do the job they need to do, which is great. One of the things I always struggled with at work was when I set up a team really well, I had a microsecond of "Great, I've got a team set up really well," followed by "But I'm going to have to break it now because things change." People develop, and a role that was perfect for them for the next ten minutes becomes something that's too easy for them. They need challenging, so you have to break it. If you're doing that in an evolutionary sense, giving the teams themselves the power to do that makes sense.

My worry with AI is that there are significant discontinuities. You've got a bunch of teams that are delivering code the way it works today, you've got a product, you're supporting it, and those teams are evolving. 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. But that's not the same as a team that basically says AI is the future, AI is doing all of it, and we're just managing the AI—the AI is the team now.

I feel like that future AI team is not a team that you evolve to; it's a team that is set off with a parallel mission. Maybe that works fine in a Team Topologies sense because it's a copy of the organization you have already, but that feels dangerous to me in terms of how they might interact. I'd love to know how that works.

**Anne (32:40)**

It's interesting because several of the guests on this podcast are experimenting with AI. You know Martin Davidson very well, and you've met Justin Cormack on multiple occasions. One of the discontinuities you see is the transition from looking at code—doing a code review, looking at all the code—to looking at none of the code.

**Jon Berger (33:17)**

Absolutely agree, yeah.

**Anne (33:19)**

Both Martin and Justin have moved through that. They were early enough that they started out their experiments with AI looking at the code, and now they don't look at the code. So they are examples of people who have passed through the discontinuity without their heads exploding. But they are quite open to new ideas because they went out to seek the answers to these questions. Having managed and led so many teams and hundreds of developers over the years, do you think all developers will move over that discontinuity quite so straightforwardly?

**Jon Berger (34:13)**

Evolution works really well when there are incremental steps that you're taking, and empowering your teams to make those incremental steps as fast as possible is most of what you're doing. But when the steps you're taking are not incremental, I don't think the same thing applies.

**Anne (34:41)**

It's interesting because with Martin and Justin, because they started so early, it was incremental for them. They were using versions of AI that couldn't produce code that didn't need a code review. As new versions came out, they realized they could shift their approach. In some ways, they didn't face that enormous discontinuity that someone starting today would face, where you bring in a new version of Codex and move straight into that mode.

**Jon Berger (35:20)**

Maybe, although early on they weren't building product—they were just experimenting. An experimental team is a different thing. If you're not maintaining, shipping, and getting paid for what you do, that's not comparable with a team that is supporting a service.

If you're a team supporting a service successfully today, you are very incremental, doing trial and error, and iterating through different loops. But there are discontinuities between making small-scale changes and reaching a point where you're not looking at the code. That feels like a discontinuity.

Maybe a new iteration of the code is essentially not a small change from the previous one, but a rewrite—where every code change is a refactor of basically all of it. Then the differences between two codebases become meaningless, which I think is a great place to be because it means you are not shipping history.

History in your code is another way of talking about tech debt. If you don't have to ship history, you're not shipping tech debt.

**Anne (37:18)**

I think I might ask you to explain that a little bit more. When I was a support engineer, I always used to leave notes like, "I did this because of this," so my future self wouldn't make the same mistake again.

**Jon Berger (37:42)**

We're talking about lessons learned here. There are lessons learned that you do want to encode in your product, and lessons that you don't.

Whether they're positive or negative lessons, say we thought the product should go left, but now we realize it should go right. The fact that the product should go right is important: it should be encoded in your test suite and shipped in the future product. The fact that we *used* to think it should go left is unuseful history and shouldn't be encoded in the product.

If an awful lot of the product is designed and coded to go left, and then at the end you patch it so it goes right, you're shipping the fact that it used to do something else. That is tech debt; it's unuseful history.

Put it another way: if you were going to rewrite the code from scratch today in a microsecond, knowing everything you know now, the fact that you used to think it should go left wouldn't be any part of that—it 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 and unuseful history. AI potentially allows you to write the code today that 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 (39:49)**

Okay, that was a good explanation! 

Well, we've talked for quite a long time today and covered a lot of stuff. Is there anything else you think we should talk about before we draw this episode to a conclusion?

**Jon Berger (40:06)**

My brain is full! I don't think anyone wants to introduce a new topic right now.

**Anne (40:11)**

My brain is also full. The cognitive load analogy—which Matthew says comes from his background in neuroscience—applying it to teams as well as individuals is an interesting and new concept.

**Jon Berger (40:38)**

Their insight was that in addition to individual cognitive load, the team itself has a cognitive load. When I first read that, I thought, "Yeah, of course it does." That's a really useful insight.

**Anne (40:57)**

So our team cognitive load has now maxed out! Let's end by reminding everybody about your book, which I totally recommend—it's amazing. You can read it so you don't have to live the life Jon lived with painful, incremental learning across different team sizes and contexts. *What Happens When You're Not in the Room* comes out on the first of September.

**Jon Berger (41:34)**

First of September, and until then, if you go to JonBergerLeadership.com, you'll be able to sign up for a free chapter so you can see it in advance before the book goes on sale

**Anne (41:51)**

Thank you very much indeed for coming on the podcast. And thank you once again to all our listeners and watchers of the *Asynchronous and Unreliable* podcast. I will catch you again on a future episode. Thank you very much.

**Jon Berger (42:07)**

Thank you.