Simone Cicero 

Hello everybody and welcome back to the Boundaryless Conversations Podcast. On this podcast, we explore the future of business models, organizations, markets, and society in our rapidly changing world. Today, I’m flying solo, but we have a great guest with us today, Alexey Krivitsky. Hello, Alex.

 

Alexey Krivitsky

Hi, Simone, thanks for having me here.

 

Simone Cicero

Good to see you and thank you for joining us. Alexey is, I would say, he defines himself as an end-to-end consultant, like most many of us, I would say, that can range from the details of technological implementation and development up to sitting with the board and deciding about strategy and organizational development. He is a co-creator of the org topologies methodology which was related a few years ago and now has, culminated into the release of an interesting book called 10x organizations, which is also a co-author. 

 

So thank you so much again for joining us. It’s a pleasure to have you here. Maybe we can start by just a little bit of framing. So as I said in the opening conversation we had, I feel like sometimes most of us working on complex organizational systems are somehow converging into very similar ideas.

 

But it’s probably a good moment for you to give our audience an overview of what our topologies is and maybe also how you got there because you also have a very extensive past in Agile and other methodologies. So I think it’s good for you to maybe give an introduction to our listeners, especially of the reasons why you felt at some point you had to create this framework.

 

Alexey Krivitsky

Yeah, thank you for this question. We don’t call it a framework between us because you know the word framework, especially in the agile community has already some kind of a shadow. So I think an approach, a method is just a more generic definitions. why we created, so I come from the field of organizational coaching consulting. And of course, for the last 10, 15 years, we all have been pretty busy with the so-called agile transformations. 

 

So me and my partner, Roland Flemm, with whom we created Org Topologies. So there are many reasons, right? One reason that I would like to share here is that we have noticed working with our clients, with the leadership teams, is that yes, they’re doing some implementation. They roll out some framework. It can be SAFE. It can be something else. can be Team Topologies, unfixed, Spotify model. And they are doing that. And then when you ask them a very simple question, like, guys, like, what are you trying to actually improve? Or what do see your company evolving in the next couple of years? Like, what are the new capabilities you are building in?

 

They have, not everybody, but in most cases, in some cases, they have hard times answering this simple question. we figured that a lot of companies are in motion doing this change, doing this transformation, and sometimes even re-transformation after transformation. We can talk about that too in the podcast. And we figured people are lacking some very basic tool to reason about the current state and about the future state and then have a better clarity on the direction of change. 

 

So, Simone, we created this two-by-two map, how much of skills being expanded and how much of work being expanded. And essentially, we spend five years now in this, I can say, research project, like a hobby, a research project where we try to understand for companies where they are on the map. And we figure out almost every company, every division, every team, every individual can be mapped on this simple two by two or topologies map. And once you map something, then you can have a discussion where do you want to evolve this organizational unit. So this is just one way to explain to our audience like why octopologies? And of course there were some other reasons.

 

Simone Cicero

Do I understand well that part of the direction of work that you guys have been looking into is the convergence between the how the organization is managed and set and the what. So the product side, the value proposition side of the organization, how this value proposition can be distributed across the teams. sometimes, my frustration with some of these agile frameworks that speak about flow and let’s say agility or whatever, I’m sometimes frustrated because it seems like there’s no talking about product and customer. 

 

Most of the talk is about the actual work and obsessing about making it fluid. But then,

 

it’s unclear how the work will actually end. Would it end in some kind of product that somebody uses or who pays for that, who budgets for it? So are these things also part of the framework, the approach that you guys have developed?

 

Alexey Krivitsky

Yeah, one problem that you’ve just clearly mentioned, Simone, is that people bring these, I would say, buzzwords, like agile and agility and other things, and they use them. Like these things are defined. But I mean, every company would have a very different understanding what agile is, right? In quotes.

 

And even people within one company, even within the same agile transformation, might also have different definitions. So we are not using any of this terminology in the org topologies method. We don’t want people to assume it is given or it is clear. We want them to actually, as you said, understand what they were like.

 

What’s the relationship between what customer wants and why the company was actually created and the internals of an organization. This map essentially, so you start the Org Topologies method not by looking inside your organization. That’s one of the further steps. The first step is to ask yourself, which is a very simple and a hard question at the same time. Like, why are we doing this? Why do we exist as an organization? And people need to remind themselves who the customers of this organization and what are the key problems they are solving for them. Only when this is clear, then you can open up the organization and then try to map your org units in relationship to that customer or customer problem. And you’ve mentioned like team topologies and other methods that focus too much on flow. I think flow is good, is not a bad concept in general. But a lot of these ideas, no matter how well they are described, will be applied in an organization in a way that this organization thinks.

 

And many IT organizations I have worked with, they have a very internal view on the situation. So I was witnessing several team topologies adoptions where what leaders would do instead of talking about the customers and the strategy and the needs of the organization, what they would do, they would open up an architectural map of different components they have in the software product. And they would attach teams to those components to improve flow on the working on those parts or components. And this is a very internalized, a very internal view. 

 

And I’m sure you can improve some things doing it this way. But the risk is you might actually just rearrange some decks on a Titanic, as we say. You might just be doing some local optimisation, and it might not have any positive influence or implication on real things that matter.

 

Simone Cicero

So if I understand well, in your method, let’s say, there are certain end states that are desirable, I would say, or at least this is my impression. Would you maybe chime in and clarify that? Broadly, if I can maybe introduce it to our listeners, your framework has, let’s say, two axes, as you said. One is the scope of the work. scope of the work moving from single task, so largely functionally distributed work or, you know, would say fragmented pieces of work into, you know, customer domain focus. So essentially, as I understand it is, you are in charge of broad customer domain problems, so maybe a product development, something like that. And on the other side, there is an access, which is about, you know, the complexity of capabilities that a unit runs on its own. 

 

So it’s, I don’t know, purely functional thing or a purely single-scale thing or more like a systemic thing that can create full autonomy and customer value. Is there an end state for all organizations or maybe depending on what type of organization you are in your experience, you want to position somewhere in the board?

 

Alexey Krivitsky 

Yeah, great question. Just to simplify your explanation of the map. So the vertical axis is essentially in very simple terms. Are you working on the outputs or are you contributing to the outcomes? And the difference between outputs and outcomes is that outputting more outputs does not necessarily contribute to a greater good. So if you have a team or an org unit or a person who is just doing the same thing over and over again, some outputs, maybe they are chopping onions in a restaurant. Like, you know, more chopped onions do not necessarily add any value. And outcomes is of course something that customers understand, something that customer value. And if you’re working on the outcomes, then you actually see where the value is. And value is usually changing if you are in the product development. So if you’re working on the outcomes higher on the vertical axis, then you have more freedom to decide what I’m working on today and what I’m working on tomorrow. And the horizontal axis, in very simple terms, is going from being incomplete, just doing some function, as you say, and being dependent on the others or on the right side being complete, being independent, being autonomous. And of course, this intersection gives you interesting combination. 

 

So, Simone, you asked, so this was a bit of a debrief of the method. So about the final state. No, there’s no final state and there’s no better or worse place on the map.

 

And I think, this is like a critical for our readers to audience to understand. You know, org design, and this is the field of org design, is very contextual. There’s no right or wrong in organizations in general in abstract terms. But there is something that is fit for purpose or unfit.

 

OK, so like we’ve just discussed flow, is flow good or bad? Well, it depends what you want to improve on. It depends what you’re optimizing for. It depends on which kind of environment you are working with. So we have been developing this method for a very broad audience. Org design is very deep, and you might even say boring domain, not many managers would like to dive in. So our mission of Org Topologies and the 10x org book is to make that field of org design accessible, interesting, modern for the audience. And so we had to simplify a lot of things. one simplification, of course, is the map.

 

And the other simplification is the three topologies. So now I’m coming to answer your question about different places on the map. So we figured there are these three common topologies that your organization or your unit department likely has.

 

So the three topologies, we have identified resource topology, delivery topology, and adaptive topology. Like as this idealized canonical stereotypical management systems and org designs that organizations create around the people.

 

And none of them is good or bad in itself. But if you are, for instance, working in a very dynamic environment, and most of my clients are in product R &D, so product research and development software, in this environment, every feature you build is unique and new. You never build the same stuff twice. You can say,

 

The customer demands are changing a lot. So it’s a very highly variable environment, you can say. And if you are working in this environment, just utilizing skills of individuals just because they have them, like in the resource topology, or just focusing on flow and speed of teams in a delivery topology makes very little sense. 

 

So these topologies are very much contextual. Let me maybe give you some more simpler examples. So like if you are an assembly line kind of a company, right? So which means your product is the same, it is standard, there’s a very little variation, and there’s enough demand to produce this product for many years to come.

 

And the process is repeatable. The assembly line, the typical Ford factory, can say, or a Taylorism, is very much what I would advise to implement as an org designer. On the other hand, if the stuff is more dynamic, if every item coming out of your assembly line requires different skills, different ideas, different level of creativity is not repeatable, then this assembly line concept or resource topology is not fit for purpose. So these three places you can be roughly speaking on the map and depending on what you want, they can be fit or unfit for purpose.

 

Yeah, and the goal of this method is twofold. First, help you identify your existing topology. Because I know if you agree with me on this, Simone, or not, I believe that every organization is already kind of optimizing for something, whether they want it or not. Every structure creates some culture, behavior, amplifies beliefs.

 

So the first part of the method is understand what you have. And it typically be one of these topologies or a combination of those. And the second part is ask yourself a question like, it really driving our business strategy? And if not, then improve and maybe find other places on the map you would like to evolve towards. 

 

Simone Cicero 

When you say, so what is the unit of organizing that is normally that you normally map? Is it a team or a unit actually? So some form of grouping of teams or, you know, well-defined capabilities. So what is the thing that you normally put on the map? Is it a team or a unit or what?

 

Alexey Krivitsky

Yeah, so we have been coming from this field of like agile coaching and stuff where usually agile coaches, masters would define something as a team and work a lot to improve the wellbeing of the teams. And we wanted our method to be compatible with that thinking. So this method is optimized in the first place to map some kind of coherent units of work, let’s say team, or broadly speaking, group of people who… So like when you put a dot on a map somewhere, on the map, that dot of a map will represent either one individual if that person works solo, right? 

 

Or likely it will represent a group of people who work together on something common, which will typically be defined as a team. But then you can, of course, group teams together and look at the department. You can map at the higher level, like dependencies between the departments, or you can open up a team and look at the individuals. Even like you could put AI agents there and stuff. What you are mapping is very much up to you.

 

But when we teach these concepts in our classes and courses, we typically help people find these coherent smaller groups of people, like agile teams, scrum teams, and start with them. Because this is very typical these days, how the companies are thinking of their structure and themselves. 

 

And of course, actually, in one year from now, the tendency is to have smaller teams, like in software engineering, smaller teams and just maybe solo developers pairing with AI agents. And that would be a unit of a team. And then you can of course map them too.

 

Simone Cicero

I was thinking too, something that clicks in my mind as you speak. Again, I’m looking at this from the perspective of I’m seeing a lot of convergence here. Basically, everybody’s talking about the same thing with their own story. You’re coming from your story, so you brought to your own approach. We come from another story, we brought another approach. But I’m really keen to think that we actually start to need the common language for us to understand each other. But that’s another story. 

How am I mapping your approach to what we do, for example? It’s interesting to see that typically when I work with organizations, we have more of an approach that tends to focus on the unit level. So typically when I speak about a node in an organization, I’m not talking necessarily about one team. I’m talking about one capability.

 

So something that has a clear value proposition, provides a certain catalog of services, for example, or capabilities. And it can have a P and L. So you can actually have a more or less a I would say a boundary where you can have agreements, contracts. You can exchange value for value. So if you look at these, and I typically look at these nodes from the perspective of evolution. And we started from working with the Haier approach a few years ago and higher has roughly three type of units in the topology in Rendanheyi, which is a micro enterprise and they separate the user and node micro-enterprise. 

 

So the user micro-enterprise is the micro-enterprise in touch with the customer, let’s say, while the node is the one that is in touch with the other units to support with common services like enabling elements. And then there is the shared service, which is something more like an overhead provider, like HR or something like that. 

 

And then if you look at the Wardley mapping, example, Simon Wardley framework, you have a similar approach. have somehow the idea that you have an innovate, leverage, and componentize flow. So there are these three things. And also, if you look at domain-driven design, there are three types of bounded context. There is a core bounded context, which is similar to what we would call a user-me. 

 

There is a supporting bounded context, which is similar to what I would call a node, my enterprise. And there are generic bounded context, which is something that I would call a shared services or something like that. 

 

And if I look at your topologies, I can think that maybe a resource topologies are more useful for the generic domains. So the domains which are very predictable and commoditized services, let’s say while the delivery domain is more keen to maybe the supporting elements, the platforms, the internal capabilities. And the adaptive domain, sorry, the adaptive topology is more, let’s say, it’s better for the user, it’s the core domains that are in touch with the customer, they need to adapt. 

And it’s interesting that you see that if you look at your delivering, your topologies, both the resource and delivery topology have some kind of directing unit. Basically, they need to depend on someone or something giving them direction, while the adaptive topology is more self-aware and more autonomous in setting direction, which is the same thing we experience because typically in organizations that run the three topologies together, the three units in the topologies, you have some units which are more dependent on the board decisions, like you know, they typically depend on objectives, like for example, if you have HR, you typically give HR objectives in terms of SLAs, in terms of performance, while other nodes, which are the ones in touch with the customer, typically entertain a relationship with the board, which is more that of an investor-investee. 

So I make my plans and then the board will invest on me to support my strategic development? Which is, story short, coming back to you, do you see this resonance and do you see that organizations have all the topologies often, especially big organizations, have all these topologies together in their systems?

 

Alexey Krivitsky 

Yeah, thanks Simone for all this for me personally and I think it was helpful for our audience to connect the dots and see these different methods.

 

What to say? I think you’re right in saying that you can map these different levels of variability or complexity or evolution to different topologies and you can see them alike. I’m not a scientist, I’m a practitioner. 

 

And from the practitioner point of view, and I work with organizations that have like excess complexity. Yes, you can say they can have all kinds of topologies. And of course it might make sense to have a resource topology for some kind of a function, maybe HR or ops. And it might be okay to have a platform team being represented in a delivery topology. And then you can have some adaptive teams on top that will sound very logical to managers and the teams.

 

And this is how a company typically will be structured. But when I’m called in as a consultant, I’m not called in to do some theory discussion. I’m actually there to solve real problems. And the typical problems that I know exist and I try to solve them for many years. And that’s why I have to build Org Topology is that, for instance, if you believed that something can be commoditized, like it is right on the Wardley map, some kind of a platform, and you need some kind of a good flow of that platform. And it sounds like it’s a boundary of its own, it’s a domain of its own. You would, as a manager, typically create some kind of a unit, org unit, to own that platform. 

 

So that’s where the domain-driven design and org design become kind of intertwined and maybe for bad reasons, because yes, I understand modularization of software. I understand the concept of services, reusability, and something can be a platform. No problem about that. But the interesting dynamics happens when you attach a team to own that platform.

 

And only that team, for instance, is allowed to modify and evolve that platform. And other teams will be just consuming, so to say, their interface. It will sound very logical in all these methods which you listed. And you can have a nice even org topologies mapping on that. But as a practitioner, I know this can create a lot of interesting friction and dynamics.

 

For instance, Simone, I think some of our audience will recognize a problem where a platform starts to live its own life. If it’s software product and you figure out, this part needs to be platformized, it should be a platform that typically means there is a product owner, product manager owning that platform.

 

That person, of course, has some kind of a budget and asked for a vision. So she would come up with a roadmap, some kind of a predictable delivery will be asked of her. Then she would have given engineers teams and those engineers, of course, will be hired to, you know, be able to work with that specific technology, you know, and that becomes a world of its own.

 

And I worked in large and I worked with large German organizations where they were these platforms and essentially every team becomes this kind of a isolated kingdom. Exactly. You see the dynamics. So yes, you can justify this with great theory, domain driven design, Wardley mapping, whatever. But there will be some very interesting problems.

 

And the problem is that yes, they’re independent kingdoms. They will be optimizing locally, not globally. And they will try to avoid, you know, changing stuff when they have their roadmap. So I was, for example, working at a large German company, XING, social, so-called, yeah, German social network, which is kind of dying. 

 

But I worked there like 10 years ago when it was super fantastic place to work. But there you would have a team there each layer of the architecture, like very classical method. because everybody would have their own small view on the problem, right? You will have this feudalism, many kingdoms kind of wanting to like each other, but also having a very conflict priorities and needs and goals. 

 

Just to be very clear now with an example, there was one specific feature that many teams had to implement in different parts of the architecture. Essentially, users had to provide their business information to be shown on the profile. And you can understand this is web, iOS, Android and iPad app still was there and it should go from a front, any of these front ends down to backend to the database, APIs, backend force. 

 

This feature took two years to implement and edit field essentially took two years to implement and not because, not because people were not working, not because it was a bad company. like engineers were top notch, Scrum Masters, myself, were amazing. Everybody was working perfectly. We had retrospectives. We were improving. Everything you can check was there, but the emerging quality of the global system was so that it was super, super slow to do something which was not initially planned on the roadmap.

 

So yes, you can justify any separation, any compartmentalization.

 

But maybe we should not have these theoretical talks. We should really look and see what’s happening in the organizations. And that’s where I spent last 20 years actually working with real problems. And I tell you, yes, this local thinking, my kingdom versus your kingdom can be very well justified on paper and with any of these books and method, but it can be very, very painful for the leaders, stakeholders, even developers, and of course for the clients because those clients have been waiting for two years for the field and they were actually suing the company for not being able to provide them that very simple functionality.

 

Simone Cicero

Yeah, I see this again. This is something that it’s impossible to avoid. Organizations have to deal with trade-offs.

 

Alexey Krivitsky

Well, again, this now sounds like a justification. It’s impossible to avoid it. That’s why…

 

Simone Cicero 

No, no, but let me explain. Let me explain what I mean here.

 

So of course, whenever you separate a whole system into nodes and things and give these things a relative level of autonomy, you potentially incur in these small kingdoms dynamics and the system view gets sacrificed in favor of a more individual view, right?

 

At the same time, want to ideally, in an organization, you want to have a system that reflects the real nature of the work. So I think generally speaking, looking at an organization from a domain-driven design perspective and recognizing about the context and recognizing that these boundaries of context need autonomy is not a bad thing, right? It’s a good idea overall. 

 

Alexey Krivitsky

I don’t agree.

 

Simone Cicero

But okay, let me explain then you can maybe tell me what you think about it. So I assume that the problem when you separate units and teams and give them a relative amount of autonomy, because otherwise you just have a very big team and then it’s very hard to manage, becomes hierarchical, that’s inevitable. At least this is my perception, is that you lack the two things. 

 

You lack frameworks for these units to align and collaborate. So for example, when there is a feature that somebody needs from the market, you need to have a framework for this need to go through the organization and generate a collaboration between nodes, where every node has a relative skin in the game in the positive outcome of the collaboration. 

 

And another problem that I often see in organizations is that risk is not properly identified. So for example, whenever you have a monopoly, you introduce a risk or whenever you have somebody influencing the development and direction without, for example, directly investing in that direction. Using, for example, a hierarchical drive or force, that’s a risk you have because essentially somebody from the top can set a direction without having real skin in the game of the system. 

 

Very short, how can I say, making it short and then I’m keen to hear what you think. I think that you can solve the problems that are generated by separating domains into more autonomous teams by creating the tools for these teams to collaborate and at the same time ensuring that whoever wants to push a certain direction needs to be able to take the risk by investing in this direction, or sharing the outcomes with the units that are involved in making those outcomes happen. So it’s more a problem of language for collaboration than a problem of separating the units. So this is just a foot for thought.

 

Alexey Krivitsky 

Yeah. So I like this discussion and I like not agreeing with each other because then we can, right? Then we can have a very fruitful, rich discussion because when everybody agrees, there’s nothing more new interesting happening. Yeah, exactly. I know you invited me exactly for this reason. So listen, you’ve thrown several definitions here.

 

Simone Cicero

Yeah.

 

Simone Cicero 

Yeah, yeah, but that’s why we wanted to you on the podcast.

 

Simone Cicero 

Yeah, that’s my specialization, sorry.

 

Alexey Krivitsky 

I know, but like you said bounded context, you did several time and I’m opening Gemini and now to help me understand what there is. I know what there is, but I don’t want to misinterpret. So let me read, okay. One paragraph in Domain Driven Design DDD, embedded context is a central pattern that defines a clear boundary within which a specific domain model applies.

 

Inside that boundary, all terms, definitions and code have a unified and ambiguous meaning. To put it simply, it is a semantic boundary that prevents different parts of a large system from confusing the same words for different things. So essentially is a container of meaning. Actually, find it funny that we talk about the boundaries and your company is called Boundaryless.

 

Probably another topic, or maybe you can explain a little on that. So, but like, let’s stay on the topic. Bonded context. It’s about your domain language. It’s about your terminology. It’s about speaking the customer’s language, right? Never. And this definition, which I’ve just read, they mentioned org design.

 

They never mentioned here ownership of bounded context. So I think you are making Simone a very similar thinking bridge that a lot of people are making, which is merging domain driven design with the org design. Assuming that if there is a bounded context, if there is a domain, then it needs to be owned by a given team. And this is not given. There is no law of nature. Which makes you want to give one domain to one team. This is already a decision management can do or not do. So, you know, ando I think where a lot of confusion about team topology and domain driven design and, and Wardley mapping happen is that people mere these very independent concepts. Again, I think having defined customer domains, extracting domain language and using that language is in engineering is super helpful – then you can open up your class diagrams and you would see those entities, right? Which are there in a real world. Like in a banking environment, there will be an entity called a transaction or a bank card or a statement. Fantastic. As a software engineer, I’m all for it. But whether you attach a team to it or not, this is a very different topic. 

 

Simone Cicero 

Yeah, I agree with you.

 

Alexey Krivitsky 

Yeah, but somehow in our industry for last 510 years, because of very low quality books out there, which became very popular for the same reason that they are so bad written than everybody actually would understand them because there are very little reasoning in there. In those books. I’m not going to call names, but I know what you mean.

 

They merge these topics together and they say, whenever you have a domain, you need to have a domain team. This is not true because you might have a team, no problem, but you might have maybe several teams co-owning together several domains. Can be a very different organisational design, which by the way, will make people go from a domain to domain, learn different things, jump different contexts, be able to follow the customer value, get rid and avoid dependencies and all that. So this is exactly the org topologies 10x org book where we are trying to be very clear with these terms and not overload people with another, you know, bullshit layer. Excuse my French of the staff, but really go to the basics. 

 

And the basic is there is freedom. You can assign teams and people to whatever they want. There’s no single law of nature which makes you create platform teams or domain teams or stream aligned teams. This is a choice. And sometimes it is the best choice. Sometimes it’s the worst choice.

 

But let’s step back and think slowly about that. And I am a very slow thinker. And I would encourage everybody to when somebody is throwing a terminology, open up your favorite AI and really understand what they mean by that. Why we own this Simone, I like to use this opportunity to debunk another terminology, if I may, which is a famous Conway’s Law. Because people also put Conway’s Law in this discussion. You know, when you bring somebody like Mel Conway, who wrote this article in 1968, and it’s one of the most, you know, popular articles, somehow, when you put this in a discussion without going deep and thinking slowly, it is the end of a discussion because people will typically say, and yes, and male Conway said exactly that. Bam. End of the discussion. 

 

No, actually, and I just opened the Conway’s log paper on my computer is available. It is HTML website. Actually, it said the opposite of what people think he said. If you go very down to the last paragraph of his work, he said the following, “because the design which occurs, I’m just reading now, because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.” 

 

So essentially, he says, there will be architecture, there will be software design. Yes, no problem with that. But that architecture and that software design will never be right will never be correct. 

 

Because first of all, well, we know how this works. You never know what customers want without, you know, giving them and learning that you were wrong. And secondly, you know, the same happens with architecture, you can never get it right before actually doing something.

 

And he said the following, we must keep organizations flexible so that when our understanding of architecture changes, we don’t need to restructure our organization to restructure our architecture. And Simone, I’m finishing, but like once you figure out there’s a domain and you attach a team to a domain, good luck to flexibility. 

 

If tomorrow something changes and you like to re-architect or merge domain or extract new domains or maybe those domains were not really correct, you have now two problems. First, you need to change the code and the architecture. We know how to do it in software. But the second problem is that now you have also org design replicating the same structure of your software.

 

So Mal Conway actually said, do not replicate the structure of your software in your organization, keep it flexible. And the adaptive topology on the Octoplogies map is a collection of these ideas, Simone, how can we keep organization flexible so that whatever happens inside is easier to change?

 

That was my explaination to, you know, like debunking things that people use every day and don’t really like never have just spent 20 minutes slowly thinking about them. And I don’t mean you. I mean, like people who abuse this terminology, but actually somehow miss the point here.

 

Simone Cicero

No, in general, I especially agree with one of the points that you raised that and the passage of the article from Mal Conway you mentioned is one of my favorite, because basically Conway is saying everything is contextual. So you don’t just have to drink the cool head of the Conway law. You have to think about it in the context of your organization. You need flexibility and everything. 

 

So I think the other error we can make is that we completely destroy another person’s framework because we believe it’s completely bullshit. So I think I see signal everywhere. Also what I’m trying to do is at least in my practice with organizations is to distill a set of primitives, let’s say, that the organization then has the responsibility, as you said, to take a decision about. 

 

I’m also very thankful that I do not work with many software-centric organizations, to be honest. I tend to work with organizations where the concept of a bounded context or a unit is less attached to a piece of software, but is more attached to an actual organisational capability that can deliver a complete value proposition. So like, for example, a factory or, I don’t know, a logistics entity or a hardware development that develops actual piece of hardware.

 

So what I do when I work with organizations, I always insist on what you, another thing that you said, that you need to have ownership of a boundary. You whenever there is a boundary, there needs to be ownership of this boundary, right? So otherwise, if you just put boundaries in everywhere and then nobody owns the boundary, you have this small kingdom dynamics, right? 

 

Because people tend to just crystallize their scope of control, but they do not have any skin in the game in making mistakes or optimizing for products that nobody wants or something like that.

 

Alexey Krivitsky 

I think, Simone, the level in the details. So when you say if there’s a boundary, they need to be ownership. And I just try to explain why this is not always the case. But let me give you an example. Imagine there is, again, software example, there is, and but everybody would understand, there is this e-commerce website where customers can search for products, put them into the basket, buy them, come again, buy again.

 

And of course, there will be some functionality on the website, which is search. A customer should be able to type some misspelt product name and actually find the right product or products. So there will be somewhere down the line, some functionality that actually makes this for users happen. Search functionality. Is this domain? Is this bounded context? I guess yeah.

 

Simone Cicero 

No, but from my perspective, I think you are exactly clicking on something that I wanted to clarify. And again, I’m thankful that I do not work so much with software companies. But in my point of view, that would never become a boundary, an actual organizational boundary. Why? Because it’s not a complete value proposition that you deliver. So that would be just maybe one team, if you want, inside a broader unit that is maybe the e-commerce unit. And again, I’m simplifying because we are not doing mapping here. But that’s what I said before. 

 

This is where maybe you can have a delivery topology in this point of View because this platform serves many other teams. And maybe there is somebody in the organization, and I’m going to make an example now, which wants to have a certain behavior because it can see the big picture. 

 

So for example, I was working with this hardware development company. I’m not going to name it. But it’s a founder led company where there is a very strong strategic perspective. And the founder wants, for example, a certain strategy to develop over time. And this company, at the same time, has multiple capabilities. For example, it has a very broad hardware development capability, on top of which multiple units are developing pieces of software to serve vertical markets.

 

I would never say the platform that develops the hardware is completely autonomous to do whatever they want, because this would probably harm the capability of the software companies that build on top to actually be free to build and strategic. So in this case, the founder would say the platform unit..

 

I’m not going to give them, for example, an objective of increasing their margins. But rather, I’m going to give them an objective to stay true to a certain strategic pipeline so that the others can build upon. So it’s not going to be a full, what can I say, in your terms, it’s not going to be an adaptive topology. It’s maybe going to be a delivery topology. And again, this is a choice because this founder is taking a risk by saying our platform doesn’t serve the ecosystem. 

 

It serves only our internal entities. So I’m taking a risk. And this risk, I’m owning it by saying I’m going to invest into the platform. Because another choice could be another customer I’m working with and doing it. OK, the platform can be an adaptive topology. But then they own their own P &L. And they can serve other customers. They can also serve other customers from the ecosystem. Because somebody needs to own the risk. 

 

The point that I’m making is that we need to be able to give people the primitives to understand that the major drivers of organizational effectiveness is risk taking, risk owning, and collaboration frameworks. Because otherwise everything becomes like just a hierarchical nightmare where somebody decides and the other execute. That’s the point that I make.

 

Alexey Krivitsky 

Very much like Simone that you use the word a choice and you made this two very different examples. So yes, exactly the choice, whether some context, some boundary, some domain will be owned solely, exclusively, or it will be co-shared. And I think there’s a, it’s not even black and white. There’s a whole spectrum from like private ownership to shared ownership.

 

And you need to discuss that. I very much like the second thing which you just said is that like in your world, like a search functionality will never be a kingdom of its own. Maybe one message to our audience is that if you are thinking how to improve your organization, my, it’s not a rule of nature again, but it’s my observation that there is a very high chance that the domains or boundaries that you currently have are defined too narrowly. It’s very likely that you have a so-called search team or iOS team or some kind of a payment platform team because of the history of taylorism, of factories, of misunderstanding, of other, other, other things.

 

Simone Cicero 

Parcelizing work all the time. People are parcelizing work all the time.

 

Alexey Krivitsky

I don’t have that. Yeah. Yeah. So this, this is likely happening. And actually over time, those compartments will, get even smaller and smaller and smaller. So, I, I think if you really would like to benefit, from the intelligence of your people and the AI intelligence, which your people can use these days, the boundary should be broader.

 

And as broader as possible, right? And you need to find ways to broaden them and challenge your existing lines that you draw on your org chart and stuff. And that’s the first time I’ve mentioned AI in this talk, which is surprising because usually that’s the first one I throw in because that’s May, 2026 and AI is in everybody’s mind.

 

And Simone, I’ve been traveling with this 10x Org book recently to many meetups and conferences. And the message is like this topic of Org design and the way of boundary is, it’s always been a topic, but now I think it becomes even more of a hot topic because of the AI adoption.

 

Simone Cicero

I think one of the points that I want to also make is that I agree very much with you that we shouldn’t obsess about separating team duties inside a boundary. Because, for example, the approach that I follow, whenever one of my customers define a boundary, which is typically a product owning or a capability owning unit, I always say, try not to impose from the top how teams should be structured and how work should be managed. 

 

Try to consider it as a black box, because the people in the unit will figure out how work needs to get done. So it’s a contextual choice. I really strongly advise against saying in this organization, for example, everybody uses team topologies, or everybody uses scrum or whatever, right? Because this is really one size fits all thing that doesn’t fit with the contextual nature of the work that people are trying to get done. 

 

So I would really strongly advise against mandating the managing approach of the work inside a product boundary or a capability boundary. So that’s something that I think resonates with what you were saying. Anyways.

 

Let’s get to a close because it’s been quite a lot of time already. And thank you so much for the energy of the conversation. Wanted to ask you, first of all, if you have any breadcrumbs to share with our listeners. You have been studying a lot of approaches and working on this for years now. So most likely you have found some gems and books or readings or other things that people can look into to ensure that they do not get too much red pill on anything.

 

Alexey Krivitsky 

Yeah, I think I’ll just go shameless and just show. Again, it’s. Why, right? You just mentioned breadcrumbs. these, you know, some things that people can, you know, go and pull and learn more. So essentially that book with which we just published in a February, a few months ago, essentially it is a collection of breadcrumbs. We studied a lot of material on org design, org change, AI adoptions, and we brought like the the common dilemmas people have and actual problems people have to the table in a very simple and digestible form. The book is written as a business novel, so it’s even easier to read. But then, of course, it’s just a small window.

 

This book is just a small window into the big domain of org design and organizational change and transformation, and org psychology and whatnot. So, then people hopefully can follow, you know, they pull the lines and go deeper into that.

 

What I read these days and how I read these days, two maybe pieces of advice to our audience. We are in an age, 2026, May. We’re currently recording on the May 15th. Do not read alone is the mantra I’m using. So we have this great, great opportunity capability given to us almost for free, you know, to have a PDF of your book, upload it to your favorite LLM. 

 

And then after you read a chapter, you can go to LLM and actually have a meaningful slow thinking discussion similar to the one I just had with Simone. You can argue about the chapter. You can ask GPT to provide you the opposite arguments, right? You can change sides so you can broaden and deepen your understanding.

 

You can even ask GPT to make you a test, a survey quiz to test your understanding. So never read alone. If you’re buying a paper book, always try to get also like a PDF version of that. And I think there you can ask for more breadcrumbs and more links. And this is how we should be learning today. The other piece of advice I would like to give.

 

And by the way, in our book, actually embedded AI assistant. There’s a QR code and you will go to a custom GPT who knows about the book, even if you don’t have a PDF. So we want people to use AI to read our book and go deeper in that. The second piece of advice where I’m currently going to, I’m following like maybe 30, 50 handlers on Twitter, X.

 

And I built myself a personal assistant with Claude code, which daily will would scrap those accounts and will create me a digest of new things. And I have a three kinds of digest. And I have a digest about recent scientific papers in AI. think it’s helpful even if you’re not a software engineer to read at least some of the scientific things about AI.

 

I have another digest, which is like a business digest, you know, a business implications of AI and have some more. So essentially one Twitter handle I really recommend people to follow is from Andrej Carpathy. He used to be a director of AI at Tesla 10 years ago, and he was a co-founder of AI. And that, that guy is – it amazes me, Simone. He’s like the deepest person in AI because he knows how to build AI and he builds, but the way he explained that and the way he philosophize about the implications of AI, it’s just so easy to follow. And every week, essentially, he comes up with a very cool new idea of AI implication. The one which is super popular a month ago was LLM Wiki can build their knowledge base with AI and I’ve built myself.

 

So I don’t just read alone. I upload the books to my Wiki and I disassemble them into parts and into concepts. And then I can have a discussion with my AI on the very broad, you know, domain. And this is just wows me every day. These capabilities. So don’t read alone. Use AIs to help you go deeper, ask AI who you should follow for your interests, ask AI to create your digest so you can find those breadcrumbs for yourself and explore and experiment. That’s the AI experimentation I think we should all be doing.

 

Simone Cicero 

Thank you so much. I hope you enjoyed the conversation like I did. It was a long, long overdue, I would say. So thank you for joining us. I know you have been traveling for your workshops and book presentation events. So I appreciate that you find some energy to show up today with us. And our listeners for sure will have tons of insights from this conversation. And of course, for our listeners, you can head to our website, boundaries.io/resources/podcast. And you will find these episodes with all the transcript, all the things that Alexei has brought up to your attention. Maybe you can throw the transcript into an LLM and ask the LLM to tell you what he thinks about it. So don’t read alone to drink too much cool hay, try to always find your way to stuff and especially your development. Thank you so much, Alexey. It was a pleasure to have you. And to our listeners, of course, until we speak again, remember to think Boundaryless.