Simone Cicero 

Hello, hello everybody, and welcome back to the Boundaryless Conversations Podcast. On this podcast, we meet with pioneers, thinkers, and doers, and we talk about the future of business models, organizations, markets, and society in this rapidly changing world. Today I’m joined by my usual co-host, Shruthi. Hello Shruthi.

 

Shruthi Prakash 

Hi everyone.

 

Simone Cicero

Thank you so much for joining us. We are excited because today we are joined by Cliff Berg, co-founder and managing partner of the Agile 2 Academy and the leading figure in Agile and DevOps advising worldwide. Cliff is the lead author also of Agile 2, the next iteration of Agile, bringing a very fresh perspective on Agile methodologies. Cliff has an extensive experience as an executive leader advisor.

 

Cliff has also helped shape the Agile practices of many organizations worldwide. And today he will share insights into the evolution of Agile, especially in what’s ahead, a topic where I intuitively believe that we share a lot of common ground. Cliff, it’s very great to have you with us today.

 

Cliff Berg

Thank you, Simone and Shruthi. It’s a pleasure.

 

Simone Cicero 

Thank you so much. So as an opening question, I would like to ask you to maybe share a little bit of a background story of how you, you know, what was your experience in mid-wifing the Agile 2 thesis into life? Because, you know, for those of you, of listeners who follow your work, you know, these ideas of Agile to some level of discontinuity with how we normally identify Agile as a topic in organizational development and design and software development. So I leave it to you to tell us a bit more about how this idea came up together with your fellow writers and doers.

 

Cliff Berg

Yeah, sure. Very interesting story. I’ll try to be really brief. You know, when the Agile Manifesto came out in 2000, I was CTO of a company called Digital Focus and we had about 200 people and about somewhere in 2000, one of my project managers came to me and asked, what our team wanted to start using extreme programming.

 

And, uh, you know, extreme programming was really a hot topic at that time. Everybody was talking in IT was talking about an extreme program. What is that? And it sounds so cool and so on. And so I, yeah. And I respected those people. I trusted them. This project manager and the team lead in that team. And I said, try it. And it worked out really well. And so we adopted it across the company.

 

My company became a major sponsor of the Annual Agile Conference after the Agile Manifesto came out and the Agile Alliance was formed. But then I watched in horror over the years as, you know, because the Agile Manifesto created the Agile Movement, which kind of supplanted, kind of took the mantle from extreme programming. You know, before the Agile Manifesto, it was XP, XP. And all of a sudden, it was Agile, Agile. And interestingly, they don’t align well, because XP is extreme by intent, whereas the Agile manifesto is very much about balance, not extreme. But no one kind of noticed that discontinuity. So anyway, but it’s all good. There are different ideas. 

 

But then as the Agile movement kind of started to gain steam and be used at scale in companies, things didn’t work out kind of that well. And then you started to see a proliferation within what became the Agile community of different focuses. And the Agile movement became very much about human and behavioral process things, which are all really important. In fact, it’s kind of the most important thing but started to ignore the whole technical side. And so that kind of bifurcated the movement. As a result, DevOps became its own thing instead of part of the Agile movement, even though early proponents of CI/CD (Continuous Integration/Continous Development) were identified as Agilist. But so much dysfunction grew out of those times.

 

You started to see from very early on these frameworks, starting with Scrum Master Certification – really created a very bad trend. So over the years, in fact, 10 years after the manifesto, the British Computer Society did a study of the state of Agile and they found, they basically listed all these dysfunctions. And when the pandemic started, a few years ago, it then was 20 years in and those same dysfunctions were still in place. In fact, they were more deeply embedded. And so I thought, you know, this sucks. We have to do something. And I had been for years, uh, working, uh, with, uh, companies to help them improve their DevOps approach. Like, uh, right. My last engagement before the pandemic was I helped the Senior Vice President of operations to devise a DevOps strategy at a large fintech company. And when the pandemic started, we all kind of had to rethink what we were doing. And I thought, you know, this might be a good time. This might be a good time because right now people are in the mindset of rethinking. We had to rethink how we work. So why not rethink all about how we work?

 

And so I put a team together. I reached out to a colleague and we created a list of the capabilities needed by the team. So it wasn’t a random list. We create a list of, you know, we, we knew we needed someone who had deep product design experience, but in an Agile way. And I don’t mean Agile-like framework, I mean Agile in terms of, so he, his experience was from Google and someone who had deep program management experience, but with a very fast moving Agile flavor. We also human resources, but with an Agile flavor, we ended up with someone who was the founder of an Agile people ops framework and so on. So we created this table and system engineering because you know, a lot of software is used in products, real products like Bosch and companies like that. 

 

So we put this team together, ended up having 15 people, and then this effort spanned like six months. It wasn’t a weekend. And we started with a retrospective on what’s working and what’s not working. What do we think? And we created a list of more than 100, of what we called key ideas. If more than one person, if at least two people identify the same issue, it makes the list. And then we reviewed that list and we distilled out from that a set of what we, you know, I regret that we use this term. We call them principles and really they should be called reminders because there are no principles. This is about human behavior.

 

The only principle is it always depends. You know, so, but anyway, we called them principles for better or worse. They’re really like reminders. And, uh, there were 43 of them. We tried to get a smaller list, but we couldn’t, you know, because we realized that if you distilled it down below that, it would lose its meaning. It would become very intangible. And so we, we kept it what it was, what it naturally was. And it was 43 things.

 

And we published that in October of that year as Agile 2. 

 

And then we undertook a crash program to write a book about it, which Wiley published, which ended up being, I wanted it to be 200 pages, ended up being 400 pages. We wrote and went through like 10 revisions and reviews with everybody. 

 

I love the seven people who volunteered to work on the book out of the 15. And the whole process, including nine rounds of revision with Wiley, and go to print. And it was in, it was for sale. And I’d buy the, after four months, the 400-page book, end to end. Could not be done. I said, watch us.

 

Simone Cicero

Mm-hmm. Very Agile.

 

Cliff Berg

So anyway, it was the chronic dysfunction. And we say very clearly, we’re not trying to replace, we’re trying to help pivot and help improve and shore up the Agile movement. Because I write a lot today about the Agile movements and decline because it is, but we were trying to prevent that. And if the movements and decline – what that means is it doesn’t mean Agile doesn’t matter. It absolutely does. It matters more than ever. 

 

But, you know, the ideas are not in decline. It’s just, you know, AI has now taken the place in terms of things that are top of mind for decision makers and fast-moving high-tech organizations. Once, once the movement kind of loses.

 

mind share, it tends not to come back. You know, like you look at Lean Six Sigma and what happened with that, it disappeared almost overnight. But the ideas are still around. In fact, the ideas are embedded in how a lot of people think. So the ideas don’t go away. But you know, the movement might lose, you know, lose its share of the space in the, you know, the talk sphere. But it still matters. Anyway, that’s how Agile 2 came to be.

 

Simone Cicero

Can I ask you, I mean, it’s 43 reminders, but maybe you can give us a little overview of what are the key diseases of Agile that emerged from the retrospecting that you did. I mean, I’m less interested in the key positive things because everybody knows that about Agile, but many times we forget that there are some issues maybe that could be both ingrained in the very idea from the very start, or maybe just things that we acquired as a movement over the years. So what are these major problems that you have identified? At least groups of topics that maybe you can give us an overview so that we can piggyback on those.

 

Cliff Berg

Sure. I mean, where to begin? You know, recently I wrote a post that unexpectedly went viral. You know, it was like a random post I made on a Friday night. I didn’t expect anyone to see it. And it ended up getting like almost 2 million views. And it was basically Agile rest in peace, you know? Yeah, the term Agile movement, you know, not Agile ideas. And, um, we, you know, in response to that, you know, there were 700. Comments or 700 comments that people posted. And so we went through those and tabulated them. We categorized them by what is this person trying to say? And which was not easy. That was a lot of work, but, um, we put them in categories. I think there were 19 categories or something.

 

And the top one that people mentioned, which was exactly what we found in the Agile 2 work, the same exact, it aligned perfectly. And the top one was, it’s all about leadership. And yet that’s the singular big glaring hole in the Agile manifesto. It says nothing about leadership. In fact, it hints, it very subtly kind of diminishes and dismisses the importance of leadership. 

 

You know, self-organizing team, which has a hint of a really good idea, but it’s not expressed right. And trust the team to get the job done, which is a good thing, but it’s more about what it doesn’t say. Yeah, trust the team, but all the time, absolutelY? You know, is that an absolute? 

 

You know, people often forget that when you have a self-organizing team, someone created the team. Someone decided who was going to be on the team. And someone decided if they were up to the task of being self-organizing. You know, being self-organizing and having that go well usually requires, number one, you have a very generative, constructive culture that, because teams are not an island, they depend on the organization.

 

And it also requires that the people in the team generally have a fairly high EQ, you know, that they’re not petty and they’re not, you know, thinking mostly about what they want to do. And, you know, so self-organization, I think of our, our homeowner association, which is self-organizing and it’s a snake pit, you know? So, um, but, you know, you know, the kernel, the kernel good idea is that you want to empower people, is what they should have said, but with judgment. And so, you know, it’s all about leadership. 

 

And when the Agile community, which likes to go to extremes, and I blame XP for that, you know, they think self-organization, oh, it has to be absolutely self-organizing, or that, you know, which means no assigned leader.

 

Well, usually you do need an assigned leader, but what kind? What kind? And, you know, again, the Agile community has these memes within, and one of them is the pointy-haired boss and they equate managers with the pointy-haired boss. Well, there are a lot of really effective Agile, powerful companies that do amazing things that have lots of managers. And a lot of them are really good.

An effective manager is a good leader. just dismissing, oh, you don’t need managers is nonsense. You absolutely do. You know, it’s managers who have authority, who can put things in motion and commit resources and bring the people in and also mentor people and generate the inspiration and be a servant leader, but also be other kinds of leader.There are many kinds of leadership that are needed to make a complex endeavor work. It usually is not one person. It’s kinds of leadership. We actually, in the course that we have, there’s a whole bunch, there’s a list of types of leadership that tend to be really important in complex initiatives. 

 

If you have the right kinds of leadership, it doesn’t matter what framework you have. In fact, you’re better off without any framework. If you have a framework and bad leadership or insufficient leadership, you’ll still fail. The framework, is irrelevant at best and at worst it’s in the way.

 

Shruthi Prakash 

No, I was just going to ask like, how do you sort of propagate this further? Right? Like now that we have, let’s say Agile 2 where, um, let’s say leadership is a point that you mentioned, how do you get that buy in and more so when businesses are becoming more and more complex organizations are either way in sort of this constant flux of balancing hierarchy versus attaining flatness in the organization. 

 

So how do you know, like you said that you, uh, like Agile 2 works better with complex organizations? So just to touch upon that a bit more.

 

Cliff Berg

Sure, yeah, so another kind of meme in the Agile community is, it sounds like I’m dumping on the Agile, which I do a lot because you have to make change. Agility is important, that’s why I dump on it to get people to rethink stuff. And one of the memes is that hierarchy is bad and it can be.

 

It absolutely can be. But the thing is you need structure. And a lot of organizations have too much hierarchy, they have too much structure. But the real issue is how people behave. You know, because, you know, if there’s a culture where you’re allowed and expected to work with other areas and reach across structure, then the structure doesn’t matter. It doesn’t matter. 

 

What’s toxic is if the structure is used as domains of control and domains of where, in order to talk to other people, you have to go up the chain. And where the different parts of the structure compete because of the way funding is allocated or incentives are designed. So, the structure can be very toxic.

 

But it really is rooted in how the behavior operates of the people at the top levels and how that structure is used. Because structure enables you to mobilize people very quickly. You can tell all your people, OK, start working on this. All of a sudden, we need to do this. And so structure can make you very Agile. 

 

That’s why the military uses structure because they can immediately say, oh, all of these people go over there. So structure is not inherently bad. It’s whether or not the structure becomes a prison and a set of barriers is really the issue. But that said, hierarchical structure tends to be a little bit too rigid today and you know, it, what seems to work better today with, you know, you mentioned the optionality, uh, is, you know, to create structure as you need it, instead of having this permanent structure, you know, and that has to do with, you know, the Amazon has a single-threaded team concept and, you know, so, uh, you know, mobilizing people in groups to solve a particular problem, but by doing that, you’re creating a structure. It’s just not a hierarchical structure.

 

Simone Cicero

I love this idea that you said structure can make you very Agile because that’s what it is. You know, we are now, for example, a few months ago, there was a big, you know, conversation around Airbnb’s CEO Brian Chesky coming up and saying, you know, we cut a lot of distributed teams and we centralized a lot of editorial control on things. So there was a bit of a backlash, but at the end of the day, he needed the structure to make the organization work better and deliver better value to his customers.

 

So sometimes I feel like when we speak about self-managing organizations, we tend to speak about means instead of ends. And so what’s the point of being self-managing if we’re not serving our customers well? But on the other side, there is some kind of impact that adopting a self-managing structure generates on the outcomes that the organization creates. 

 

For example, the more self-managing is the organization, the less coherent is the outcome of the organization. That’s a question that you cannot really force out. But my original question was more like, given that you are saying we need structure, even if it’s not a hierarchy that we need, but we need some structure. We need a way, for example, to ensure that the right leadership shows up at the right time. What is the problem with frameworks? For example, if let’s take SAFe, which is the framework that everybody blames most of the times. And I feel sometimes it’s very silly that they blaming of SAFe for the sake of blaming it because it’s kind of provides some affordances to solving some coordination problems or capital allocation with the portfolio stuff and so on. So really, what is the problem with frameworks and how do you make the conversation we had so far more relevant and actionable for companies? Besides saying the old way doesn’t work, what do we do then if not frameworks?

 

Cliff Berg

Yeah, well, you know, Framework, the Agile 2 actually mentions this. Um, and, you know, I, I’m a long time, uh, friend or, I don’t know, colleague of Scott Ambler. 

 

You know, he created a major framework called Disciplined Agile. And, um, but, you know, his viewpoint is these frameworks are a source of ideas. You don’t just implement it. And, you know, frameworks have a lot of great patterns in them. You know, I love SAFe’s, you know, portfolio Kanban idea, but it’s just an idea. It’s just an idea. You shouldn’t implement that.

 

You should take the idea and then think, what should I do? You know, and if, if you give people a framework that like give it to them and say, here, do this, you create what psychologists call functional fixedness where they stop thinking, they stop thinking and they, they don’t, they just go through the motions. It becomes pro forma.

 

And so, you started this out, I think, I forget if it was before we started recording or not, but you mentioned that you use lots of questions when you work with clients. And that’s the right way to start, start with questions. How are we gonna make this happen? How are we gonna make sure that our culture evolves the way we want it to? How are we going to make sure that our stuff actually works and continues to work, but without slowing us down? How are we going to do that and ideate on that? And that’s where you bring in the patterns and the frameworks that you’ve seen for ideas, but then you come up with your own approach. So the worst thing you can do is give someone a framework and say, do this.

 

That basically kills their innovation, kills their thinking, and turns it into just do these tasks and then go home. You want a more generative approach where you challenge people to solve problems, and frameworks are a great source of ideas and patterns, but you should never implement them as stated. That’s my opinion.

 

Simone Cicero

So it’s more like, you know, I want to offer a kind of plug into another part of the conversation, which I believe it’s one of the major shortcomings in Agile. Because when you think about – don’t apply frameworks just for the sake of applying them, which is very resonant to the idea of, again, saying self-managing organization just because we want to be self-managing, we don’t care about the ends or the outcomes, seems a similar conversation for me. 

 

So it’s not about, the point is an organization will never be successful because it applied frameworks. It will be successful judging on the outcomes it generates from the customers. So the big word, let’s say that for me, it’s on the table, it’s accountability. So to what are these teams accountable? So to what are they accountable? 

 

So in some of the things that we have seen as promising in, you know, in terms of new ways of organizing, we are seeing a lot of much bigger role for capital allocation, venture building, and kind of skin in the game. So imagine entrepreneurial skin in the game. 

 

So imagine that teams can have their self-managing capabilities, but normally there is a balance on beating the consequences of the choices that they make in terms of, for example, consuming certain funding that lets them do what they want, or they’re failing to create equity value for them or something like that. What is your feeling in terms of, if we want to mention major avenues of overcoming the traditional problems that we have with Agile. 

 

And, you know, for example, we can start from accountability. You know, you can maybe explore a bit of what you are seeing in terms of these and other revenues that you would suggest.

 

Cliff Berg

Oh boy, where to start? I mean, I was in a meeting with, um, some, uh, I guess they’re VPs, uh, um, about two weeks ago. Uh, in, in the engineering group of a client. And, um, one of them, I was chatting with one of them before the meeting and he, he gave me a list of things that he wants to achieve because we’re working with them to create a developmental program around upskilling their – they have a group manager level and they were helping them upskill those people. 

 

And the top thing he let off with was basically accountability. You know, he was complaining that they don’t feel accountable for commitments, you know, and you know, that’s a complex issue because organizations often overdue commitments. 

 

You know, commitments should be something that’s really important. You know, you make a promise to a customer or something. You know, that’s a commitment. If you make everything a commitment, your people will burn out. You know, I’ve talked a lot with Bjarte Bogsnes who leads the Beyond Budgeting round table. And, you know, a core concept there is to differentiate strongly between commitments and aspirational goals. And then the third thing is how much you allocate to that, your budget. And so aspirational goals are commitments and commitments are very different things. You should be very parsimonious about what you commit. But if you make a commitment, you should take it very seriously. And he complained that as people don’t.

 

You know, I think, you know, this is another meme in the Agile community. And, you know, I think the term self-managing team, I understand the intent, but the term bothers me because the, I know how it’s read and a lot of people in the Agile community hear a term and they make assumptions and they don’t read further. They think now they read the term. They know all about it. And, uh, you know, most teams are not self-managing.

 

And if you look at the most Agile and successful companies, you know, and we look very closely at five, we looked at SpaceX. By the way, I’m not an Elon Musk fan. SpaceX, he created an amazingly innovative culture at SpaceX, but that’s where our interest ends. But, you know, the companies we looked at were, you know, SpaceX, Amazon, Netflix, Spotify, and Google. And they all shared very similar things. They, they are not about self-managing teams. They are about leadership and very specific kinds of leadership behaviors. And you know, those leadership behaviors are very much about giving people problems to solve and then letting them figure out how to solve it. And that’s self-managing to a large degree, but it’s not an absolute. I mentioned Amazon’s single-threaded leadership model, and you could call those self-managing teams, but it’s not like they have no accountability. They absolutely do. There’s always someone in charge of single-threaded leadership team. It’s not like, oh, there’s a bunch of people and they self-organize. They don’t self-organize.

 

And the single threaded team has to, I hate to say report, but that’s how they do it. I wouldn’t do it that way, but that’s how they do it. It works for them. But their self-managing teams have to report to senior managers about how they’re doing. And they have a very specific, Amazon is very kind of scientific about how they do things. 

 

And so they have a very specific process for how that reporting is done. You know, they have their six pager and so on, and their FAQ process. But so, you know, the thing about self-managing is it should have an asterisk because what it really means is you’re empowered. You’re not really self-managing. You know, you have accountability. You’re not just accountable to yourself. You have accountability and there usually is assigned leadership. But…

 

You’re given a problem to solve and you’re given a lot of latitudes, not open-ended. You’re given a lot of latitude and you’re expected to align with other people. You know, you’re not, you’re not allowed to like go your own way and step on other products or go against corporate strategy. You know, you’re expected as you operate to reach out and to collaborate and to figure out how to keep things aligned. 

 

You know, this meme in the Agile community of, oh, just create a bunch of people and then get out of the way. This is frankly nonsense. It’s absolutely, and you know, experienced leaders who hear that, it really diminishes the credibility of what the Agile community has to say, you know, because they know that that’s not how things work, you know, the effect of leaders in these very effective, highly Agile companies are very involved. They’re not getting out of the way.

 

They’re very involved and they ask a lot of questions. They give a lot of agency and autonomy, but they’re not stepping back and trusting. They’re watching.

 

Simone Cicero 

I wanted to highlight a couple of points for our listeners first that it looks like to me that when you say we need this accountability in the system, and it can be either accountability to a leader that has been empowered to lead, and to some extent it should really bear the consequences of his leadership or there should be another type of accountability that maybe in more advanced organizations, it’s an accountability to managing your own resources for which you still need some internal kind of expression of leadership likely into a team, not that it needs to manage its own resources that are finite and need to be replenished either with selling services to the customer or negotiating other budgets.

 

And I think this is interesting to underline to  for our listeners that there needs to be this accountability in teams. It can be either some accountability that is given from a leadership perspective, a design and editorial leadership, like for example, in Airbnb or other type of things, or it needs to be accountability to, how do you collect capital? So for example, in Haier, we see a lot of these contracts where that strategic leadership invests money into teams and they have their own, they need to manage their own P&L. And then, you know, you have accountability to the money that you receive. And finally, I wanted to underline another interesting thing that you said that really struck a chord with me. When you said – you have to be parsimonious on what do you commit to, which I think is really interesting. 

 

And let me think more, about when we speak about organizations that develop a lot of optionality, right? In the past, for example, we encountered Promise Theory from Mark Burgess, where you tend to describe the system as a chain of promises that you make to each other. And developing complex systems really encourages teams to not depend too much on promises that others make to you. And so, you know, if you have a really adaptable system, first of all, you need to avoid depending on too many promises and try not to make too many promises to others, right? And this keeps the system very adaptable and very, you know, keeps the optionality into the system, which I think is really important for organizations that live in the 21st century. So unless you want to add a couple of bits on this, I will leave it to Shruthi.

 

Shruthi Prakash

Okay, so I’ll go. So, no, I mean, just taking off on what Simone said as well, right. There were a few strings that stood out. So one being, let’s say leadership being a problem factor in Agile 1.0. And then now let’s say the development of the next step. And I was also remembering the previous podcast that we had with open system theory practitioners and how they mentioned that essentially, you know, when a company puts out an ad, they are looking for a person who is going to fit into a certain role, which is, you know, within a fixed mold that has already been described for them versus hiring a person to solve a problem. So with what you have said about the role that leadership plays as well, right? So how do you think that the leaders can give people problems to solve rather than tasks to complete essentially, and therefore sort of dive much deeper into a more holistic transformation and a mindset sort of shift across the organization?

 

Cliff Berg

Yeah. Well, so I heard three things between the two of you. And so I’ll take them in reverse order, you know, about, uh, you know, leaders need to, uh, you know, and this is behavioral, you know, almost all of this is behavioral and that’s why frameworks don’t matter. It’s all about, you know, how people in positions of influence, uh, or authority respond in situations. And, you know, that includes thinking in terms of defining job roles or looking for someone to solve a problem. And when you bring in someone new, do you just look, do they check the boxes on what we’re currently doing or do I think they’re able to solve hard problems?

 

You know, and then using, you know, the people you have, giving them problems to solve, and then paying attention and participating so that, you know, they don’t, you know, fall off a cliff. But, you know, I think that’s mostly behavioral at all, you know, at all levels of the organization. There’s, you know, HR behavior, there’s leadership behavior, you know, that impacts that. 

 

And pre-defining roles in terms of, you know, it’s very, you know, roles are very situational, you know, and people tend to make their own role. So, you know, if you over-define a role, you’re really kind of creating an impossible situation. You won’t find someone who really fits the role. That doesn’t mean you shouldn’t define roles.

 

Again, it’s not an absolute, let’s not be extreme about this stuff. The other things I heard were about promises and also like the idea of people having their own incentives, like a P&L, or their own kind of like mini business and accountability. And about promises, I think that makes me think of, in the course that we developed, we teach three paradigms in terms of how your relationship to another group. And they might be a third party that like, you bump up against here and there, but you’re not really interacting with them intentionally. It’s like, imagine you’re building a building, but then there’s someone else building another building and you share a street and they need to close the street one afternoon, but you have cement trucks coming in. So, you know, they’re not involved in your project, but you need to coordinate with them, or then you need to give, be transparent with them about what you plan to be doing, because you affect them. And then another kind of relationship is a contract relationship where they’re a supplier, you know? And, you know, that often is very effective when you’re buying commodity things. 

 

Like, I need to find someone to deliver salt, you know, and you don’t care who it is because you don’t care one kind of salt or another, or maybe you do, maybe, depends if you’re eating it or putting it on your road, I guess. But you want a commodity and it’s all the same, you just want the cheapest one and you find the best supplier who’s reliable, low cost and so on. And then a third type is partnership. And you know, there’s usually a contract with a partner, but it needs to be very flexible. If you make the promise about what they’re going to do versus about the relationship, you can make it overly rigid. Because in the development of a product, it evolves. and the interface tends to evolve. So interfaces are very important for agility, actually. It’s like an API. But it needs to be able to evolve in a coordinated way. 

 

So you need to be thinking about how are we gonna update, how are we gonna, you know, how are we gonna collaborate about changing the promise, like easily, not with a lot of overhead. That needs to be part of the relationship, how we work together to keep changing these interfaces, you know, and if you’re a partner, you both have skin in the game.

 

You know, in our study of SpaceX, I ended up meeting someone named Dan Rasky, who founded the commercial NASA’s, what’s it called, the Space Portal. It’s basically their office that was set up. He co-founded that office as a bridge for space startups like SpaceX. And now all the so many others that have sprouted up. And the idea was to make, instead of making NASA looking for suppliers, which is what they used to do, and they still do it, you know, they basically, you know, create a requirements list and they ask for bids, you know, on this and that they getting suppliers. The Space Portal was about creating partnerships and with the partnership everyone has skin in the game. You know, the, vendor invests their own money to build something. And they only get paid if it works. They only get paid if like, you know, they meet the intent. So, but then they own, they own the product. They own to deliver it as like you paid for it. It’s it’s yours.

 

They own the intellectual property, the vendor owns it. So there’s an incentive they now can productize what NASA, you know, help, you know, got them to develop. You know, and so that partnership is very important. And, you know, when, you know, with regard to groups within a company that have like their own P&L, they’re not autonomous. They’re partly autonomous.

 

That’s my problem with the word, you know, self-managing, but also autonomous and self-worth. You know, these are not absolutes. You know, they’re, they’re autonomous in the sense that they have a lot of latitude and agency, but they’re not entirely autonomous. They have to align with corporate strategy. They, you know, they, they have, you know, uh, they have to, uh, ask for resources, they have to fit into a larger picture. So the autonomy is a matter of degree and someone’s watching and someone’s deciding what they can have autonomy about from week to week. It’s not unlimited. It’s being managed. There are levels of autonomy and degrees of freedom are being managed by someone.

 

Simone Cicero

Yeah, you were, I think you said again, a couple of important things that are worth aligning, when you said with the example of the NASA portal, and when you spoke about the importance to be elastic in changing promises, right? A lot of what we are seeing in terms of organizational innovation for the most performing companies we are seeing these days is coming in from two spaces, let’s say. 

 

One space is platforms and ecosystems. So a lot of companies that have their third parties developer portals, for example, we had in the podcast, we had Scott Brinker speaking about HubSpot strategy and how HubSpot is leveraging on so many third parties and they co-develop shared experiences by integrating different applications at different levels.

 

And this is really the epitome of how you partner with larger ecosystems that can distribute your products, and integrate your products. So lots of the thriving organizations of the 21st century have this interface-based partnership making, continuous partnership making, which is one big direction of innovation we are seeing in terms of when we think about an organizational product and so on. And another one that we are lucky at Boundaries Boundaryless to be at the very center of is this approach based on distributing P&L, but not only, but also the capability to contracting and to reach the market. So in the practice that we praise, let’s say, it’s not just distributing P&L for the sake of controlling TCO of things, but it’s rather, you know, you kind of become as a P&L owner, you become free to negotiate and contract and buy and sell. 

 

And a lot of these interactions between nodes happens according to what you said, bits, opening requests and then receiving bits and choosing what you want to partner with, which for me, it’s a lot, how can I say, but it integrates a lot the perspective that we discussed before that, of course, you can have a promise from someone. Right? But, the fact that somebody is promising you to do something in a contract, it doesn’t mean that we’re going to actually do that. They may fail in doing it. 

 

And therefore, you need to develop optionality, different options, and different avenues to the resources you need, and so on. For me, it’s really, to some extent, it’s really acknowledging that we are living in complexity. Therefore, if we look at the industrial age and we look at the hierarchies that we have used to manage organizations in the industrial age, bureaucratically, those really don’t need any leadership. There is a very limited amount of leadership that you need. Instead, for organizations that have to live in complexity that people are used to thinking of, this needs to be self-managing, so we don’t need leaders, it’s actually the opposite. You need many more leaders, many more leaders in a distributed and complex organization than you need in a hierarchical industrial organization. What do you think?

 

Cliff Berg

Yeah, it depends what your goal is. You know, it depends, you know, whoever owns the ecosystem, what’s their goal? You know, we, one of our clients is a, medical research foundation that, uh, that was launched about a year or two, almost two years ago. Um, and we helped them develop their core strategies for how to move quickly and be nimble. Um, and, uh,

 

You know, They have an external facing scientific advisory committee, and they also have an internal, what they had been calling a council. But the internal one is basically principal investigators from across that university. 

 

And they, You know, One approach, which is very kind of hands off, is just ask the principal investigator, you know, how can we help you? And how can we help you with the grant proposals you’re writing and bring people together and treat it as an ecosystem? Another approach is to be a mission-driven organization, which they are, and to use that counsel to ideate on what are some big problems in medical research that we think we’re in a good position to solve. And that becomes much more proactive. So instead of then treating it as an ecosystem, you try to align people and you try to create opportunities. So you try to get funding and then so that you get big blocks of funding, so they don’t have to all go find their own grants. And you give them the funding to do things that are all gonna push this thread forward to solve a big problem. 

 

And what they actually are doing is a combination of the two. Again, it’s not one or the other, doing a combination, but they are very mission-driven. And because they’re mission-driven, they don’t want it to be just an ecosystem. They want it to be., they want there to be a lot of alignment in terms of what all the different research teams are doing.

 

Simone Cicero 

Mm-hmm. I mean, that’s very resonating with the idea that the more vertically integrated is the purpose and the mission, the more you have to exert some type of control in the organizational structure and be a bit more top-down. While if you really embrace a more distributed optionality-based approach, you also have to accept that things that can emerge are not necessarily aligned 100% with your mission or purpose. So I think you made a great point. Yeah.

 

Cliff Berg 

That’s very key. If I can pivot on what you just said, because extremes, in my experience, extremes don’t usually work well, except in very extreme situations. And the challenge for the director of this institute is finding the right balance between those two, because what you just said is actually very key. You can’t anticipate what people are gonna discover and what ideas they’re gonna have and so, you know, if you lock things down, we’re all going to go in this direction. you basically shut down everybody’s, you basically foreclose on the, you know, that’s others might come up with ideas that you haven’t thought of, you know, discoveries that might completely change the game, so you have to have a mix and finding that right mix is the challenge.

 

Because the wrong answer, it’s all one or all the other. There’s a right mix most of the time. And finding that mix is the judgment call that is the main challenge.

 

Shruthi Prakash

Yeah. Now I was thinking about a lot of these points discussed, right? For me, it’s always been about, let’s say, even with my previous rules, when we do take up transformation practices, it sort of dies out post, let’s say one implementation quite often, I’m not saying all the time, but quite often. So how do you, let’s say, ensure that these practices have sustainability in them. How do you ensure it’s sticky as a practice? And it basically runs its course rather than being like a one-time sort of implementation activity.

 

Cliff Berg 

Yeah. So, you know, a lot of people in leadership roles in the IT field during, you know, during, you know, the period of Y2K, around that time, a lot of them had Y2K programs that worked and they learned that approach. 

 

And the whole area of data management and getting control of your data was very prominent during the early 2000s. And a lot of managers learned from that experience. And they basically learned that what worked was what like Accenture and those companies do. They come in and help you create a big program plan and then you roll that out and then you’re done and they learned that paradigm and that paradigm does not work for this, because this is very behavioral. 

 

Actually, there are some parallels with data management because there’s behavior there too, but not to the same degree. You know, agility is almost entirely behavioral and the behaviors that really matter are not the individual contributors, it’s the leaders, the people in roles that have any kind of authority. 

 

And so really it’s mostly about behavioral change of people in leadership roles. And that is the single thing to focus on. And few transformations focus on that. They’re usually about creating new processes and stuff. You know, the processes, the frameworks don’t matter because people will create the processes they need. 

 

If the leaders are good. They’ll figure out what processes that process, you need process, but you don’t have to give them a process. You don’t have to have some group defined, this is how everyone’s gonna do things. They will figure out what processes they need. You know, that the processes come second, not first. You need to improve the leadership skill and knowledge. They need knowledge too. They need knowledge of lean thinking and those kinds of things. But, you know, because those are mental toolkits. 

 

But first and foremost, they need behavioral change. You need to improve their EQ (Emotional Intelligence Quotient). You need to improve their understanding. And most people in leadership roles don’t have management, don’t have leadership training. They don’t, and they need to. And it’s more than a two-hour seminar. There’s a lot to learn. 

 

You know, we’ve identified, that the applicable domains are leadership theory, behavioral psychology, cognitive science, operations research, and organizational culture theory. You know, and people need to understand some of those, the key ideas in those fields in order to have the cognitive framework for how to think about what they’re doing when they lead.

 

Simone Cicero

Sounds like a lot overlapped with the idea of an entrepreneur, am I right?

 

Cliff Berg 

Very much so, very much so. Entrepreneurial thinking is very important today among leaders in organizations. One of the common behaviors that we found in these highly Agile companies was the expectation that people will try things before being sure. That instead of planning it all out and dotting every aspect, and until you’re completely sure this is gonna work, and then it probably won’t, because it’s too late and people are sick of it and the details are not right, you know, so you over plan. And then you miss the window of opportunity, you know, and we found in these highly Agile companies that the leaders are very proactive about insisting that people try things before being sure. They’re proactive about that. 

 

Amazon has a rule of thumb. 70 percent. If you have 70 percent of the information you need to make a decision, you need to make the decision. Don’t wait to have more information. 70 percent’s enough. Make the decision in a safe way and contained way and see what happens. SpaceX has a similar rule. If you’re 51 percent sure it will work, you need to try it. Don’t wait. Waiting is a lean waste. Don’t ever wait. 

 

If you’re 51% sure that’s good enough, click print on the 3D printer to make the part, put it in the rocket engine, put it on the test stand and see what happens and measure the heck out of it. So the leaders are very proactive about letting people know that the leaders expect that you won’t wait, that you won’t hesitate. They generate,  Leaders generate the culture through articulating what they expect and then how they react to things.

 

Simone Cicero 

I mean, there’s a lot of risk tolerance, a lot of learning how to negotiate, of course, convincing people to follow your advice or in general, your leadership. That’s, again, really entrepreneurial. It makes me think of an article. I don’t remember the name, but it’s really also overlapped with a lot of the work we do with the 3EO, an article from the HBR from many years ago, a couple of years ago where they identify, and I will put it into the notes, but essentially they identify three types of leadership for adaptive organizations. And it was some kind of architectural leadership that is needed to set the rules of the organization. Then there was an enabling leadership, people that are more into supporting the others into these kind of hard journeys that you are highlighting as the future. And then of course there was entrepreneurial leadership. So the idea to bring things forward and take risk and understand customers’ needs and listen and research and operational elements. 

 

So I think this was a good framework for me and it resonates a lot with maybe we didn’t speak about much about the architectural side and the enabling side in the conversation but I think we kind of gave them for granted that they were there and in the system now you have the entrepreneurial leader that extends and develops the organization in certain different directions. So that’s a good post, a good article that also listeners can check in.

 

Cliff Berg

Well, you know, the whole architecture side, you know, I’m trying to look, I can’t forget his name, but Wolfgang something. I mean, I’ve talked to him many times. I don’t know why I’m black.

 

Simone Cicero

Edgy, you mean the intersection group people.

 

Cliff Berg 

Yeah, exactly. So he’s very big on that. And he’s right, you know, because, you know, and that’s, that’s kind of where Agile lean intersect in that, depending on how you define lean, because what lean meant 30 years ago is like, today lean is everything. It’s like all these paradigms over time they start accumulating everything that else, you know, so now Agile is everything. And lean is everything.

 

So the original lean, which was mainly about flow, except now flow is everything. But the original lean was more about sequential processes. But lean was a set of ideas on how to make sequential processes very flexible and very self-correcting. And that enables agility, but it doesn’t give you agility because if you have those flexible infrastructure, flexible system, then the way you behave can use that to be very nimble. 

 

But if you have people who behave like just thinking incrementally, because to be Agile, you need to realize that you need to change the flow. You need to change the flow, create a new flow. So if you’re not, if your behavior is just think incrementally, you’ll just think how to tweak the flow. You won’t think about, that flow is not right. We need a new flow.

 

But thinking about the mechanics and the flow and like edgy, the architecture. And I know he thinks of architecture in terms of people too. But that’s really important. And it takes many kinds of leadership. Like Peter Drucker used to say you need inside person, outside person, and a person of action.

 

You know, the inside person is often like the CTO with someone who has great technical probably abilities or someone who all the people inside relate to and respect, you know, they kind of trust that person and, um, uh, you know, that person often is the one who set up the flow, the original one now is it Agile? I don’t know, but they did set up the original flow and the outside person is the charismatic one.

 

You know, it’s like if you look at Matt Damon and Ben Affleck, you know, they both wrote Good Will Hunting, but I have a feeling that Matt Damon really kind of was the deep thinker and Ben Affleck was kind of like wrote the exciting parts or something, you know, and everybody wants to socialize with Ben Affleck, but Matt Damon like is a really nuanced deep actor who can act any part. It’s amazing.

 

He’s believable in comedies, he’s believable in these dark dramas, you know, and so there’s a real depth to him and he’s kind of like the inside person. Ben Affleck’s the outside person, you know, the charismatic CEO, you know, but then the person of action is like Andy Grove at Intel. It’s like get shit done. Time is ticking and time matters. What’s happening? Where are we? You know, not be mean about it, although a lot of them are mean about it. And I don’t think that’s great, but Andy Grove wasn’t mean about it. He was actually a very nice guy. But I mean, I didn’t know him, but you know, actually a colleague of mine did know him. But the reports are that I’ve seen as that he was a nice guy, but he invented OKRs.

 

You know, he was very much thinking about how to keep things moving, how to keep things aligned. And, you know, you need that too. Um, because in business time matters, you cannot be hesitating. Um, you need to be watching the clock. 

 

Shruthi Prakash

I mean, I’m yeah, I mean, I’m extremely curious to just see how all of this sort of integrates more and more as we go. Right. I mean, even within our call today, we’ve spoken about so many different practices and how they have sort of combined together. So that’s nice to hear. Just wanted to check in with you for our breadcrumbs, as we call it at the closing of our podcast. So any movies, podcasts, videos, books that you might recommend for our listeners that has influenced you and they can help gain from.

 

Cliff Berg 

Well, I didn’t know ahead of time that you were gonna ask for that. And so I would have put a list together, but atop of mine, it’s pretty easy. Two books I always recommend people are, one is Accelerate by Nicole Forsgren. And I like that book because it documents some very thorough research that she did about the behavior of teams and in high-tech companies. And she found that it wasn’t servant leadership, it was transformational leadership that made teams effective. 

 

And, you know, that’s not to like dismiss servant leadership, because servant leadership is kind of an element of transformational leadership. It’s like, it’s a set of behaviors, you know, and those are important behaviors, but that’s not enough. You know, leading teams more than that.

 

And she, her research is very kind of factual and concrete. Although I would caveat, you know, she co-authored it with Gene Kim and Jez Humble and lately Jez Humble has decided to promote the idea of what in programming is now called trunk-based development, as if that’s the only way to do things. And it’s not.

 

It’s not the only way or the best way. It’s a way and it’s a good way, but it depends. There are lots of situations where it’s not the best way. You know, so he’s become kind of very pedantic and about that issue, which is mentioned in the book. But I highly recommend the book. It’s fantastic book. She actually, by the way, has a copy of the Agile 2 book. I’ve talked to her and she liked our book. 

 

But another is David Marquet, who wrote Turn the Ship Around. And he’s a former submarine captain. And he writes about how he was generative in converting his crew from being people who just take orders to people who think for themselves. He gave them problems to solve.

 

And he taught them to think out loud instead of being tight-lipped and, you know, afraid to say what they really think. So he was a coach and a mentor also. He also remained a decision maker. He didn’t just stand back. He made decisions. You know, leaders don’t abdicate. They’re decisive, but they know when to let other people decide. And they prefer to do that.

 

But they also know that time matters and it’s their job to make sure that things keep working. So he also has a copy of the Agile II book and I have a picture of him holding it. But his book is fantastic. It’s a great read. I highly recommend it. It’s called Turn the Ship Around.

 

Simone Cicero 

Thank you so much. I’m sorry, Shruthi.

 

Shruthi Prakash 

No, I was just going to say we’ll mention all of these, but in case you want to share more reads, because you might have a few more, you can always share it with us and we’ll put it in the podcast notes.

 

Simone Cicero 

Yes. Thank you so much, Cliff. I mean, it was a long conversation. And I think this is really a thesis and topic that is dear to our really conscious listeners. Because this is something that we discuss very often, right? How do we evolve from old models that are really, how can I say in English? That really need to be reinvented because the market now, the society now, really demands different approaches, demands a different level of leadership and adaptability. So thank you so much for your time. I hope you also had a good time.

 

Cliff Berg 

Thank you, it was a pleasure. And I’d just like to close with one thought, It’s not what you do, it’s how you do it.

 

Simone Cicero

Yep, yes, yes. Again, we spoke about means and hence a lot of times, but it’s also a good way to kind of create a counterbalance, you know, because sometimes also how you do things drives outcomes. So thank you so much for our listeners. Check out on our website www.boundaries.io/resources/podcast, you will find the episode with transcript, the video and all the notes.

 

And until we speak again, remember to think Boundaryless.