#242 - The End of Traditional Management: Reimagining Work for AI-First Organization - Jurgen Appelo

[00:01:44] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today I’m very excited to have one of the prominent leadership speakers and also Agile person, right, in the show. His name is Jurgen Appelo. Before this conversation, actually, I haven’t heard a lot about his work, although it was quite popular for a long time. And today I’m very excited to actually have the chance to learn from him directly about all his kind of like invention and all the cool things that he’s been doing. And obviously, we’ll talk about AI as well towards, you know, the middle and the end of the conversation. So, Jurgen, thank you so much for this opportunity. Welcome to the show.

Jurgen Appelo: Henry, it’s great to be here.

[00:02:20] Career Turning Points: Seven-Year Career Pivots

Henry Suryawirawan: So Jurgen, I always love to ask my guests to first maybe tell us some career turning points within your journey, something that we can learn from you. I think that will be great.

Jurgen Appelo: Yeah. So um it’s funny cause I recently discussed that with a few friends and I picked up this idea that we have pivotal moments in our lives every seven years. Now, I don’t know if that is true for you, Henry, but it fits me like a glove for some reason or another. Like for example, 14 years ago, I had been working at a company for seven years as a CIO, uh managing developers and introducing Agile practices and et cetera. And I was working on a book because I always want write a book. And then I published the book and I quit my job and became independent as a freelancer, speaker, workshop facilitator, and so on. That was 14 years ago.

Seven years later, I got a bit tired of the management topic and I started doing other things, I’m sure we will get to that the unFIX model and other startup experiments. And uh, well, fast forward seven years uh later, that’s this year, again this is a pivotal year because the Agile community has a bit of an issue uh with Agile not drawing a crowd anymore. Agile conferences are in decline and I have to reinvent my work. Uh, what am I going to do from now on for the next seven years basically, and I also wrote some blog posts about that. So yeah every seven years I have this pivot in my life journey and there’s always uh an environmental reason for that. So I’m not sure if this answers your question, Henry, but, uh, we can talk about all those seven year moments but let’s just uh stick to the last, last couple of years.

Henry Suryawirawan: Thanks for the interesting insights, right? I’m not sure whether I can fit nicely in those seven years within my career, but I would say that, uh, we change a lot within seven years, right? And especially nowadays as with the technological advancement. I don’t know whether seven years is kind of like the right time with all these advancements. Probably will be shorter. But we’ll see. I think thanks for sharing your story.

So obviously you have kind of like… yeah. You have a few phases in your career, right? So I think, um, we’ll touch on quite the story, how you came up with all this, I dunno, framework model and also the way how you design organizations and things like that.

[00:05:29] Origins of Management 3.0

Henry Suryawirawan: Maybe let’s start with what you were really famous, uh, from, right? Uh, so it was in 2010 that you wrote this thing called Management 3.0. So I haven’t heard about it before my research about you. So maybe for those people who may not have heard about it as well. I think because in this part of the region, I think it was not widely known, but maybe tell us a little bit of story. How did you come up with Management 3.0?

Jurgen Appelo: So yeah. I was first development manager and then Chief Information Officer at a company in Rotterdam, the Netherlands, which is where I am based. We made a lot of websites and web stores for Dutch based companies. Um you may have heard of Heineken, famous Dutch brand. Uh we made all of their websites, for example. And I am a software engineer at heart myself but I’ve I was never the geek or the nerd. I have very broad interests. I like marketing, I like finance, I like lots of stuff. I also like programming. I have a degree of uh. software engineering degree, actually. It automatically meant that I ended up in management positions. I fell in love with Agile software development. Uh, it made total sense. So yeah I introduced Scrum practices in our company back then. That was 2003, 2004, 2005. I had to experiment a lot with how to make that work.

And back then, the only message that I got was let’s keep the managers away from the teams. They have to self-organize. And I thought that was a bit disrespectful to me. Because I tried to do a lot of good work so to make the teams a productive, help them with their struggles and so on. So I thought let’s write a book for the managers so that they can make sense of what their role is in an Agile organization. And it turned out that was one of the best decisions I ever made cause that was a niche. Nobody else had claimed it before.

And then when my book came out, as you said it became very popular. I have created workshops. I turned that into a licensing, a program where hundreds of facilitators around the world could give my Management 3.0 workshops. But then I had already quit my job. And I went around the world as a speaker and a workshop facilitator, and yeah that’s mostly in Europe. I did uh have a good number of events also in South America. I was keynote speaker at the Big Agile Conference in the US twice. I have maybe two or three events that I attended in the far East, to be honest. But indeed I would, I was not very popular on that side of the planet, I’m afraid. But it’s been a lot of fun. It’s been a hell of a ride. And I have published several other books since always in within the scope of management leadership, innovative organizations, agile organizational design, and things like that.

[00:08:31] Managing Systems, Not People

Henry Suryawirawan: So very interesting that you mentioned about the role of managers in Agile organization, Agile teams, and all that, right? So I know that people nowadays kind of like, I mean, I’m not sure how pure Agile they are doing, but everyone assumes that they are Agile. So maybe if you can elaborate, what do you think are still the role of managers in such maybe technological organizations, so to speak, right? And what do you think are still relevant compared to back then? You know, like in 2010, you came up with this approach. Do you still think those things are relevant today?

Jurgen Appelo: Absolutely. Well the interesting thing is that everything keeps changing. So in the past, let’s say a few decades ago, it was pretty normal to treat employees as cogs in a machine and be able to give them instructions and give them work to do and then check them for their performance. And some managers even counted the lines of code that they produced. And that was the bad old days. Many managers nowadays understand that this is not how software engineering works. You do not measure productivity in terms of lines of code and things like that. So we definitely moved beyond that.

And I have always said it’s about managing the system, not the people. And what I mean by that is this is the team, the self-organizing Agile team tries to be, do the best they can - I mean, I assume people have best intentions - within an environment that is often holding them back, that is grinding them down, et cetera. And that’s where the focus of the managers should go. Like how can we remove all those obstacles so that the team can run, run and produce, and produce. And create value for customers. So that was very much in line with Agile thinking, only the Agile software development frameworks focused on the team itself and the Scrum master, for example, removing bottlenecks. But the Scrum master can do only so much for actual change in the organization. You need management. They’re responsible for the connections with HR, with marketing, with senior executives, and so on. And very often the problems are there. So that’s the role of the development manager to make sure that the environment is conducive to higher productive, highly productive software engineering teams.

So that was my focus with management back then, and when my book came out, to make management more humane to assume that some of the developers are trying to do a good job. They’re just being held back by stupid rules by bad technologies, et cetera that managers could solve for them.

Well, fast forward a number of years. We’re now in the age of AI and we have AI agents joining our teams. And the funny thing is there’s now this paradox of we now have these true robots joining our teams who should be managed with command and control. Like managers did maybe 20 plus years ago with humans which is a bad thing. You should not apply command and control to humans but you should apply command and control to your AI agents, right? Because they’re not humans. They need extensive prompting and context engineering, uh, et cetera, which is a fascinating paradox.

So as I said, things keep changing and now we’re basically entering an age with a dual track where managers have two responsibilities. On the one side, the humans that still need to be managed in a humane oriented way. And the other track is the machines. They need the command and control approach that they sometimes refer to as Management 1.0, which makes perfect sense when you are dealing with machines. And those two have to align. They have to be able to work with each other, and that’s a new challenge. How do you do that dual track management? I look forward to the years to come, because this is something we all have to figure out basically.

[00:12:35] Everlasting Management Principles

Henry Suryawirawan: Wow! Very interesting indeed, right? So we are now, indeed, you know, dealing a lot with not just human, right, but also so-called AI agents, robots, automations, right, that can do their own decisions. So I think, let’s put that aside for now. Uh, you mentioned about a few principles that in Management 3.0, the first is like managing the system, not the people. And I assume also like you move away from command and control, right? More towards self-organizing. Are there any other principles that you think are still relevant for us to know about whenever we run, maybe, technological company or software team?

Jurgen Appelo: So I’ve tried to distill it into a number of principles over time. And what I started out with was, for example, things such as create value for stakeholders. Interestingly enough, the Agile Manifesto focuses only on customers, making customers happy and that makes total sense, delighting your users and customers, but those are only one group of stakeholders. Managers are responsible for more groups of stakeholders. You also have your suppliers and vendors, on the other side. You also have your shareholders and business owners. Uh, you also have the wider world outside which is the government and the local community, perhaps, where you employ people, etc. Managers have this balancing act to do. It’s like spinning multiple plates in the air. You cannot just delight your customers at the expense of other groups. And that is the art of management, in my opinion, to keep everyone happy enough that they don’t complain about what you’re doing. So that was one of the principles that I mentioned value for all stakeholders.

And uh, energized people is what I usually started with in my Management 3.0 workshops. Many people say that, uh, employees are already naturally motivated. Uh, what usually happens in organizations is that organizations demotivate people with bad rules and bad systems that they need to live in. And I agree with that to some extent. But there are also things that you can do to actually motivate people. I have quite a lot of uh, experience that myself in my years when I was a manager at that company in Rotterdam, I did the silliest things. I organized a vacation photo, lunches, for example, after summer where we had lunch together and anyone who wanted to show their vacation photos, we showed them on a big screen over our sandwiches and then we shared with each other, where we’d been on vacation. And people loved that. It was just a very personal thing. And nobody asked me to. But I thought, well, I would love to show my vacation photos and I’m sure other people are also happy about where they’ve been hanging out for the last couple of weeks. So that’s one example.

We organized game nights with the employees. Uh we’re playing games, we’d uh I organized lunches performance appraisals over dinners. I call it 360 dinners, where we organized the, uh, up the whole team together, uh, over dinner. We discussed the performance appraisals forms that we were sent by HR and we filled them out together with each other. We gave each other frank, honest, radical feedback that sometimes hurt but always had a compliments added to it as well. And people loved that. It was very transparent, that way of management. And that was not normal for managers to do something like that. I was a bit of a weirdo to be honest in the way I managed. Uh, but I had results cause I was confronted with the turnover rate of 15 or 17% when I started. I had a drop to nearly zero. People didn’t do… quit their jobs anymore after seven years. There was no retention …uh… high retention, I mean. No, uh, no churn. And, um I was proud of that and that’s basically what I wrote about in my book. But the thing is that you can do as a manager to keep people happier in their organization.

Henry Suryawirawan: Yeah, so I think thanks for emphasizing this part of, uh, you know, energizing people, motivating people. So, because in a lot of companies, at least I’ve seen managers are focusing a lot about results, deliverables, output, you know. Chasing KPIs, OKRs, whatever system that they use. And I think sometimes forgetting about the people aspect, especially these days about layoffs, um, you know, a lot of situations about working back to office and things like that. So many, many people are feeling, you know, some parts of them are being demotivated and probably lose interest in their jobs. So I think, uh, what you mentioned is kind of like important for managers to energize people and motivate them back.

[00:17:21] unFIX: Patterns Over Frameworks

Henry Suryawirawan: So let’s move on to the next, you know, kind of like maybe iteration or evolution of this Management 3.0. So in 2022, if I’m not mistaken, so you kind of like invented another thing called unFIX, um, model, right? So if I’m not mistaken, this is also kind of like a response towards, you know, Agile frameworks, you know, large scale Agile framework, things like that. So maybe tell us this story. What is unFIX, uh, also, by the way?

Jurgen Appelo: So yeah, uh, fast forward a number of years. I had done a lot in the Agile community. Uh, I was not the only one. There were lots of frameworks like SAFe, the Scaled Agile Framework, uh, LeSS, Large Scale Scrum, the famous Spotify model quote unquote that everyone was referring to, and the number of lesser known competitors. And I always had a bit of a hate-love relationship between those frameworks, because they were full of good advice. There were sensible people making those frameworks and offering them with the best intentions. At the same time, I did not like the concept of a framework of offering something that is prepackaged that is complete and that you then would install as if you were installing the .NET framework or a Java framework or whatever in the organization. That just didn’t sit well with me.

I also noticed that I wasn’t particularly impressed with the organization design suggestions In SAFe and the Spotify model, et cetera. Um, because for example the Spotify model is simply a matrix structure rebranded. There’s nothing new about the Spotify model other than the sexy terms, like squad and tribe is basically is a matrix structure that we’ve already been using for decades, and they come with known problems, matrix organizations. So I was not impressed with organization design advice.

So I started researching that a little bit. I got interesting suggestions from various sources and I thought okay we need better suggestions for organization design and not presented as a framework but as a pattern library. Now what is a pattern library? That is the concept or pattern language, I should say. That is a concept that Christopher Alexander came up with. He is a uh, he was in in the seventies of the 20th century an architect, an urban design, planner, a professor, and he collected 253 patterns of what makes a great city. And there’s lots of familiar things, like a promenade. Many cities have a promenade. Because people like promenade. They want to, they go walk up and down the promenade and be seen and see other people and things like that. Or the town square. Every city has town squares, many of them, because it makes sense to have a square where cafes emerge and so on. Well, those are just two examples of 253 patterns. Now what he did not offer was one architecture, one blueprint for how to make a city. That is, that would be the equivalent of a framework, right? If you draw the city is, okay, put the buildings over there. No! You just offer this library of patterns but you ask the city planners, the urban designers to combine them in any way they want. Because New York is not the same as London and is not the same as Paris. But they all have promenades. They all have town squares. They all have many of the patterns in Christopher Alexander’s book. And I love that idea of patterns. It is actually also used in the famous book Design Patterns by the Gang of Four. Maybe you know that one, Henry, or the in the nineties super famous book with Model View Controller, the singleton, the facade pattern. I know what I’m talking about cause I’m a software engineer.

Yeah so, and they also picked up this idea of use different patterns from the book but don’t put it all together as one framework is that does not work. So I picked up this pattern concept, and I’m not the only one by the way. There are other people who also have borrowed the idea of patterns like Liberating Structures, Team Topologies that you’re probably familiar with, sociocracy, and a few other brands and models out there have gone the patterns approach instead of the framework approach. So I offered a couple of patterns for organization design. Some of them borrowed from the Spotify model, some of them borrowed from team topologies, some of them borrowed from elsewhere at that, oh, these people they all have great suggestions. Why reinvent the wheel? I just want people to have a pattern language and not a framework. So give them a toolbox and the great metaphor that I always use is Lego.

With Lego, you get, you have a box full of bricks and you can make anything you want. Of course, when you go to the store, you buy something that looks like a hospital or a fire truck or whatever and then you can make it. But once you get bored of it, you can make something else and combine it with your other Lego bricks that you already had. And then this is where the real fun begins. And that is a bit similar to how a pattern language works. But interesting thing is it does require more of the user of the organization designer or the manager. Because with SAFe, you can simply implement it and then you get certified, if you have a correct implementation of the Scaled Agile Framework. And while there’s a lot of people who do not like SAFe for exactly that reason, because it seems it doesn’t really work out of the box and implement it in any organization. You have to break it down into individual components. And that is what you do with a pattern language. But it requires more thought, so it’s a harder sell, I’m afraid, of pattern language than a framework. Cause framework is easy. You just implement it, you certify everyone, and done.

Henry Suryawirawan: Yeah, I think it’s the same like software framework, right? It’s very easy to install, start, use, and straight away you understand a convention and people just go, right? So I think maybe that’s why people are more interested in just adopting framework. And I know talking about organization design, many people also copy the big boys. You know, just like what you mentioned, Spotify model, maybe Amazon model, Google model, Facebook model, whatever big organizations. They think just by following, copying the organization design, they will also reap the success of those organizations. But I think, interestingly, when you mention patterns, right? We all know software engineers, you know, design patterns, right? So the good thing about patterns is that, sometimes, uh, you also list down the, where this doesn’t work, right? So it’s not always like this pattern works for all cases. Um, you mentioned maybe there’s a context why it will be successful and why it won’t be successful. So I think it’s, uh, the onus is on the management executives to actually pick the patterns.

[00:24:27] Core unFIX Patterns

Henry Suryawirawan: I dunno how many patterns you have so far in unFIX. Maybe if you can, I don’t know, share with us what are some of the common patterns that you think you have done so far that are always successful or mostly successful in any tech organizations that you have implemented?

Jurgen Appelo: So I don’t even know off the top of my head, to be honest. I think it’s, uh, over 200 patterns that we collected. But to be honest, uh, there are a number of popular ones that everyone refers to. Those are the organization design patterns. And then there are some rare patterns that almost never meant and nobody mentions. But it’s the same with Christopher Alexander’s book. There are some obvious ones that every city has and then there are some patterns that are very unique and special that you only need in very rare situations. A bit similar.

But let’s start with the organization design pattern. The value stream crew is the same as what in team topologies they call the stream aligned team. It is the same as the Agile team, the Scrum team, it’s all the same thing, right? You have a small unit, a self-organizing team, that is trying to produce something valuable for a customer. That’s an obvious one. That’s a no-brainer that almost any company in the world uses that pattern for a good number of teams. I hope. Fingers crossed. Because it’s a good pattern. So that was pattern number one, I think, in the unFIX, uh, model. That’s the obvious one. Uh.

But a pattern that we added that is not in team topologies, for example, is the governance crew. Because team topologies has four patterns which is stream aligned team, the enabling team, the platform team. And then the component team or what they call the complicated subsystem team. So that’s just four. But who was managing? I was of course the manager who was thinking, where do I fit in team topologies? I mean, come on. I talked with lots of startups and scale ups in Europe and the most successful ones very often have this trio on top of a business unit or on top of a scale up, that is the chief product, the chief marketing, and the chief technology or something like that. Three chiefs, maybe four chiefs, and they run the whole thing. And then I think, well, that’s a pattern. That’s a good pattern. There’s lots of scale ups that work that way. So let’s just acknowledge that as a pattern. I call that a governance group. And team topology misses an equivalent of that.

There’s another interesting pattern that is actually not yet in the unFIX language, but I’m considering adding it very soon. And we, I’m sure we’ll get to that point, uh, with the arrival of AI agents, we need something else. We need an orchestration unit. One or two people who have as their goal orchestrating the AI agents. Orchestration is the term nowadays of managing AI systems basically instead of humans. That obviously is missing from team topologies, because team topologies is pre-AI and is also missing in unFIX cause unFIX is also pre-AI. But it just shows that a pattern language needs to evolve over time.

Another thing that I mentioned that I borrowed actually from other sources is the teaming options. In the Agile community, we’ve always been very reluctant to have people switch between teams, because we say ah that’s actually not a good idea. That’s an anti-pattern because it’s, context switching is bad, humans are not good at that, that you should focus on one product only throughout the week. And that makes sense to some extent. However, in other industries, they do a lot of reteaming. If you look at fire departments or hospitals or the airline industry, every day people are on another team. And those are usually sub-teams out of a larger super team. I was not the first one to point that out. There’s a great book by Heidi Helfand, it’s about dynamic reteaming where she also says, well, actually sometimes it makes sense for people to form different teams. The problem is the context switching. How do you solve that? Because this hurts a lot in software. Like it’s pretty easy for an airline attendant who goes from one plane to another, because both planes are exactly the same. That’s the whole point for airlines to standardize on the same type of plane, so that’s easy for the cabin personnel to switch between planes and between one team and between different teams. But how do you do that as a software architect from one product to the other if it’s a completely different product, right?

Well, there AI comes in nowadays. AI lowers the the the barriers because artificial intelligence is able to give you much more information and dashboard full of the up-to-date information on the architecture and product and the latest changes, and who did what and what are the consequences of the last release and so on. It’s a bit like, as I always say, it’s a bit like a surgeon moving from one operating room to another. The patients are all humans but they have very different problems. But there’s machinery showing you all the information about heart rate, blood pressure, brain activity, medication, and you name it, and then the specialist can do their job. And I think the same is now happening with software engineers and software architects that makes it easier for them to switch contexts between one product and the other. Because our AI agents, our machines will tell us, give us up-to-date information about that other product. And that lowers the bar for context switching.

And that is a benefit from an Agile perspective because organizations that are, that train themselves to do dynamic reteaming can be much more agile in an environment that changes fast. Because you can respond faster to risks and opportunities if you can respond with whoever is at hand at that moment, form a team, form a squad, and go. You don’t have to wait for a standard Scrum team to be available in their next sprint planning, next Monday morning or something, right? And because that is already too slow these days. So I offer in the unFIX model already some teaming options like what are the different ways that you can do reteaming. And, uh, yeah that’s just another example of a couple of patterns in unFIX.

Henry Suryawirawan: I think that’s a great point that you mentioned about, you know, being able to dynamically reteam, right, switch context or even understand different codebases. Because I think we know, we all know software engineers, uh, almost different codebases are snowflake, right? So they’re different in its own kind, even though maybe they use the same language, same framework. But the way it is implemented is always kinda like unique across different teams. And yeah, probably AI will be able to help us lower the barrier, be able to understand the context and even try to suggest some improvements that we can do, even though we are not the domain experts in that codebase.

[00:31:39] Pipedrive Case Study: unFIX in Action

Henry Suryawirawan: So I think the name of the model itself is quite unique. I dunno whether it is intentional. You mentioned it, unFIX. Uh, so my next question is throughout your journey popularizing this model, right? Do you think there are some stories that you can share? How do you actually unfix maybe technology organizations and what actually they did to kind of like fix themselves?

Jurgen Appelo: Absolutely. Yeah I was, uh, I was quite happy with the name myself, to be honest, cause it was the idea of breaking things apart like Lego blocks, just reducing frameworks to their individual components and then remixing them. So I started out actually coming up with a framework for innovation and experience. But then I thought, no, it’s not a framework. It’s an, it’s an un- framework. unFIX. That’s it! unFIX, I thought. And to my surprise, the domain name was available, unFIX.com. What were the chances? So I immediately registered it and, uh, yeah. So I think that was uh one of the good moments in my life.

But then, yeah, I started writing about the patterns that I had found and let’s be clear here. These patterns already exist, right? It’s not like Christopher Alexander invented cities. He went around cities that already existed and observed which patterns work well. I do the same with the unFIX model. I observe what organizations are already doing, what seems to be working and then I describe that as a pattern so that others can consider if they want to do the same thing.

One of my favorite stories is the company Pipedrive in Talinn. They are a SaaS platform, CRM vendor. Pipedrive reached out to me and they said well actually what you described in your recent blog post, that looks suspiciously like what we are already doing here. Uh, can we talk? And I said sure. I mean, that’s great. And that became my first case study of a company who had already implemented a number of those patterns that I had simply observed. And they also did reteaming and they have a base and they have, uh, the small mission teams that went on a mission for a couple of weeks, couple of, uh, months to complete a feature set. And then they dissolved as a team and then they formed another team for another feature set, uh, within a larger tribe. So they had tribes that were like 20-ish, 25 people. But they were stable but within those tribes they did a lot of remixing of people depending on what they wanted to work on.

And there was always one team that took care of the bug fixes and the maintenance. They call them the launchpad. They were the teams that took care of what the others did not want to do while they were making new features. And that was actually brilliant cause they came up with the idea that if you have worked on a launchpad for too long, you’re expected to go on another mission. I mean don’t do only maintenance, you have to go and build something new. But if you build a couple of new features, it’s time for you to go back to the maintenance to actually take care of the stuff that you built the previous half year, right?

And so they have this continuous rotation of people within one tribe so that they did both maintenance and new product development but not at the same time. And I thought that was a very elegant solution to the problem that many software engineers have that they don’t want to do new product development and maintenance at the same time, because that drives you nuts. The bug fixes and then maintenance requests that come in while you’re designing a new feature, uh, feature set. So they split that and they said well there’s a rotation of people within our tribe, with 20, 30 people. We keep those groups separate but everyone does everything. So you build it. You own it. It’s still true. Only you don’t build and own at the same time.

And I could match that exactly with the patterns that I had in the unFIX model because I could show, look, I already indeed, I have teaming options. The reteaming patterns. I have the tribe pattern, which we call the base in the unFIX model. We had the value stream crews. The patterns were there. But what was unique was at Pipedrive combined them in a way that I had never imagined myself. So it was like you give someone Lego and they make something of which you say, whoa, awesome! I knew about the bricks but what you made out of the bricks is something really really cool.

This is one of my favorite examples still but afterwards, this was a couple of years ago, of course, other people have started out with the unFIX model and started playing and they make their own design. So that’s the whole point. Everyone should make something for themselves out of the Lego bricks. I’m not a coach or consultant so I’m usually not directly involved with what companies are doing with my unFIX model. But they send me messages and screenshots every now and then, the pictures of the designs and that is super cool to see what people are doing. And, um, yeah so there’s a number of case studies on the unFIX website for anyone interested if they want to dive deeper into the examples.

But, uh, very important warning message, do not just copy what another company has done, right? So you’re not supposed to implement the Pipedrive agile framework, cause the Pipedrive agile framework is perfect for Pipedrive. It’s not perfect for anyone else. But you can be inspired by what they did and then say, oh, I’m going to make my own framework out of those patterns. And that’s the best that I can hope for, that people do that.

Henry Suryawirawan: Yeah, I think that’s a great disclaimer, right? So obviously many people still want to chase kind of like the gold plated solution, right? So this is the thing. Then they just follow and they think it will be successful. Again, I think it’s a good reminder because I think in the past, I also used to run some organization teams as well, right? It’s always difficult, right? Because you have a specific context that probably is different than what people are preaching for in their frameworks and models, right? So you always kind of like have to find your way out by yourselves, right? Depending on the situation, depending on the context, the people that you have, right? Could be different. The culture that you have. Thanks for bringing this up. The unFIX patterns that people maybe can look at. 200 patterns, uh, sound quite a lot. But hopefully there are some successful ones that you kind of like highlight on those websites. And we’ll make sure that, uh, we’ll put that in the show notes.

[00:38:16] M3K: Merging Management 3.0 and unFIX

Henry Suryawirawan: So I think the next evolution of your work, which is quite recent, right? So you have Management 3.0, you have the unFIX, and you evolve by, I dunno, combining both of them into this thing called M3K. And I think this is also aptly because of the Age of AI. So tell us about this story. How did you come up with this M3K and what does M3K mean?

Jurgen Appelo: Yeah so the story is that both Management 3.0 and the unFIX model, those are two different sister companies, basically. I sold Management 3.0 at some point cause I was tired of doing the same thing. I was still sort of involved, because it’s, it was my baby obviously. So I know the team. I did my own unFIX thing. But in the Agile world, there was less and less demand for workshops in the last few years. And the workshop facilitators were our customers. So that’s an issue. I mean if your customers don’t have work then you yourself don’t have work either. So we saw licensing declining. And this is not just for us, it’s for the whole industry. It was facing the same problem. And then some people said why don’t you guys join together Management 3.0 and unFIX? I mean they’re a perfect match, cause management organization design, it seems to make sense to merge that. And yeah I got together with that team and said, yeah, let’s just do that. That became M3K.

We started with what comes after Management 3.0? Is that Management 4.0? But then we said, nah, boring. We’re going to have to keep updating the version numbers every few years. Why not Management 3000? So that is management until the end of this millennium. That, that will, that brand will stay for a while but then we said okay well we will use that as the working title. And then informally within our team we stopped saying Management 3000. We started referring it to a to just M3K. It was easier. It rolled off the tongue more easily. So after two months we said, wait a minute, isn’t M3K the brand then actually instead of Management 3000 because it’s easier to say? Everyone was yeah, yeah, yeah, of course. So we made it M3K which is now the combined brand for what is Management 3.0 and unFIX that are still, they still have their own websites, but over time this will probably be merged into one thing.

Again I’ll be, uh, transparent here. I’m just an advisor to the team. That’s the role that I play. It’s other people who do a great job. They had to downsize because of the economic reality that they were faced with. Uh, slashing costs. Uh, but, uh, the company survives and they’re doing wonderful, uh, work. I meet with them once per week to see how things are going, offer them ideas. I meet with them next week, uh, next week again about the ideas for next year. But my focus is on other stuff with my Substack, I’m sure we’ll get to that in a moment. And, uh, meanwhile, I’ll look over the fence what they’re doing at M3K, and if they need my help for anything, I’m happy to share any advice. And they can take it or they can ignore it. It’s up to them.

[00:41:33] Skeptical Enthusiast: Balanced AI Perspective

Henry Suryawirawan: Yeah, thanks for sharing this, uh, background story, right? So obviously now is the right time probably to jump into, you know, the topics that people are talking about a lot, which is AI, right? You have this Maverick Mapmaker Substack, right, the newsletter that has quite a lot of articles already. Some of them are quite intriguing and popular. And also you have a book titled Human Robot Agent, right? So this is purely a book about, you know, how we deal with AI. So tell us, in your view maybe first of all right, um, about AI, are you proponents of AI? Do you feel positive? Do you feel negative? What is your view about all this AI craze these days?

Jurgen Appelo: I call myself a skeptical enthusiast. I often sit between the two camps. I am not an evangelist who says everything will be great and AI will solve all problems, because I think there are many problems to solve in the short term. But I’m also not an alarmist. I don’t think that we will have a robot apocalypse or something like that. I think in the end AI will be beneficial for humanity, but it is like one step back two steps forward. That is I think the most realistic approach. Yes, many people are losing their jobs but there is a prediction that we will have more jobs than ever. We just cannot predict what kind of jobs those will be, but that we will suffer temporarily as happened with previous, uh, revolutions in the business world or the industrial world. Um, so I’m a skeptical optimist, a short-term pessimist, and a long-term optimist, as sometimes I say. And that’s what my book is about. Indeed, I have it here, Human Robot Agent that I collaborated on, of course, practice what you preach, with ChatGPT and Gemini and Claude just to see how I can make a team out of AIs. And that’s a lot of fun.

Like one of my favorite use cases is I had a gem in Gemini that looked, that reviewed everything that I wrote and then tried to tie it to a scientific principle or law or paradox or whatever. So for example, when I say that humans have a tendency to overestimate technology in the short term, then Gemini would say that is Amara’s law. We overestimate in the short term and we underestimate in the long term. And yes, indeed! I should mention that because that makes me look smart as an author if I mention that. And uh I said also at one point, I’m a short-term pessimist and long-term optimist. And then Gemini said that’s a Stockdale paradox. Well, I have never heard of the Stockdale paradox, Henry, but indeed it exists. The Stockdale paradox, you can look it up. So I mentioned that. And I love that of AI. It’s like this team that is helping you out with editing and reviewing and just raising the bar for you as a professional. You can do better work than you have ever done before, because you have your onsite copy editor, development editor, et cetera available 24/7. I mean, I never had that with my previous books. And, uh, I love that and I practice what I preach.

I write about this and I try to figure out what are the consequences of AI on the future of work. And there are quite a few consequences, some very practical ones. Uh, team sizes are getting smaller. I am old enough to remember that we discussed the optimal team size is five plus or minus two. Well, now I think the optimal size is becoming two plus or minus one. It’s one, two, or three people is the optimal team size plus a whole bunch of AIs. And, uh, there’s more and more reteaming. We discussed that earlier, because AI is making that cognitively, uh, that cognitive constraint is being reduced. There is this big issue of algorithmic management that we already see in companies such as Uber and Takeaway.com or whatever the freelance platforms, but also in more traditional enterprises, Amazon warehouses and whatnot, where people have digital bosses instead of human bosses. What are the consequences of that? Some people love it, some people hate it. But it is very important to discuss how you want to employ such algorithms to manage part of your workforce. That’s just three examples.

I, when I wrote the book, I set out to understand what are the human, the psychological, the sociological consequences of introducing AI in organizations. Because there are already so many people writing about prompt engineering. I mean, I don’t need to cover that. They do that much better than I do. But there are not many people focusing on the consequence for humans as teams. How will teams work differently? And I think that’s a fascinating topic. So I wrote a book. Uh, it came out a number of months ago and I basically moved on to Substack. All my new writing is there but still about the effects of AI on the future of work.

Henry Suryawirawan: Yeah. So I think it’s quite fascinating, right? And especially, um, for sharing your usage of AI agents in coming up with the book, right? I think the trick with the gems, I think, sounds really interesting, right? So for people who are aspiring to write a book, I think now it’s possible, right? Uh, if you probably use AI to leverage, you know, some of the things that you think you couldn’t do before. And I think what fascinates, um, me about the book as well, like you mentioned, right? It covers the leadership, the management, and organizational design part of, you know, the impact of AI, right?

[00:47:18] Co-Creating with Humans and Machines

Henry Suryawirawan: And one special thing that, um, like we all know, right? Uh, you also touched on in the beginning that now we have to kind of like collaborate not just with humans, but also with agents. So kind of like co-creating stuff within our role, right? So tell us maybe this first thing, right, the biggest impact that we all should be aware of. Either we are individual contributor or manager, right? What do you think would happen when we do this co-creation between, you know, human and machines that will become much more prominent?

Jurgen Appelo: That is a fascinating topic in itself, cause when we mix humans and machines, some of us might get confused. Like we discussed earlier the difference between Management 1.0, command control, versus Management 3.0 is managing the system not the people. That is perfectly fine when you realize that each moment whether you’re talking to a machine or talking to a human, because they need different kind of management. That might have consequences when we mix it all up. When we, I mean literally when we are on Slack or on Microsoft Teams, for example, and sending messages. And some messages are to a fellow human and other messages are to an AI agent. Are we competent enough to realize that those are very different kinds of teammates that we are talking to? We should not mistake the humans for machines and we should not mistake the machines for humans.

I think it’s still very early to see the consequences of this but think we’re going to see some damage in some organizations where people mix up the humans and the machines, not realizing that, well, actually they need different approaches. You should not try prompt engineering on a human. The human does not really appreciate that. To be talked to in that manner, while the AI agents loves it, because it’s clarity that it gets, right?

So I’m just hypothesizing here but I think it’s not very hard to see these things coming when you simply follow the trends. And it’s still early days with AI agents. I mean, at the start of the year, they said 2025 will be the year of agents. Now this week some people said, well, actually going to be the decade of agents, because agents are still so bad at this point with memory and context. And self-improvement is still severely lacking behind what we would expect from human level intelligence. So it’s going to take much longer. And not to mention, all the security hazards that we invite once we start working with AI agents. And I think that’s good. It, I think it’s actually good that it takes longer. I mean, this may also be Amara’s Law again, we overestimate technology in the short term, right? I mean same with AI agents. But in long term, we might underestimate what AI agents will be able to do for us 5 to 10 years from now.

But the positive message here is we have time. We don’t need to panic. We don’t need to rush with AI agent implementations. We have time to figure things out to make sure that we are EU ACT compliant, uh, AI act compliant, that things are safe and secure and whatnot. I think that’s a good thing, because we humans are slow. So we need time to figure out how not to confuse the humans with the machines. Because, yeah, you might temporarily give your password to your teammate, because you trust your teammate is a human, and you have a beer together at the end of the day. But you should not do the same with an AI agent. Because that password should not end up in that agent’s prompt or context. And, um, yeah. These things, I’m sure they’re going to happen often enough in the next few months and years.

Henry Suryawirawan: Yeah, so when you mentioned about that, I read articles recently about, you know, some people trying to use AI, treating them like God. Some people treating them like a psychologist, right? So this is probably some examples where kind of we kinda like confuse the current AI, you know, with people, with human, right, uh, especially friends, you know, relationships and things like that. So I think what you mentioned is, uh, sounds fascinating and thanks for giving us some encouragement as well, right? There’s still time for us to adapt and kind of like learn how to use AI much, much better.

[00:51:51] From T-Shaped to M-Shaped Workers

Henry Suryawirawan: Which brings me to the next question. Like we all know we are gonna be disrupted, right? Everyone’s gonna be disrupted. Our skillset probably is gonna be changing by a lot, uh, I would say. So what do you think we should do in terms of, you know, reinventing ourselves, learning new skills? And I know you mentioned a lot in your book and your articles about the M-skilled worker. So maybe, um, what would be your advice?

Jurgen Appelo: Great question, Henry. I’m glad you asked, cause it’s one of my favorite topics. The M for multidisciplinary people. It is this idea that actually relates to that context switching we discussed earlier. Some of, uh, listeners might be familiar with the term T-skilled person. That’s the person who has one specialization where they go deep like software engineering, for example. But they also have some horizontal additional skills. Like they know a bit of product management, they know a bit of social media marketing or whatever. We talked about that for 20 years, also in the Agile community where I am from. Nowadays, we move to the M-skilled person which means that you have multiple specializations, multiple areas where you can go deep, and you have that horizontal bar on top that allows you to connect those disciplines.

A great example is many Nobel Prize winners are actually multi-skilled. They are, for example, molecular biologists and astrophysicists or something like that. Why? Because that helps them be more innovative. They can transplant ideas from one domain to another. Something that is not a common concept in one area could benefit from something, why that is very normal in another area. So you, that cross pollination of ideas across domains makes people more innovative. And that is actually where we humans can add value beyond AIs. Because the AIs are the masters of specialization. I mean they’re fantastic video creators or text writers or whatever. But it is for us to connect the dots.

Second reason is AIs take over one job after the other. I mean my good friend was copy editor in the past. Well, he can forget about that. He has no work anymore in copy editing as you can imagine, because everyone writes their own copy now themselves with ChatGPT. So he needs to adapt. Well, now it’s copy editing or his video editing, or next is something else. Then there’s always a job falling away. So we need to hedge our bets. Have multiple options to be safe so that if one discipline drops away, well, we have still two others. So let’s focus on those for a while and meanwhile learn something else to replace the one of those three legs that has dropped out, right? That helps us be better employable in the future.

And a final reason is, as I said, teams are getting smaller. So that traditional Agile team that normally had five or six people on it, nowadays, may have only two people and a bunch of AIs. Well, those two people, they better be multi-skilled, because they will have to cover the complete array of disciplines that you would need on an Agile team that would normally have been covered by five people, right? And now, it is two people plus a bunch of AIs. So they will have to understand what the AIs are doing to be able to correct them to prompt them to manage them orchestrate their work.

So those are three different reasons for moving from T-skill to M-skill, is hedging your bets, is being more innovative through the cross pollination of ideas, and uh it is because team sizes are getting smaller. I think that is, one person said on an article, this might be the very definition of what AI is doing to us humans. It is making us multidisciplinary, because that is where the true differentiator, the value add is for us humans on top of those AI helpers, AI agents assistants that we have around us.

Henry Suryawirawan: Wow, I think thanks for the insights. So I think, um, thinking about it, I think it’s quite true, right? So we are being expected to become more kinda like generalists, understand more disciplines, right? Being able to crosspollinate ideas probably, right? Um, so leveraging AI that could probably specialize in their own skills, right? Be it software engineering, copywriting, whatever that is, right? So I think your book is definitely kind of like an interesting book for people to read. And if you are interested in the topics that we just discussed, feel free to check out the book.

[00:56:38] Why I Trust AI More Than Humans

Henry Suryawirawan: So the last few minutes, I wanna cover some interesting, intriguing topics that you have in your Substack newsletter, right? The first thing, uh, which is kind of like a very, very controversial for some people, right? You mentioned that you trust AI more than human. I think many people these days are thinking, oh, AI can hallucinate. You know, they need to be fact checked, they need to be reviewed. Why you have this opinion of that you trust AI more than human?

Jurgen Appelo: Yeah. So, yeah when I share, as I did last week online, that I asked my AIs for advice, then there are always some people who say, well, but ChatGPT is just a stochastic parrot. It is just token prediction. It is just this or just that. And that’s true. I mean, yes, they do hallucinate, but ChatGPT hallucinates less than the people around me, because the average human is pretty stupid. No offense. I mean, just look at what people are talking about on social media. Look at what politics, uh, politicians are talking about. A lot of it is complete nonsense, if you do the fact checking. On average, the AIs are better than the average human being.

Now, I’m doing the comparison between average. Of course, there are expert humans who are better than the AIs. But my point is those experts are often not available to us. Like if I wanted an expert therapist, yeah, those cost money. So of course, a real therapist is better than ChatGPT. But the, that person might not be available, might be expensive. I might have to travel an hour to get to the to get to the therapist and they might be fully booked, or my insurance doesn’t cover it, whatever. So my second best option is ChatGPT. My third best option is my friends and family, right? And that applies to everything.

I gave an example of a question that I asked last weekend. I’m reading books on cosmology, because I love understanding how the universe works and things like that. And I have this question. I didn’t just understand that the concept of relative time versus absolute time. I thought there was a discrepancy. So well if I ask my friends, they will look like deer in the headlight. They will have no idea what I’m, what my question is about. Of course, I could go to Brian Cox or Neil deGrasse Tyson, the real cosmologists, but they’re not available in my circle of friends, right? I cannot just call them. So my second best option is to ask the AI. So yeah I asked Gemini and I got a fantastic answer and then now I understand the answer to the question that I had.

So that’s the point that I wanted to make that, yeah, AI is, I trust AI more than the average human that I have around me when it comes to complicated complex questions, because the AIs are actually trained on the knowledge of all of humankind. And yeah, they might do stupid things every now and then. We have to take that into account. They’re not real experts. But the real experts, they cost money and they’re often not available. So then ChatGPT is a good second best option.

Henry Suryawirawan: I think that’s quite funny the way you explain that, right? So I think, yeah, it’s kind of true, right? So sometimes we want to learn just a little bit of that skill, right? It’s always difficult to find someone experts enough to give us the advice. Uh, you may be able to find it online, but you still need to spend some time to actually figure it out, right? So I think AI can help in this case. Uh, definitely.

[01:00:19] Scrum Is Done (Not Dead)

Henry Suryawirawan: So the next thing that I think is quite controversial, uh, maybe not so controversial for some people, right? You mentioned that Scrum is done. It’s finished. This may be associated with Agile is dead as well, I guess. So yeah, tell us about this, uh, Agile thing. Is it something that we all should, uh, move on from now?

Jurgen Appelo: Yeah. So of course, I got some flack for that title Scrum is Done. I did not write Scrum is Dead. But I knew that it would trigger some reactions. I said Scrum is done. Like my book is done. I have my book here. It is done. It is not dead. That is something different, right? So people need to understand this the subtle difference between done versus dead. Um, my book is done, Scrum is also done. It did a great job. Let’s just face it. It had tremendous effect in the Agile community. We can praise it for everything that, uh, Ken Schwaber and Jeff Sutherland and the entire Scrum community have achieved. But it was written for an pre-AI age. You can see that in its practices. The AI agents don’t need standups. The AI agents do not need a monthly retrospective. There’s lots of things that they don’t need.

And my, the point that I make in the article is, if Scrum, as it is written in Scrum guide, is your default framework, you are holding back the artificial intelligence. You’re slowing them down, cause the AI does not need Scrum. It’ll go much faster. You’re going to need what I call a dual track system where the humans might be doing Scrum, but the AI agents will be doing something else. That is Agile to the max. And yes, they are having a lot of Agile is dead articles for the last year or more, what is actually dead is the Agile industrial complex. Everyone who made money with Agile, their jobs are dead. Because all businesses need to be agile nowadays. And I often say that I think that artificial intelligence is doing more for Agile than the consultants and coaches have ever done. AI is doing to Agile what COVID did to remote working.

You remember that, Henry, when pre-COVID, lots of organizations they didn’t wanna do remote working and that sounded dangerous. And then with once COVID hit, everyone was working remotely because they had to and then people found out, well, actually this works pretty well. With Agile, it’s the same thing. There were still organizations that didn’t like Agile, they didn’t like all the suggestions, uh, with Scrum and other methods and frameworks. But now with artificial intelligence there is no way back. They have to be faster. They must accelerate. Nobody cares if you call it Agile or not. You will be agile. And we just don’t use the word Agile anymore. I don’t think anyone at OpenAI or Anthropic uses the word Agile. Why bother? They’re already agile to the extreme.

So the same is going to apply to everyone. But Scrum as a framework, that was, and I used the word was intentionally, that was a fantastic framework in the pre-AI age for humans. But now we have humans and artificial intelligence on the same team. We basically have to reinvent what agile means in the years ahead. The humans can be on the slow track but AI agents will be on the fast track. And that is funny because 20 years ago the Scrum team was on the fast track while the traditional organization was on the slow track, right? Scrum was fast compared to the rest of the company. But now Scrum is the slow one, if you do Scrum by the book, and the AI agents are going much, much faster. But we still have humans so we’ll still have people doing Scrum.

It’s done, it’s not dead. Like I hope people still enjoy my book. Movies that have been out for many years. I mean, many of us still love Star Wars or whatever, those movies are done. They’re not dead. We can appreciate them for what they have done for their accomplishments and we can still enjoy them, but we have to face the fact that the world has moved on. And same with AI in our work. We’re going to find out and I’m, I wanna be part of that new wave of what Agile looks like when we are all AI native, basically. And the human speed is going to be the exception in the future, because most of the work will actually shift to artificial intelligence where the real business model is being optimized on a minute by minute basis. And the real humans, they will have their pockets of slow productivity not grinding down the AIs or not holding the AIs back cause they are on a much faster track like that. Like the Japanese Shinkansen is not being bothered by any slow local trains that are on their separate tracks, right? That’s what, that’s the human track, basically.

Henry Suryawirawan: Wow, I think it’s a very good food for thought, right? So people who are still kind of like in this Agile mode, we are still kind of like doing Agile. So now I think if you don’t implement AI, you’re gonna be disrupted and it’s gonna be even faster, right? The way that you’re being disrupted.

[01:05:50] Redesigning Organizations for AI: Fast and Slow Tracks

Henry Suryawirawan: So maybe one last thing, and we mentioned about all this, right? So one other article that I find really fascinating, you mentioned about let’s start from scratch in terms of organization design. Because we understand the impact of AI, it’s quite big, right? It’s massive. Everyone’s gonna be disrupted, job’s gonna be disrupted. So why you bring a case of, you know, let’s start from scratch again, how do you design organization?

Jurgen Appelo: Yeah. Well, it relates to what I just said that basically, well, I use the the the analogy of trains in my article. Um, I have experienced traveling up and down between Rotterdam and Brussels. There are slow trains and there are fast trains, and the fast trains are on their own track. There are separate tracks so that they cannot be held back by the slow trains. You need something similar in organizations where the fast employees which are the AIs, they’re not held back by the humans who operate more slowly. But you want to benefit from both. It’s not like you will only have fast tracks, you will only have AI. No! There will still be humans but they will be slower. But they still do important stuff. Like we also still have slow local trains parallel to the fast trains.

But that’s why I wrote we have to start from scratch because the frameworks that we have, including the unFIX model as a pattern language and team topologies and the Spotify model and all those models and frameworks that we made, they’re all pre-AI. That’s why I say, well, that I think we have to start from scratch, uh, Henry, because we now have to think AI first. We have to give priority to the high speed trains. Those need to be on their destination super fast and the slow trains will have to work around it so that they don’t hold them back. But that means reinventing the infrastructure. The infrastructure of work has to be reinvented. And, uh, I think that’s a fascinating challenge for the years ahead.

Um, I know many people are already working on that. To be honest, many are focusing on the technical aspects of AI agents like with protocols such as MCP and A2A, and whatnot That’s important, that’s good stuff. I mean those AI agents have to understand how to use each other’s services. But the interesting part for me and others is that interface between the machines and the humans. Let other people write the protocols for the machines, that’s fine, that’s great. I would like to be involved in the protocol for how do we connect between the machines and the humans. How do we get people to transfer from the fast trains onto the slow trains, and vice versa? That requires logistical planning, right? And it’s the same in the future of work. If we still have humans and we don’t wanna hold the AIs back, uh, we need to figure out how to reinvent our work. And, uh, yeah that is mostly uncharted territory. That’s why I call my Substack the Maverick Mapmaker. I’m the mapmaker, I’m trying to explore where we’re going in the future of work and then drawing maps as I go and share them with everyone.

Henry Suryawirawan: So I think thanks for kick starting that, right? So somehow when you mentioned about fast track, slow track, right? It reminds me of Daniel Kahneman’s book, the Thinking Fast and Slow. So it’s not like we always have to think fast, right? Sometimes thinking slowly, deliberately, consciously is still very important. And that’s why I think humans will still have a value in this whole, you know, disruption, age of AI kind of stuff, right?

[01:09:25] 3 Tech Lead Wisdom

Henry Suryawirawan: So thank you so much for this fascinating sharing. So unfortunately, we have to wrap up pretty soon, but I have one last question I would like to ask you. I call this the three technical leadership wisdom. It can be any kind of leadership wisdom, I would say. So would you be able to share your version today, Jurgen.

Jurgen Appelo: Um, gosh, there’s so many things that pop up. But usually, the first thing that I answer when people ask me what is the number one skill or requirement for managers, leaders, and teammates in the future work is critical thinking. Uh, we touched upon it with the topic of trusting AI more than humans, uh, which is a little bit tongue in cheek, of course, because human experts are still better than AI. But when you ask questions of AI or when you ask questions of your fellow humans, you need to be critical. And I actually think that maybe it’s a good thing in a way that we are now bombarded on the social network with all this AI generated crap and slop of which we do not know anymore what is real and what is fake, because this trains us not to believe by default anything that we see. We have to get better at that. And I think we are now the generation that has to go through this personal transition that you get more suspicious of everything that we are shown, because it could be fake, and we need to be trained. We need to realize that this may not be true. And I tried to do that myself.

Like very concrete example. Just half a year ago, I saw a news item about the Ukrainian versus Russian War. And there was something that I agreed with. Uh, it was that Europe had donated three times more to Ukraine than the US. And of course, I was ready to retweet it, because I mean I’m a European. I thought, yay, Europe is doing more. But then I thought, no, wait a minute. Let’s fact check this. And it turns out it was not true. It was, it was false. Uh, it was that the US and EU had done just about the same.

So I was so happy. I was proud of myself that I had held back and I did not just share that false meme that was going around. And I think this is, yeah, evidence of my personal transition that I try to observe everything more skeptically. Whether it is AIs giving me advice or my human friends sharing memes that might be false. I have to always think, hmm, wait a minute. Is this is really true? And I think that is the number one skill also in organizations because we are facing some very dangerous times with deep fakes and artificial intelligence being used as a weapon against companies, basically. We need to train ourselves to be, uh, more skeptical of what we observe.

Henry Suryawirawan: Any other things that you would also convey?

Jurgen Appelo: Other things, other ideas. Well, um, the multi-skilled person, of course, we talked about that, is maybe suggestion number two for people to pick up more skills. I have actually, I went back to drawing. I did a lot of drawing when I was a kid up to, uh, when I went to university. I did a lot of cartoons. I said I love drawing. But then at the time, I thought I’m gonna make more money as a software engineer than as a cartoonist probably. And I was right, I think. But now, uh, now that I see AI is taking over all these digital skills, I thought, hmm, maybe I should go back to something manual again because that is very hard for AI to steal if I am a decent cartoonist or whatnot. So it’s just an example of a new skill that I am now developing and that is my message to people. Just pick up something out of the ordinary and decide to go deep there, just… I actually bought a drawing table, a sketching table. It’s in the room next to the next door. I use it now for drawing and I love it. So yeah my number two suggestion for people is to become multi-skilled. The M-skilled person is very important.

And if it’s, uh, if there’s a time for number three is play with AI. I mean just get used to it. I see, I still talk with people who have rarely used machines as advisor or as coach or consultant or whatnot. Or just as an assistant in producing stuff. It surprises me because it’s, you can have so much fun with AIs. And you can only imagine new business models and new, yeah, new jobs of the future once you see what the possibilities and what the drawbacks are of the machines, where they, uh, make a difference and where they suck. And that gives you ideas as a professional of what you, what kind of value you could be offering next year and the year after. So even if you’re skeptical of AI, if you, even if you think AI is not always a good thing as I do, you still need to use it a lot just to know where it shines and where it’s, in which areas it’s a complete disaster. And there you know, okay, humans can make a difference there, because this is not what AI are good at.

Henry Suryawirawan: Yeah, so I think for people who listen, right? So I think do play with AI tools. Although I know it’s kind of like tiring these days to keep up chasing, you know, the new things invented in the AI world, right? Um, but the message here is clear, right? So we have to, move ourselves up, be more M-skilled kind of like person, right? Pick a more multidisciplinary skills, pick up something that, um, you know, in the past probably you’re good at, but you kind of like left it behind somehow. Maybe that could bring something new, something authentic, uh, from the human side of you as well. And yeah, obviously, critical thinking is very, very important in these days. So many, you know, scam, deepfakes, um, you know, fake news and those kind of stuff. So definitely having critical thinking is still kind of very, very important.

So thank you so much, Jurgen. So if people want to reach out to you, ask you more questions or maybe, uh, follow you along, is there a place where you would recommend them to go to?

Jurgen Appelo: I hope that they will subscribe to my newsletter on Substack as the Maverick Mapmaker You’ll find the media, Jurgen Appelo. I’m sure you will add it to your notes. That’s the number one destination. As you find my newest stuff, my newest essays, uh, I really try to do my best. And Henry just two days ago, I was announced that I’m a Substack bestseller. Woo-hoo! I earned the badge. I was so proud of myself. So it means I have 100 people paying for my coffees cause if people, if people become a paying subscriber which is a very small percentage, they pay for the coffees that I need to do my writing. That’s a lot of coffees I can tell you, Henry, that I need.

Henry Suryawirawan: Yeah, congratulations, by the way. I know that it’s, uh, kind of like tough to produce those kind of, uh, I would say, they’re kinda like authentic, uh, insightful and controversial at the same time, right? Some are really, really kind of like, you know, twisted your mind a little bit to think in the different perspectives. So I think I highly recommend people to actually subscribe at least, um, and if you like it, please, kind of like contribute to Jurgen’s coffee. So yeah, highly recommend the Maverick Mapmaker Substack.

So again, thank you so much Jurgen for this time. So, uh, hopefully people learn a lot about a lot of things, organizational design, how to deal with AI and things like that. So hopefully you keep on inventing new stuff that we all can learn from you. So thanks again for that.

Jurgen Appelo: Thank you, Henry. Great questions and I love the conversation. Thank you so much.

– End –