Alexey Krivitsky & Roland Flemm - The value of Org Topologies in the era of DIY-frameworks

[00:00:05] As we don't have a paper, I think we'll have to improvise, Roland, today.
[00:00:09] Let's do that.
[00:00:11] In French?
[00:00:12] No. No, thank you.
[00:00:17] Hello everyone. Hello. Hello everyone.
[00:00:22] Yeah, so, uh, this will be in English. I'm sorry, my French is a bit.
[00:00:28] This talk is about the ofologies in the era of the DIY frameworks.
[00:00:34] Hold on, hold on. What are those DIY frameworks, Roland?
[00:00:37] DIY. Bricolage. Yeah. So do it yourself. We are now a little bit used to Agile, it's been here for years already. And what we see as consultants that organizations will start to pick and, you know, cherry pick things from different frameworks and combine things. And there are frameworks targeted at, well, here you have a bunch of items and just try to make something nice. That's the do-it-yourself era.
[00:01:09] Yeah, and uh, you know, we are presenting you the topic of work topologies. We just finished a two-day class here in Paris. So it's a big topic, it's a vast topic. We barely were able to put it in two days. So now we have less than an hour. And we always need to find a window through which to explain this topic. And this time the choice was obvious. Because we are at a full conference, we decided to focus on the flow. So, uh, speaking of flow.
[00:01:41] I need to give you a word of caution. Because what you are about to hear and see might be disturbing and cause unexpected side effects. Okay?
[00:01:54] So, uh, we're talking about things that will be going a little bit against the flow or things that might be known to be normal and accepted, maybe in your head, maybe inside your team, your company or your industry. So you be warned, right?
[00:02:10] Yeah, and why is it so? Because as our mentor and coach Craig Larman says, you cannot unsee a local optimization. Won't you once so it, so hopefully in this talk you'll be able to learn.
[00:02:24] And see some local optimizations that when you go back to the offices tomorrow or next days, you will start seeing them and some different thoughts might be popping up in your in your mind. At least this is our hope for this talk. A few words about us, so that you know our context and what we're good at.
[00:02:46] Yeah, these these are the better versions of ourselves, generated with AI. Um, my name is Roland Flam, this is Alexey Krivitsky. We have been sweating for about two years, more than two years on the subject of organizational development, we call our project orgologies. And we spend decades of knowledge, uh, in both software development and consultancy.
[00:03:14] We both are Scrum trainers, but from different churches. So as we say, we go to different churches. We pray to the same gods of agility. Adaptability, the right side of this picture though, again, about the flow, right? We found ourselves swinging, swimming against the flow somehow. So we visited some talks in this conference and of course we know what happens in the industry by following a lot of people from you guys on LinkedIn. So we found ourselves that we are not really mainstream people. We're not trying to say popular things. We're not trying to say things that you that make you comfortable. Uh, not because we want to be special, uh, but because we believe the world is not black and white, right? And the mission of topologies is to help all of us to create a bit more thoughtful organizations, right? And because this world is not black and white, of course, we would like to show you more options. Right? We're not saying some options are better or worse than others, all depends on the context. So this is the map ofologies and we're not going to go into every box. Today you'll be speaking out of the box. If I may say. Uh, but essentially we will be talking about this multi-colored panel of different options that you have, hopefully just to expand your understanding of what's possible in your organization.
[00:04:47] When we look at the box, the map that we have, it contains 16 boxes. And we can use them to map and plot and see ecosystems, so combination of boxes together creates value, and the map is an invitation for you to try to see who is involved in creating value on a department or the whole organization and create these things that we call ecosystems. And once you see your ecosystem, you can talk about it, and you can see what what is it doing for us. And maybe also what kind of options you see to, well, redesign your ecosystem.
[00:05:26] Yeah, so we're trying to make invisible things slightly more visible so you can have wonderful meaningful discussions about your organization and about the vector of development of your organization. Anyway, uh, let's get back to the flow.
[00:05:41] Yeah.
[00:05:44] Let's introduce Flowtech. This is an imaginary company. And their vision statement is, we are creating a world of AI powered IoT on blockchain, Internet of things.
[00:05:55] Anybody works at Flowtech?
[00:05:57] No. Good, good, good.
[00:06:01] Now there's a use case described. I'm going to read it for you so you understand what kind of challenges they have. We they create worlds where your toaster strategizes your breakfast using AI. Your refrigerator trades energy credits on the blockchain to keep your greens fresh, and your coffee maker is cloud powered to brew your coffee to perfection before you even wake up.
[00:06:25] Wow.
[00:06:29] Anyways, uh, of course they have some challenges and first let's look what happens at the ground level of this company in the IT. Of course, IT is always somewhere ground or below the ground sometimes, right?
[00:06:40] Well, they're not in the basement.
[00:06:41] Well.
[00:06:42] Not this one.
[00:06:44] These guys are not in the basement, right? They've been already uplifted, upgraded, elevated to a better state of being. And in the IT department, there's this guy called Florian, also known as Flow, right? And this guy is our head of engineering. And over the past several years, he's been visiting different conference, read all the books that you can find on this topic and he has invested heavily in creating fast-flow teams like some of you, or maybe most of you and most of us has been doing, right? Uh, he read all these books and he successfully practiced modern frameworks like Scrum and Slave. And of course, he dovf into the new era of DIY frameworks like unkicks and team apologies. So he really, you know, his knowledgeable.
[00:07:34] He's knowledgeable.
[00:07:35] Kind of.
[00:07:38] You know, explored the whole space and tried to take the best pieces out of it, like most of us do, because we are in the era of DIY frameworks, like somebody said before us, right? We don't believe in agile frameworks, et cetera. So we need to pick different things, et cetera, et cetera, et cetera. He's not alone in the company. That's a good.
[00:07:57] No, we we have a second persona that we want to introduce. This is Florence, we thought we'd use a French name for the occasion. And she is a developer and she works in a very specialized team working on IAM, that's um, identity access management. And they have distributed cloud-powered credential storage solutions. Wow.
[00:08:21] This team is also known as forgotten password team.
[00:08:24] Okay, okay, well, that doesn't sound as sexy.
[00:08:29] Well, she's happy in her team, so she's got a lot to do. She's busy.
[00:08:35] Yes, and they follow the advice of yesterday keynote speaker and another speakers Sunday Hog and Dawn, right? Was speaking yesterday. And of course, it's not a new thing that, well, you need to break the monolith into pieces and you need to speed up development. And her team was doing wonderfully, right? That's the flow of the forgotten password team. They are the fastest team in the company. They can put things into production. And we actually, we might sound like sarcastic, but we are not. I mean, this is really important, right? To break things down. Like as a developer, I've been doing this for many years and helping other companies do that. So it's right. It's not really a caricature. This is what really happens in the industry. A lot of people focus on these things and these things are the right things to focus.
[00:09:25] Exactly, and especially if you look at what's happening in IT, then we can celebrate all kinds of successes with these strategies. I mean, in IT we see teams with happy people and that's because management has put so much effort into reducing their cognitive load. And and creating this private ownership, so it's very clear, you know, everybody knows their zone of accountability. There's clarity all over the place and this creates teams, many teams that are really in a state of hyper flow. Not sarcastic. This is what people do.
[00:10:01] All right, so let's take the elevator and go up the board room and see what's happening there. And currently in the board room there is a meeting. All right, and somebody says to go faster, last year, we double the number of teams from 30 to 65.
[00:10:20] But uh, oh, I can't see it. And our costs grew 300%.
[00:10:25] And our return on investment dropped with 25% and CAPEX, OPEX, SCHMEX, they all are down. What is happening?
[00:10:33] Yeah.
[00:10:34] In other words.
[00:10:35] Wow, IT is things up. Yeah, yeah.
[00:10:40] Who to blame? Always the IT, right?
[00:10:42] So.
[00:10:45] But, yeah, there it is. Heads will roll. We need somebody to be accountable for this.
[00:10:50] Bring us the head.
[00:10:51] The head of IT. Yeah, we need him here.
[00:10:53] So now the Florian takes the elevator, interrupts his work and needs to go to the upper floor to have some discussion. So please, in a minute, have a discussion.
[00:11:06] Turn to your neighbors, say hi and you can speak in French or any other language. Have a discussion, what kind of a conversation do you think is happening in the boardroom when Florian enters that interesting group of people.
[00:11:21] Have a discussion. Few minutes.
[00:11:26] Yeah, right? Some people don't even have to talk, they've been through this discussion. They just know what happens there. Yeah. No matter what you discussed and realized, probably we can all agree on one thing is that, you know, these people, Florian and the board members, they speak kind of different languages, right? Well, what do board members say?
[00:11:47] Well, they talk about market share, profits, they see ROI, they have shareholders they need to report to.
[00:11:53] And he says comes, leave team apologies, going to float, all those things that he tried and he believes are working.
[00:12:00] Yeah, because he's not unwilling, but listen, all the numbers are red, you know, ROI's going down, OPEX, whatever it was.
[00:12:08] And Floren says, you know, my measures, which I can collect, are actually green. It's team velocity, it's lead time, it's deployment frequencies, all the door metrics are green, so.
[00:12:19] What's the problem?
[00:12:22] There is a problem though.
[00:12:24] Ladies and gentlemen, breaking news. Breaking news.
[00:12:32] Essentially, higher built a machine which allows you to do impossible. You can cook now everything in your home.
[00:12:44] This is the commercial they're broadcasting all over Europe. The Peking duck experience. Put it in the oven in the morning. Come back home at night and you have the perfect peeking dog. This is a real threat to Flowtech.
[00:12:58] Higher is taking the whole market with AI home appliances, they can actually replace everything Flowtech has been building. So fix it.
[00:13:10] Fix the IT.
[00:13:12] All hands on deck.
[00:13:16] Now let's go out of the story and get a bit more serious, right? So Florian, he's been looking for this different things. Out there in the books, the conferences, and he experienced experimented with different things. And well, he wanted to solve problems they have. But then he realized over time and especially after this discussion they had in the board room, actually, I hope nobody flew out of the window during this discussion, is that solution. They solve existing problems, and surprisingly, they can also create new ones. So every solution you're currently bringing to solve your known problems, eventually in some kind of unpredictable manner, will create new problem, which hopefully just a better problem to get solved. So he says, well, each team is very fast in its own bounded context. But essentially none of the team can address the current challenge that we have. And well, if we need to replan and and react to this threat that we have in the business, the whole road map of the R&D needs to be discarded and it would take forever because we just do it once a year when the budget cycles comes, right? So we need to be faster than we are now. And he also says, you know, I thought my R&D was adaptive because, well, whenever I go, all these methods say, we're helping you to build adaptive, more adaptive, more adaptive.
[00:14:42] System, but yes, they are maybe adaptive due to some extent. But in fact, we were just getting better at doing what we already know. So we could adapt when the strategy was stable, but now since the whole landscape changes.
[00:14:58] We realized, oh, adaptability is expensive. The switching costs will be too high. Yeah.
[00:15:04] So there there are things that are happening now in the world that we were not prepared for, and that's a surprise. That's really a surprise. Good news. Is there any?
[00:15:17] I hope so.
[00:15:17] Oh.
[00:15:20] There is this conference you can go to, like Flowcon.
[00:15:24] And that's what Florence and Florian did. They took the train and they came to Paris and well, they were in the audience. And they actually went to this great uh, what's this called keynote at 2:00.
[00:15:39] Yeah, so they went to this talk by Alexey and Roland, these two gentlemen. And in that talk at that conference, Flo and Flo, Florian and Florence. They were introduced to this idea that, yes, flow optimization is important, right? So what you guys been doing in a Flowtech is great. You've been trying to complete these skills, add necessary skills, AKA capabilities, develop those teams and it's a work every team member, every Scrum master, every coach, every head of engineering. Should be proud of. Yeah.
[00:16:15] It's what we've been doing over the last years, getting, you know, ready with Agile. We were investing in creating these faster flowing teams. We were trying to make them more capable, better the definitions of done, faster, so we were closing their capability gap to try to let them be able to do everything.
[00:16:36] Another thing Flo and Flo learned at that talk at that conference, right? Is that this move, this horizontal move, this direction they've been investing on can also be called as a first agile wave. It's not the full agile, but it's important vector, it's important part, important component of agile. And some people call it the first way of agile. Well, assumedly, there's more than just.
[00:17:02] Those people call it one, yeah, those gentlemen.
[00:17:09] But of course, there's another gap up there, which those people call a value gap.
[00:17:15] And a value gap is a different thing, right? The value gap is different in how teams understand value and what they call products. And what business stakeholders and customers outside of your building call value and call products. And what they were told at this talk is that. Well, if you create this teams which are super narrowly focused because you really want to make them fast, right? And the only way essentially to make teams really fast is to limit the number of things they are owning and accountable for. But then these people might think an iOS app of a bank is a product.
[00:17:57] A service that does something is a product. That authentication component Florence has been working on is a product or a platform.
[00:18:04] Exactly.
[00:18:06] But essentially from the customer point of view, a banking app is not a product, it's just an interface to go to the depth of bank and talk to the backend banking system to see my transactions on my mobile screen, right?
[00:18:23] So the vertical axis that we are proposing to introduce for improving your company has to do with the scope of work, it's a it's a product orientation. Not just looking at how well is my team in doing things, how what are their capabilities, but also how much do they know about the product that the customer is actually buying from us. And this is not exactly in the flow of other talks that we've heard before.
[00:18:52] Right, and the true organizational or if you may business agility or whatever we might call it in our industry that is happening now. And that will even become even more and more happening because of AI and other companies that are trying that. Will help to create this high level of organization that masters both. Not just the capabilities and flow in the teams, but also help the teams and developers to have a broader understanding of the value and the customer ideally close to the value and product definition the customers have.
[00:19:30] Yeah. So that's that's what we would call a second wave of the agile movement. To include that product knowledge to include that start closing that value gap.
[00:19:42] Now they maybe there was a bit too philosophical and there were too many words and too many uh hard pictures to understand. So we would like you to bring this back home and again, this time please talk to somebody, right? You might actually want to sit closer to somebody and have a four minutes discussion. Well, if your organization would decide to go, you know, uh, what will it mean for the organization to be bridging both of the gaps? Okay, so please have a discussion, what will it mean in your organization if you decide to try to close those two gaps? And if you didn't understand what those gaps are, ask the other person. Maybe she understands, have a discussion about that, please. All right, thank you.
[00:20:26] It's good to hear people chatting at the conference. Thank you for doing that.
[00:20:32] Have to do it in French. On reprend, mesdames et messieurs.
[00:20:38] They told me to say that, I don't know.
[00:20:40] Roland parle bien français, ouais.
[00:20:42] Toi aussi.
[00:20:43] Okay.
[00:20:44] Okay.
[00:20:46] Okay, so, uh, maybe it was confusing, right? Maybe it was not clear because that move up is not really, really known in the industry, I think. Everybody's talking about flow. Right? Not so many people about talking, yeah. Maybe, maybe something else is also important. We're not saying flow is not important. Flow is super important. But is it the only component? We know at least two, maybe there are 5, 10, 100 different other components which we should be thinking of. And if we know many components, which one is your primary component to optimize for and which one to sacrifice or vice versa? So Flo also had a lot of these ideas in his head now.
[00:21:32] Maybe we've been focusing too much on the team level flow. Spend a lot of money on it.
[00:21:43] Well, and actually I never considered the product I mention. What would that look like with my current teams? like difficult.
[00:21:54] And uh does this mean that all the teams will really collaborate intensively on the same product strategy that's like big. Well, difficult. Hmm.
[00:22:06] And of course other thoughts happening in her hand in her head like, well, all teams working as a one team of team. How does that supposed to work, right?
[00:22:17] Will it mean that we have to share the same bigger context, not divided, but actually share broader space of work?
[00:21:32] Maybe we've been focusing too much on the team level flow. Spend a lot of money on it.
[00:21:42] Well, and actually I never considered the product I mention. What would that look like with my current teams? That's a bit difficult.
[00:21:53] And does this mean that all the teams will really collaborate intensively on the same product strategy that's like big. Well, difficult.
[00:22:06] And of course other thoughts happening in her hand in her head like, well, all teams working as a one team of team. How does that's supposed to work, right? Will it mean that we have to share the same bigger context not divided but actually share broader space of work? She thinks that might actually sound interesting, she says. But then we will have to discard our team's individual backlog and the road map and the discovery work we've done for our authentication forgotten password team work. And then how about the other teams? The search team, the catalog team, the checkout team, the reporting team, the watching team? Do they all have to just stop doing what they're doing? Just join forces and do other things? What happens to the product owners backlogs all this investment?
[00:22:59] Teams working as one big team. Well, you know,
[00:23:04] I don't think so. It's not efficient. It's not going to work.
[00:23:09] And what about co-ownership? If you all own a certain responsibility, then nobody has that responsibility. We all know that, right? This is not going to work. Cognitive overload. I mean, how can you know everything of a product? Heads will explode. And how will be responsible? Okay? Not on my watch.
[00:23:30] Teams will be busy learning. Learning doesn't bring us any money, right? It will kill the flow. It's not going to happen.
[00:23:38] Right remarks, right? This stuff should happen in people's head because these things are dilemmas, right? They don't really have single answer. And other things happening in her head is like she's she's thinking, hey, I used to work in a startup when we program five different systems in three different languages. And we actually work as one big team. She thinks. And then we also talk to the customers ourselves. Well, and everything we worked on was relevant, right? If you're talking to the customer on a daily basis and owning everything that is happening there, like if you are in a startup, everything you're working on is relevant. Your team is always relevant. But she thinks, hmm, I wonder if they can actually be applied to corporations. Like flo tec, they're not startups. yada yada yada many other thoughts and dilemmas happening in their head, right?
[00:24:37] Okay, we started with this quote, right, from Craig Larman. You cannot unsee local optimization. Once you see it, it always stay with you, with with with you, right? So let's deep, let's go deeper a little bit into this systems thinking applied to org design concept and dive a bit more into this. From the systems thinking point of view, right? If you're optimizing the individual parts of the system, you are guaranteed not to get optimized system as a whole. That's like
[00:25:10] It's a law.
[00:25:11] It's almost a law, it's been discovered in 70s when system thinking was really hard invented, studied, proved at different universities. Again, if you're trying to optimize individual parts, you're guaranteed only by luck, only by chance the whole system improves. We all understand that. And the more parts there are, the more connection there are, the less chances that there are this will happen.
[00:25:36] So to make this a little less abstract, the system, that's let's call it that's the organization that is trying to produce value. And the parts in this system are the teams. So if you keep on pushing a lot of energy and optimizing single teams, then the chances are, well, there are no chances then you know for sure that your whole organization will slow down ultimately. And we see this happening.
[00:26:03] That's systems thinking. Everybody who studied, learned, Wikipediat systems thinking, they know this thing. But there is one counterintuitive aspect to this, right? So, in order to optimize the whole, we actually need to sub-optimize the parts. Like it's either that or that. So if we're caring about the whole, parts will suffer. They have to suffer and they have to accept that suffering for the benefits of greater good. If we value adaptability is our organizational optimizing goal, well, then maybe some teams will not be at the fastest flow possible. Because from time to time they will have to switch context to stay relevant and learn something they've never worked with before. And this actually goes very much against a lot of things that we hear at this conference and other conferences and what is said in many, many books these days. A lot of focus on team level improvements, not so much focus on global things just because it's easier to improve at a local level and measure and be happy etc. So it's hard to optimize the whole. To make it a bit more concrete, right? Local optimizations versus global optimizations. Like every time somebody says to you, it's not efficient, you should ask, what do you mean? Like locally or globally?
[00:27:34] You know, efficiency can be local or can be global. Right? Maybe it's not efficient for this team to stop working of what they're working on and learn, it's not efficient for the team, but it's more efficient for the global organization, for a global system, for a department, for a bunch of teams because that upper system, bigger system is learning. Is it also short-term or long-term, right? Every time somebody is mentioning the word efficiency, you should have this sound in your head because what do you mean? Small, big, local, global, right? And then if you clarify what they mean, maybe you're trying to optimize globally.
[00:28:14] And this person is really much motivated to keep optimizing things locally and that's why you have this constant conflict in the company between product managers and heads of engineering. Business stakeholders, scrum masters, whatever that may be, they think about efficiency just differently. Another example can be, oh, this is a fast flow team. Fantastic. Great. But at which cost at the global level?
[00:28:42] You cannot be locally fast without any side effects. Right? If I'm playing in a band and I'm a very lousy bass player, if I play a bit faster than the rest of the band,
[00:28:56] That's probably the last gig I'm going to say. It's called jazz.
[00:28:59] It's called jazz.
[00:29:00] It's called jazz, right?
[00:29:03] Yes, sometimes. Which undesired side effects it will create in the organization in long run? Maybe positive, fantastic, something unexpected, maybe not, but it makes sense to think about this. We hear this word fast and flow and efficiency, what exactly do we mean by that and how we measure it? Private code ownership reduces cognitive overload. If I own just one line of code in the company, I'm the fastest developer ever. So there's some limit to this, right? Well, you guys know more about this with domain driven design, of course, it's not just one line of code, it's some kind of context. yada yada yada but this is the thinking, right? At which cost? And how will it impede organizational learning in long run, if we divide and conquer, etc, etc, etc?
[00:29:57] Yeah, so that's an introduction to trying to think more systemically and deeper and not just go for the easy solution because systemic means there's a lot of stuff involved and it's complex and you need to do some slow thinking to really understand what's happening. Now, we think it's time for discussion after this.
[00:30:15] And we promise that's the last time we asking you to do something unpleasant at our keynote.
[00:30:20] Uncomfortable talk to your neighbors.
[00:30:22] So again, talk to your neighbor or talk to your imaginary friend and I see a lot of people are talking to somebody inside, that's all right. Think of some examples of those local optimizations that you observe, have observed, might be observing in your organization. So which means what we're optimizing locally without paying attention to which effects it might have on the global picture. And by global, here we don't really mean world, ecology, forget. We mean business. And like for the for the company and for the business and for the customers.
[00:31:01] Well, a small example, my team that I'm working with, I work I'm a product owner and I have a team and I make sure they get a lot of work. But it's the forgotten password team and actually, well, my team is very busy, so locally we're very well optimized because resource optimization is at 100%.
[00:31:19] But from a global perspective, my team doesn't really deliver any value to the customer because they think the forgotten password routines work fine. Okay? That's an example of not well, it's locally optimized but globally not giving any value. Now, please do talk to your neighbor and see if you can identify.
[00:31:37] And before you start. Don't blame people. There's no blaming in systems thinking. If somebody is optimizing locally, it's not because these people are stupid, evil, dumb, whatever. Maybe they are. But it's not because because of that they are locally optimizing. They optimize locally because there are some motivations in the company to think like that. So don't blame people, just try to observe some systemic behaviors that's happening. few minutes, please do talk to your friends.
[00:32:11] Okay, it's great energy. Thanks a lot.
[00:32:17] Now you know what to discuss over the bigger break which is coming, right? More examples of local optimization. Anybody dares sharing briefly one thing?
[00:32:26] Like a very good one, very good local optimization.
[00:32:29] Anybody dare sharing without the name of company, of course. No.
[00:32:33] No. No.
[00:32:36] Anybody wants to share one?
[00:32:37] I will share one then. Yeah.
[00:32:39] Okay.
[00:32:40] How about making sure that all deck chairs are perfectly organized on the Titanic? Hm.
[00:32:49] Or somebody in a restaurant chopping onions and there are a lot of onions chopped and everybody's crying but you don't need so many onions. These are metaphors for local optimization, of course, you found something more specific, right, which makes sense only in your context. It's important to bring back this language of local optimization versus global optimization, long-term, short-term to your company and start kind of questioning in a good way intentions of other people.
[00:33:18] Right? So we believe it's it's important as never before to start thinking systemically. Uh, we have 15 minutes, so it's time for questions. Anybody?
[00:33:30] I have a question. Sorry, I love asking questions and now that I have the opportunity to be on stage, I can might as well abuse it to ask questions.
[00:33:39] You go, you go first. Roland, here's a question. So what is the question, sir?
[00:33:43] I'm going to make sure that this is a question everybody wants to know. Um so moving up, you know, towards that product dimension and making people know more and be fast. Does that really work in real companies or is it just an abstract concept that you guys bring here to stage? Are there any examples of those companies and how do they do it?
[00:34:05] Well, good questions, Roland.
[00:34:07] Yes, thank you. You've come well prepared, I have to say.
[00:34:10] Thank you.
[00:34:10] Yes.
[00:34:11] Yeah. So I guess a lot of you share this, right? And we also asking this question ourselves. So we are doing a kind of a research of our lifetime, trying to find these organizations and go inside and talk to them. Talk to managers, product managers, executive developers, the main people, developers, and understand like, so how does that company work?
[00:34:34] We'll give you several examples of such companies. You can find them on LinkedIn and actually approach them and talk to them. One of them is really not known and none of them are actually known. None of them are like Apple, Google, etc. This company is based in Ukraine and is the largest producer of B2B restaurant automation software. So if you go to the restaurant in Ukraine and you've been served there and everybody welcome to go to Ukraine to my hometown Kiev after the war, please do this, visit us. Um, then you'll be probably served in a restaurant with their software. So a few pictures here, a few snapshots of org design that in Orgy's language we call org design scans, it's like you're flying around the company and what you see. And this part where Roland stays, that's what was before 2022. They had like nine islands.
[00:35:30] Nine small islands and by colors we mean different classification based on Orgy's. But they were low level archetypes. Meaning every company, you know these you see these dotted lines around the teams, that's the context they were owning. Every team was owning some same small context. Some people were owning components like a payment component. Because you're doing restaurant automation, there are different printers in restaurants to print checks and all that. There was a printer driver team in this company. Right? Some teams were building a bit more understandable by the customers features. Some teams were building a constructor so the restaurant can build a website with a menu for itself, etc, etc, etc. But every team has its own list. I would not even call it a backlog, a list of things to do, a list owner, product owner and a team lead. Right? It's a very classical setup you see in a lot of organizations. And after about a nine months of systems thinking and talking about the problems they have and trying to understand what they want to be when they grow up. They realized, okay, we can actually try to learn how to work together again like we had worked when we were small. Let's go back to this idea of we are a team of teams, right? And essentially they in on that part you have nine teams, here you have six teams. It doesn't mean they fired people or people quit. No, they reshuffled teams. They let people self-organized in a new teams and they would and they made sure these new teams had knowledge of different components. Like if there was a team who knew printers well, they make sure those five guys go into different teams so that five teams at least out of six could do something with printers. So this was the idea, like open up, right?
[00:37:24] Some key concepts they did. It was a smallish company, 50 people in R&D. They formed they total of six, not only cross functional. It's important. Scrum talks about cross functional, this come. Uh, but they also cross component teams. That's a very big difference if you want to go up on the vertical axis. And teams were detached from the architecture. The opposite advice that we heard many times at this conference. You detach teams from the architecture and now all these teams together co-own that architecture which sounds like a very bad idea. But if you do it carefully, right? If you do it thoughtfully, if you put some thinking, coaching, communities, that actually work pretty well. And when team pulled an item from the backlog, they might pull an item which required work in a component they have never worked before. They can give it back to other team who had more knowledge or they can say, okay, that's interesting. It's the first time in our lifetime we're going to open up this repository. And when they open up repository, what happened within the first half a year in in this company, developers were like, oh, that's interesting.
[00:38:39] This repository had been owned by that team which doesn't exist anymore, but we see the team used this special technology for deployment or whatever database scripting migration, but other repositories that we know already, they do something different. What do we do?
[00:38:58] Let's standardize, let's simplify, let's change this repository so it behaves like other repositories. So the level of complexity of the architecture goes down when you do this. And when things become more obvious and transparent and visible, owning and co-owning becomes even easier and even better. So this vertical move, sometimes we call the scaling or simplification because we're trying to simplify and get rid of things that are really bothering. Okay. Uh and there are videos, of course, you can find online about this company. Another example of a slightly bigger company. Pandadoc.
[00:39:39] Pandadoc. Um, as you can see, it's a more complex organization and this is the ultimate result that they've achieved. But what they did actually is create three big groups of teams and you could say that that's their bounded context they work in. And in that context, all the teams try to share as much information as they can, again, with the same effects of emergent architecture, emergent standards and you name it. So, uh they, they teach each other across these teams about learning about new stuff that they haven't done before. Um and it's not like a journey that happens overnight. The story that you just told and this story from Pandadoc, it takes years and years and years to do this. And it's done with small experiments that fail and then we retry again. So, don't think this is magic happens overnight. This is a journey. And a tool like Ortopologies can help you to travel that journey in a sensible way and keep your point north where it is.
[00:40:41] Yeah, and this team, this company, they didn't use Ortopologies. They use actually ideas from large scale scrum less to arrive to this design over five years of experiments. One uh particular item on this list, I would like to comment on last one, component, mentorship and communities. Yeah. This company had a lot of code, a lot of components. This is like a document management system, digital signatures, etc, complex domain. And of course, over the course of the years, the company is like more than 10 years old, they had a lot of legacy code. Like we all have. So how do you open up this code now to everybody? Well, you don't do this overnight, right? What you do, you look at your components, maybe equal to repositories, right? And you try to classify them. Ha, okay, this component is in a good shape. It has a decent code coverage, a test coverage. It's already has automation, deployment, pipelines. So and it's not a critical. It's not a mission critical component. So we can give it away to all the teams. And if somebody breaks something, well, there's a CI running and stuff, right? And maybe there are five more components like this that we can give away to everybody on the first day. So private code ownership and shared code ownership are not just two options. There are many steps in between, right? Some things you can open and give away. Some things you're like, hm, no, this is very core part of our product. Only one team knows it. And now you have an option. So we are giving you options, right? One option is let them own it forever. Let call them. automation deployment pipeline. So, and it's not a critical. It's not a mission critical component. So we can give it away to all the teams.
[00:41:45] And if somebody breaks something, well, there's a CI running and stuff, right? And maybe there are five more components like this. that we can give away to everybody on the first day. So private code ownership and shared code ownership are not just two options. There are many steps in between, right? Some things you can open and give away. Some things you're like, hmm, no, this is a very core part of our product. Only one team knows it. And now you have an option. So we are giving you options, right? One option is, let them own it forever. Let's call them what what do they call them in team topologies? Complex subsystem team. If you have a complex subsystem, you have a complex subsystem team. If you have a complex subsystem team, you have a complex subsystem. It's like they're married forever. Unless the mission of this team is to refactor, improve, attest, and at some point, give it away to other teams. So this component mentorship community is the idea where you identify those difficult components and you have a road map for each component.
[00:42:56] Like maybe you attach a team to it to work on it, or maybe you pull people from different teams or maybe people volunteer come from different teams, which is even cooler, and work as a temporary team to improve code, and then they go back to their teams. But now those teams have knowledge about these components. So you can do it gradually. Right? You don't need to decide public code ownership or shared. No.
[00:43:18] Transformation in reality is messy. And it looks always great afterwards on conferences like these to show mappings and it was all brilliant and nice and clean, but reality is, of course, messy. One last one maybe.
[00:43:32] Yeah, one last one. And before we go to the last one, which is super interesting, this one. You see these three kind of circles equal to departments. Well, at who will study topologies and the map, you will see two upper levels, B-level and C-level. So this is the difference. At a B-level organization, those walls between departments, they will be fixed. I'm in the team X and I'm in this department, I work on a B to B to B to C. You are in some other team with other teams together and you're working on B to B to B to C and we never change. And you have your fixed manager, etc.
[00:44:13] This will be a B-level company. The C-level company, which is a more fluid way, and that's what Panda Doc is doing. Teams stay midterm, midterm, not forever, midterm. attached to some big business objectives, which require them to work on B to B to B to C. But when that objective is done, or the team would like to learn something else, or maybe that area grows and this area shrinks because of business develops like this. This team will go and become a part of that department. So departments are not really departments, they're just areas of agreements and they are fluid. So this is a very different way of designing your organization.
[00:44:56] And the last example that we can discuss is Y soft.
[00:44:59] Yes, Y soft. Very, very interesting, revolutionary company. And again, we show one image, but there were multiple stages and you can find more details on our website on how they progressed. It's a large case study. Um, Ysoft had 14 teams, so it's a little bit smaller than the previous one. Um, but the funny thing is they or the good thing is they achieved to serve all the teams or let all the teams work in one same bounded context. So one sprint, if you want, that all the teams share. There's one one space for collaboration. And a couple of years ago, I don't know the exact year, was it 2022?
[00:45:35] Maybe they they went manager less. So they they've observed in earlier stages that actually having middle management was causing stopping them from growing further into becoming the cell, the one big cell organism that they are now. And they've decided to repurpose management. So there's job security but not role security and you can maybe do something else that's more valuable than managing things in our company. Some people did and some people left. I think there's an example of somebody who was happy to start coding again, you know? Yeah. You want to say something?
[00:46:12] Go.
[00:46:13] Sorry.
[00:46:13] I said, yeah, back to coding, back to coding.
[00:46:17] So there there's one product owner for the whole company, the CEO, okay, and he has two helpers, two people, two product managers that do more daily kind of work with the teams. The CEO that set strategy and puts bigger items on the on the on the road map, which is called a product backlog.
[00:46:35] Um, there was a point in time where they did a merger, so they took over a new company and the people of that new company needed to learn all the software that Ysoft is making. And uh, it was pretty fast actually because it took the five teams one month to be to get up to speed in the new code base. Sharing code makes stuff simpler because if I know that you're going to read my code, I will think twice about, you know, what I'm writing.
[00:47:01] Yeah, so and these are not fairy tales. These are googable talks, conferences, articles, you can all find them. So we are in a in a research of finding more companies like these. And if you're experiencing something similar in your company, please do find us, talk to us. We'd love to talk with you and learn more from you, right? And the idea of these companies, they are much more adaptive and resilient than any other company we know. The company in Ukraine, which we started our examples with, is still there, kicking the market even during the war, even after COVID. So these companies are not just funky, not just sharing code and learning, those companies have those things that we listed. They have really significant business implications like resilience, for example.
[00:47:50] Yeah. Because an example of um Flotech, if they need to address a new problem, all teams can work on anything. They're used to learning, so it's a matter of putting new items on the product backlog for them to start working on it. You don't need a reorganization if you really want to change direction as a company.
[00:48:08] Right. We are not really trying to rewrite Agile manifesto. We think we just need to help people read their that one a bit better than they are. But we've come up with this five principles that we've observed organization that create business oriented R&D follow. And I'd like to give you a minute just make pictures and uh read them for yourselves.
[00:48:52] Yeah, similar to what conference has on the front page, right? This a bit different. The just a quick comment on the item number four.
[00:49:02] From constant reorganization to adaptive org design. What's interesting in those companies
[00:49:08] is that when something changes on the market and they need to readjust the company strategy, like higher introduces new crazy thing on the market.
[00:49:19] Those companies don't need to reorganize themselves, they don't need to create new teams and new business unions and new backlogs and higher new product owners and do all this mass. They can just realign the order of your items on their backlog of your will or whatever technique they use to manage business priorities.
[00:49:39] And because the teams got used to learning and working on new things from time to time, the teams will start to learn this new things. We now have two minutes and we're really welcoming now your questions if you have them for us. Thank you so much. Don't applause yet. Don't applause yet. If you applause twice, it always goes awkward, so wait with that. We have a hand in the middle, lady in the blue.
[00:50:08] Yeah, thanks. I think we have time for only one questions. And there is just a coffee break afterwards. Yes, there's a coffee break afterwards.
[00:50:15] Okay. And where you will be discussing more local optimizations, right?
[00:50:20] And while the artificial intelligent created coffee is coming.
[00:50:26] The question.
[00:50:27] First of all, thanks a lot. It was absolutely amazing presentation. Very full of humor and creative and dynamic. Thank you very much.
[00:50:36] Now just a couple of words to Alexey. I am very happy to see you in Paris. We crossed paths in Kiev. I am very happy to see you here.
[00:50:46] I'm also Ukrainian.
[00:50:47] Nous parlons russe maintenant. Subtitles, please. Subtitles. Yes.
[00:50:52] And now let's go straightforward to the question. Uh, it would be curious to know what served you as an inspiration for your org topologies? I guess that systemic thinking for sure and what else?
[00:51:11] It's hard to say it better than what Craig Larman says. And we're trying to find our own. Thank you for the question and good to see you too. Larman says, I'm trying to reduce suffering in product development. That's what he says. We are a bit more optimistic. We would like to improve the lives of people in organizations, but not just by looking them and giving them one line of code, or by opening up this locked human potential. It's not just about making happy people, you can just give them drugs, right? For God's sake. Buy the drugs. You're going to be happy for a few minutes.
[00:51:51] It's okay, but it's not about being happy. It's about
[00:51:56] realizing the locked potential in the organizations, which eventually will make people more fulfilled. So we are seeing a lot of companies and a lot of companies are dysfunctional because every group of people is dysfunctional. So it's okay. But some companies really push, put people down, you know, like in the like on our picture, like underground or on the first level. And we believe human beings are human beings and they just can work on things they would like to work on, they can be more creative, they can be they should be free from these limitations of somebody believes, cognitive load will explode my head. I haven't seen a developer with like open head. Explode it.
[00:52:37] They learn, they suffer, but eventually, they think it was the right thing to do.
[00:52:45] So I would say human potential.
[00:52:47] Okay. To be more concrete, I think, um, I was really inspired when I saw Scrum and did my first Scrum teams, my Scrum master.
[00:52:58] Scrum.
[00:53:00] Scrum. And uh, later I discovered large scale Scrum with Bas Vaude and Craig Larman. That was very inspirational to take it a step further. Um, I also saw the decline in the enthusiasm of people doing Scrum and Agile. And I'm really, you know, it hurts me and I want to make sure that that changes. We all see that we just have to apply it differently.
[00:53:21] Yeah.
[00:53:23] It's my calling in life. Anybody else has a question for us?
[00:53:26] I guess unfortunately, I'm afraid we won't have any time. Um,
[00:53:31] All right.
[00:53:31] But if you guys are here,
[00:53:33] Now you can applause if you want. Thank you so much.
[00:53:40] Thank you so much for having us.

Transcript