Dedicated Teams, Autonomy and Effectiveness with Serge Beaumont

Hi everyone. My name is Patrick Akil and if you looking for dedicated teams, autonomous teams and Clarity in responsibilities than this episode is for you. Joining me today searchable, more. He's a principal Azure consultant over here, XC Bia and you'll recognize him from episode 2 way way back. I'll put all his links to socials in the description below, check him out. And with that being said, enjoy the episode. I went to one of these people

said that, how many, how many projects are you working on like 12 and they laughed at me said. Well 120. Yeah. And that was a consistent thing. So I started interviewing more and more people and they all had 20 projects now, the how that's insane. Yeah, it is but that's just the way it works because everybody because they didn't and that's really you could say a product owner problem at the higher level for instance, with the

three projects. Yeah. Higher level product ownership within say. Okay, we're going to do this one project now and the Other to have to wait, so that all of them are faster. But that does mean that you have to say to other stakeholders, whatever, like you're going to have to wait for a while and that which you see a lot is that then the management at that level doesn't have, the doesn't have the strength of character to say. Okay, we're going to do project.

Number one, we're not going to do project number 2 and 3 so the people pay the price. Yeah.

Is that is the thought process there that if they do all of the projects kind of similarly, that they're the value that they add would be. Turn. Because why would someone just initialize even three projects at the same time? When one is clearly more important or even if it's not more important you still would add value more. If you focus on one project, know what the problem that is that that it isn't clear.

Hmm the problem is one of those things is once you do start going into that other direction and saying let's just assume fixed the team. So let's see how much they're loaded. I've seen so many times that then even if it's just a stupid wall of stickies and you put it all the wall and show what then is that all of a sudden, even like one of the worst cases I had was like a team like very smart people like six people. Yeah.

Fully in like Excel country constantly collecting hours of people that were, they were writing doing a lot of complicated calculations reports and other kind of things. Yeah, and still, it wasn't clear, what the total load on the team's was well. So it's a very complicated puzzle to do. And then when we did the whole, okay, let's make some Fix teams. Let's see how far they are how far they can go. The team started projecting out how much they could do. And everybody said, well, yeah,

this is pretty clear. We won't make it this year with all the plans we had. Yeah. And it was sort of a sad moment for those six because they were like, why are we even here, right? And so, and so we are, that's, that's a part, of course we won. We had to explain like, you're basically Trying to make a fundamentally difficult puzzle. You're trying to do that. You're trying to calculate progress based on simple fact of I'm doing an activity. Yeah. Right. It's just like you know like a

natural. If you save like in the definition of done I have tested a great. You've done the activity of testing. Does that prove anything? Nah was the test successful. Is it actually? So it's kind of similar to that. So simply the fact that you're that you're describing the fact order, you're right? Writing down your hours. I did an activity. I burned hours. You have no sense of if that was actual progress.

Exactly. And so, and that's also actually with my current customer, the exactly the same thing. All their data is all ours burned actually. See, people did stuff. Yeah. Well and then you ask the question, but do are you having progress? Well, that's sort of an indirect measure, right? You're assuming that if you spent 80 of your burned, 80 hours on a project that you had 80 hours of pro, Kress that's rarely the case.

Yeah. So that's also why it turns out that sort of the agile way of looking at it? Because, well, we don't care how many hours you burned. What was the actual progress? Exactly. Since that's the only thing and the actual empirical proof of seeing like a version of a product or something like that that it's surprisingly powerful. Hmm. And so that's also one of the things we have to teach them. So sometimes it's even the case that yeah.

Sure. It's a lot more complicated than sort of intellectually cooler thing to do, all the existing stuff they have because they're often are more complicated calculations and data. Yeah and then we come in with this very dumb idea. Exactly. Five. Just just show the thing. Yeah. And everything is ever is discounted into that and they go like, it's that simple. Yeah. It's that simple. It can't be that simple easy. Actually, that's crazy.

Yeah, and so yeah, that's that's what I think, organizations of that. Get used to. Yeah, interesting but I mean I've been in teams where first

of all my time is split during meetings and I don't even know if I need to be here. I would ask myself like, do I really need to be here regardless of if the meeting is effective or not effective, right? It's just about the topic and my role within that team, but if someone is in that team, how do you get out of that team? And really just focus on the core of what you are. Therefore, in a team. Can you do that from within the team or does someone from outside of the team?

Really needs to help in that aspect? In my experience. And this goes to again, what we're sitting here for work. Actually, you know what, makes an effective team, right? Yeah. One of those core things is In essence, the team is a team by grace of a common goal. Hmm, that's one of the big ones. So you're saying like, what is my how do I know my personal contribution to the team? Well, I'd say that is Irrelevant or not. Irrelevant it is. It's only of a second-order important.

Yeah. To what, what does the whole team needs to do because everything you need to do? You should be able to ask yourself. Does it matter what I do? I could be doing anything like week, getting coffee. I could be no making flipping burgers for my team or doesn't matter as long as if I know what the team's goals are. Hmm, does it contribute to death? Yeah, so that is the more important thing. And so one of the things I've been doing nowadays and I've been really looking into so

chakra. See nowadays, one of the things that is in sir chakra see because we're all equal together. Yeah. And so how do we make sure that we sort of make agreements on who does what without somebody being the boss. So the nice thing of, of their Force our chakra see is that it's it has more tools to make those agreements and make them explicitly. Yeah, and one of them is domain

definitions. I didn't I use social currency 3.0 and so it's shortened to S3. They always call it as 30k and in S 3, there is a think of the delegation canvas and it basically describes okay. For if you have a group or a role or whatever it may be, what is its purpose? What is this core purpose? What are those responsibilities? If it would be sort of delivering products of any kind? What are they? And so you clearly Define what those boundaries are, who are you?

And who are you not? And when the whole team MCS that you see? Uh so this is what we together are responsible for. Let's say, you know, maybe there are pmo team and they're responsible for providing a report to the executives, so they know who the beneficiaries are, they need to know what their what their exact their beneficiaries are trying to achieve. So there are goals then they hang out there on purpose.

Like our purpose is to make sure that our execs can make decisions or something like that. Yeah, that's our core purpose. Okay. Therefore what are your responsibilities that all time? Certain information is available Or something to that effect, you can write that down and the products, maybe, you know, we provide our PR execs with this in this, in this, in this report. So the people aligned on that

when they, when they have those discussions on purpose and responsibilities, while the fun thing is that The canvas is actually the tool with which you do the discussion. Mmm. So it's very often it's a delegation that is also right called the delegation campus,

right? So normally, if we're still in hierarchical organization or you see, sort of the outside circle like in the overall organization, then hands a smaller group power, maybe with a, with another example, let's say we are together in a larger group. We're friends. We are all equal and we're in a group of like, ten people. Yeah. And we all agree sort of together, somehow we come with the idea. Let's let's, let's have a night

out together. And then and then we all know that if all of the ten of us are going to organize that, you know, it wouldn't have anywhere else not going to work. So, so then the whole group, basically, look at each other and go, like, Patrick, you're good at organizing stuff, why don't you do it? So, we're okay, if, if you, if you organize the venue where we're going to eat, what we're going to do, but I think it's good, that's what we think it's good. If all of us agree on the price

first. So you know you talk with each other. Let's say, okay. Two Euros. That's the maximum budget. We have now. All of a sudden, some things magic happens, sort of in that social graphic method. The group together, we were sort of the people in power together. Yeah. And we handed you some power. So we magically agreed upon the fact that you have a constraint

of 50 euros, per person. Yeah, we have given you the power to decide and saying your responsibility but also therefore sort of a power that we hand over to you because we chose to do so is you are out you two, The venue, you choose

the restaurant stuff like that. Yeah so it's not so much about sort of who has the power, but that ability to basically hand it over to somebody as a group and say here, it's yours now because now you are God emperor of the meat of that of that party because we but we chose to do so. So it's not the case that in these systems that there is no person who has final power over something. It's, how did we come to the distribution of it?

And so those canvases basically do the same thing a manager comes in or group comes in or whatever they have this sort of they hold a big pie of power of decision, power of responsibilities, whatever it may be and then you negotiate with each other. Is this a responsibility or not? Are we allowed to do this or not? Is this a thing? We're going to be doing for you or not and then you gain a lot of clarity. And with the nice thing is that the team then knows, okay?

This is who we are. This is who we are not. Yeah, let's say they are responsible for, for instance, create a pmo group. We create that report that's us. It also means that we for instance, how get to decide what the final structure of the report is but we are accountable to our beneficiaries the execs. So it we're doing it for them so they should be happy about it and so but for instance, the tooling like let's say who chooses that. Yeah, right. So it could very well be that

you explicitly State? Well, as a pmo group, you are allowed to choose your own tooling but It must fit within the infrastructure and it should be able to host the ball within the infrastructure of our company. Yeah so for instance it must you must be able to run it on Azure or something like that, right? So and that's I think where this magic tends to happen is that you very, very rarely.

Actually I found that teams are completely clear about what that boundary is, who are legion. Yeah. What systems do we own? What are we allowed to say yes or no? Do we overlap With another team with respect to responsibility. Yeah, even if that's the case, right? It can still be explicit choice but then you can say well, okay good, that we know it because every time we make that type of decision, we better communicate

with the other team. Interesting and so I think I fully believe in I've done it many times once. You have those things negotiated, and maybe another example with with another customer, I had the manager of the design Department had. They wanted to restructure themselves Elves in a different way according to sort of, like I have a very high level, sort of a process of making sort of the

high level designs. There was a group that was much more geared towards taking those overall designs and customizing them, but also executing on them as they were building things. Yeah. And another group that was fear very much around General standards, but also okay, it's nice that you have a design because it actually was it designed for for hotel rooms and things like that. Where do you get? You know, if you're going to build hotels across the world, where do you going to get your

toilets? Yes. For instance, I mean, it's nice that you have a design for it, which is, generic across the whole brand. But, you know, we probably can't get the same toilets in Europe as in United States. So that's what we did. So what the manager then did, she agreed and we had a clear discussion around? What does the whole department do? Yes, the whole departments responsibility. So we had a canvas for that. And then the subgroups they each had at their leader.

So first, we made some drafts with the leader about sort of what their responsibilities were, how they did, they fit within the hole and then we brought in everybody else and there are some very interesting discussions so the whole groups are the sub 3 sub departments could look at the list of responsibilities for the whole department and saying are we covering everything? Yeah, so one of the things they

found was how you wait a minute. There's a responsibility up there for a department that nobody's covering. So those were things, they found another thing they found was that our wait a minute, there's overlap or there were gaps things like But also hey wait a minute. If we are going to be executing on the responsibilities, as one of those sub teams, we need you guys. So we'd like you guys to take on the responsibility to make sure you always have this type of information available to us.

Yeah, exactly. Then handed to us. So by the time that whole negotiation was done, literally every team member said, I'm so happy, I know who I am now. Hmm, I know where I'm part of. I'm very clear on what my team needs to do and then you can trust. Just because that's basically all the things we've been doing with agile teams all over the place through things like, daily stand-ups, and other Mick techniques, at your your backlog items, they'll figure it out. Yeah.

What do I need to do today, to get to the team's goals and to achieve the team's responsibility, exactly. I mean it's Clarity on an organizational level or a unit level, however, you may see it, anything right? Even on the the team levels that are below that, that contribute to that common goal there, that's incredible.

And I use it at every level. So if if it, if it's really needed, I rarely use it at the personal level because it's You don't really need it. And I'll see you want to avoid it a bit because otherwise people sit in their activity boxes, right? I'm a tester, I'm only going to do this thing. Yeah, it's like that. So you want to avoid that. But definitely, if you have teams of teams, of teams of teams, of teams of teams, kind of that sort of a hierarchical structure, nested structure of

teams. Yeah, you can use it at any level so you can use that A Team level, the team of teams level and if the teams of teams is part of a department, then the department. And it's been a very powerful tool I'm really like it. What if the people in those

teams say? Well, I know now with the team responsibilities are, but I've always actually had a different set of responsibilities. Probably, they went out of the way to gain those responsibilities because they probably wanted to be in that other team. That's I haven't actually encountered that very much like people, having fought for certain responsibility. I think what people want the most is to be useful to be effective and to have sort of an impact on the world. Yeah. The specific.

These that come with it then not to be as important that that okay? What I do find it's also why connected to that delegation canvas. I have a whole thing that they call a sentence ization cameras where you basically go through the whole process.

And indeed one of the things you find in this one of the things we we go through is then once you have done that at every team member basically figures out, okay, you know first of course are we really on the team or I might just a stakeholder or just somebody who provide some information. So when this Clarity okay this is really the Courting.

Yeah what's the Border then we ask every single team member given that you know here on this canvas disorder all the responsibilities of the team and you have a whole bunch of things to do. Okay, what other things do you have? That you are responsible for or somehow are expected to do any way, shape, or form. Yeah, that is not on that list. Probably like a whole slew. Yeah, it really depends. Some people have nothing. Some people have a whole bunch of things, but they all write it

down. So that you basically make a sort of a matrix of you write down pero like a person puts their name up and then they write down your just to put stick. He's like yeah, this is all my responsibilities. And then you get a pretty clear picture on truly how dedicated that team can be. And then we go through another process. Because, of course, it is very unprofessional to just drop everything exactly like, no not doing that anymore, go by.

So yeah, that responsibility has to land somewhere. So then we plan it out and basically say, okay this responsibility. So you're actually also responsible for the other report or you should be vetted other meeting and then there's a whole discussion like should that does it make sense for that responsibility to actually be adopted by the team? I could be one option, right? Yeah, then you continue doing it but very often, it's more like no. Wait a minute.

That responsibility you're doing right now, actually belongs to another team. Again, that's where the clarity comes in, because then they clearly see, hey, wait a minute. What I'm doing here is actually now that team's responsibility. So let's have a negotiation over and then it could be just a straight hand over. But sometimes I've seen it all.

So often is with a hand over with sort of an apprenticeship so that you put on your both of the team's backlogs, you put sort of a Apprenticeship backlog items. Yeah, we're one team member hands it over to another team member, so that's another variant. I've also seen variants where the conclusion is, it does not belong to our team but to hand it over would be much more work than the remaining work of. You know, what still needs to be done finishing, you know, finishing it.

Let's just finish it. So, sort of a short-term adoption and we know it's not really our work, but, you know, we do it. We finish it and then it's gone forever. Yeah, so that's also very interesting and finally sort of the defer or kill because it's like well, you know, We don't actually, when we think about it, it actually doesn't make sense that we're doing it at all. So let's just not do it anymore.

And so that's also what I use that, what I didn't call the sanitization canvas for and then we sort of plan out basically, how do we do the whole end over and then you start really cleaning up the work of all the people and handing over responsibilities that they shouldn't be having.

So that the team in the end can be at least for any team you want to function, you wanted them to be sort of dedicated towards that goals and It is of the team for at least 80% 90% because otherwise you're so distracted.

Yeah just doesn't work. That's the importance. But I think people will then realize if this is the team for them because if I look at my own journey, I would be in a team and I will be like oh that team is doing real cool stuff. I will go to my manager and be like can I help them? Can I like game responsibilities in that team?

And that's probably how I would get so many like different team aspects on my plate that I would feel responsible for but that is a result of being like, Proactive or entrepreneur. However, You want to call it and I can see them from a delegation point of view. Like if you have team leads or even managers and people come up to you and want to help, it's easy to then distribute that work.

Also cross team. But then you get the like, bunched up mess and it's not, it's not really clear anymore who's responsible for what even on the team level. Is everyone's kind of doing everything, and if everyone's doing everything, then it nothing's getting done in a good manner, I think. Yeah. So I think we're not based on what you're saying.

Like, you know, friends, you said, Personally, step up and I personally get this one of the things that's also very important in this way of thinking, is that, there is a very weak. That's actually a term I took from holacracy, which is one of those variants in the sort of the social critic method. Yeah. Is they call it role versus soul and everything. We were just discussing about the responsibilities that they're all hats. They're never connected to

people. Yeah. So all the all the discussions that you have around, okay. Here's a set of responsibilities and that we call that a domain, right? It's just a set of stuff. Your is a combination, sort of a package. Yeah. Like what's abilities and not that planning with more like it's just a package of power. Yeah. Or a package of responsibilities and it comes with a whole election but you connected to

something. Now we are, we tend to connect it to a person and saying here, that's yours and it becomes your job function and then if you go to HR and you change your job function, but that's a much too strict connection. One of the things we want to do in this kind of system, just like a scrum Master role and a product on a roll, right? Specifically or it should not be specifically attached to a person. Actually, it's one of the

mistakes. I also go against the lat is that also, the product owner role is a role if you implement it. Yes, there is one person who needs to have the final say over the ordering, but I've had many implementations where the actual implementation of the product on a roll was a political heavyweight. Hmm. Say hello to say no a lot. Yeah, a ux person because the whole thing was, so, ux heavy, you needed the expertise to actually sort of figure out, like, where do we want to go with?

Respect to the X and somebody was very heavy in information analysis, for instance. Yeah. - yeah, like it be a person. Like the three of them were needed to actually make the product owner all work. Well, then you have three people sharing and working on the has the role didn't change. Yeah, well, it's enrolled in

fundamentally change. So the same thing with these things is that It's not like, if you do renegotiation of roles, you're basically attaching, you're basically putting a lot of hats on the table and saying, oh, and essentially, if you would bake, it make it a visual, you would have a bunch of hats and you have a bunch of responsibilities and you write down a responsibility and a sticky and you move it from one

hand to the next. Yeah, that doesn't mean you got the responsibility that had got the responsibility. Exactly. And you're only taking on the mantle of those responsibilities when you put on the Hat. But that didn't doesn't mean it's your job function because maybe two months later, it turns out that, you know, maybe you're going on a long holiday and it's better if I take over your work yeah. Then I put on the hat it didn't change my job function. Exactly.

Jake I took on the mantle of the responsibility for a while and so when we're talking about governance in that sense, that's where we're talking about, governance is just talking about hats all the time and what are the responsibilities and essentially, the team hats are very big hat. They're so big that you need like, Seven people to actually, you know, make sure everything happens. And if you have a whole department that hat is so big, you need multiple teams to implement it.

Yeah, but they're still hats. There's just responsibilities Etc. So when people talk about taking responsibilities or moving it, In this type of conversation. It's always not me. Taking responsibility. It's the wider discussion of I'm wearing a hat right now. Yeah. Should my hat. Have the responsibility and then later, if I ever take the hat off, and give it back to you, it comes with a detached responsibility. It never was attached to me,

interesting. But then people people always glue like responsibility and accountability closely together, but I can still be accountable if I delegate the responsibility of doing something else. That's also interesting discussion because also in, The use of the word, responsibility and accountability. Yeah, the word gets flipped a lot. Yeah. So let's just I'm choosing one of the definitions that I like a lot and I also took it a bit for mystery.

So a responsibility is the fundamental nature of a thing needs to be done. Yeah, the act of doing something. The Hat has a responsibility to it. Let's say, you know there's a hat that says your product p.m. oh yeah, half. And that pmo hat is responsible for providing a report to an exact Sure. So that's responsible to it. It becomes an accountability when you put on the hat. So now I'm choosing to be accountable for that responsibility. I'm wearing.

Yeah, so that's the difference. So responsibility is a bit more neutral, it just is. And the accountability is the act on taking on the responsibilities and saying, okay I'm going to do it now. I'm promising to fulfill this hat in the correct fashion. Now what the problem is, I've also heard people use the same two words in exactly the

opposite direction. So it sometimes gets confusing, you do have to watch out when people talk about responsibility and accountability which version of it, are they using exactly? But I do think the distinction is important. So a responsibility at least in the way I use the definition yeah is talking about the hats and we're moving stuff around and it's just the definition and indeed the moment you put it on, you're basically telling the rest of the organization.

I'm going to do my best to make all this happen. Yeah you can be held accountable to it then you can be held accountable. To it. Yeah. But only until you wearing that because the moments I give the hat to you. Now, you're accountable. Welcome. So that's the difference. But when you're not, when you're

in a team like we just covered a whole big part of dedication dedication. Is like, something that would be a responsibility of the team, right? Like a shared responsibility. Who can then be held accountable for that? Like that's kind of a hard thing because if everyone does is everyone then accountable or is it only you when you put on the hat? Like, here's an interesting mix of be. History may be. Why does scrum only have three rolls? Yeah, it's an explicit Choice.

Hmm, there has been research done way back when with James Copeland who is also famous from C++ and he wrote a little many books. Yeah. And there was a thing called The Bell Labs Pastor project, so James could be in also did a lot of research on what types of organizations make for better organizations. How do they work? You know, what are factors that do that? One of the things they I found that one of the most well and and again to add to that story.

So they looked at many projects and they sort of made a curve and did correlations on which aspects are better or sort of predictive of their performance. And one of the projects that was at that time like super performance of like a very much an outlier was the Borland, Quattro pro project. So basically when Borland was making their version of Excel and it was like when they research that project it was like out. Forming everything with a factor of 20. It was like insane.

Ridiculous, it was ridiculously much faster or even worse. Like something like 50 or 200. It was compared to like all a lot of research. They did with teams, like, teams that were working at Microsoft at the time and, you know mature, but you know, why were those people so fast? Yeah. It turned out that communication saturation was the big factor and communication saturation for us Geeks is to what extent? Do you look like the Borg.

So, how much does Remind know everything of every other mind. So now the saturation of all the information through the whole team. Yeah, so if you have like one bit of knowledge that is just with me and a bit of knowledge is just with you, then our communication saturation, goes down. If we both know everything of each other, then you know, we have maximum communication saturation, then, they researched.

What's the most defining factor for the communication saturation that turned out, to be the number of roles, mmm. So the more roles Define, let's say you have a team of eight people and eight. People have a very defined role and I were talking accountability responsibility. Everybody has their separated. In that eight wheels. Then you get that whole problem of saying, oh, I'm just a tester. I did my testing job, I'm the programmer. I did my programming job.

But also, what you also see? Because the tester does, all the testing work, that person is the only person who knows what's current status of testing, Etc. So you've just partitioned your whole team in little little activity boxes. Separates out. Yeah. So to come back to scrum now. This is the reason why we only

have three rules in scrum. This is the reason why we only have one developer role because they discussed can Schreiber and Joseline did discuss it and they said we should we have like a designer role should we have? And they explicitly said, no because you don't want people to fall into that comfort zone of saying, this is my little activity box. So there has been in the agile way of thinking, a very explicit choice to not partition everything to roll.

Yeah, do not give you that comfort of saying. Oh this is my little, I'm just a tester, I did my thing so that the whole team can be held accountable together and you never can hide behind the fact. Oh, but I did this little corner piece. Yeah. So it's an explicit Choice. Does it lead to a bit more chaos? Does it lead to be to a bit more? I we need to figure out for ourselves. How do we work together? Yes. And that is why I have a daily

stand-up. That is why we have all these mechanisms in place to make sure that as a good as possible. We Each you could say the potential chaos of nobody knowing what to do. Yeah. Or everybody doing our thing or doing the same thing or duplicating efforts. Yeah, that's why the stand-up exists. Exactly.

You want to make sure that there's a shared mental model that is completely shared across the members of the team. Exactly. And if you do your thing, and I do my thing, then it's never going to be shared, mental model, and if you would be in an organization or a team that is completely partitioned through little activity boxes and little hats. Yeah, you don't need to stand up now because everybody Directed by the little activity box and no one cares about the other person.

Exactly. So here, you see the luck. If you know baby with this bit of History That explicit choice to not have any defined roles with respect to a team means that you also get a more fluid team. You get a team that doesn't hide behind their. Okay Mike I'm a tester or I'm especially in my case I was a developer all the time. Yeah but what if like 90% of the work was testing and then just watch the test or test and sweat, right? That makes no sense.

Whether He's an active. So every person should be a skill injection into the team. That doesn't mean you're automatically comes with all kinds of accountabilities. So, yeah, I mean, and there is a problem, conduit, right? I mean, if people indeed do not know what to do and just like you, I think what you're alluding to is, if everybody is responsible for thing, nobody is responsible for thing, right? Yeah. And that's where you get some sort of the practicalities of what you see.

Most teams do is sort of have one person. Be served the champion over your story, right? The simply somebody attached to it and they just make sure that everybody else is aligned on that specific user story. Yeah, but that is also leadership that is fluid and flexible. It doesn't mean that one person, the boss person or, you know, God forbid. The scrum Master is the boss of the execution of all those of, all those user stories and then starts dictating everybody.

Yeah, that wouldn't work. Now, comes from the group. Exactly. Like the example, you gave where I would be held, responsible for figuring out the The date for the restaurant. Yeah. For instance. So that's handing over and the negotiation of who does what? Etcetera that sort of the. And, and, of course, that's also why we have a limit to the team

size. Yeah, it is literally nothing other than the Human Condition if we, as humans were so good at communicating with each other, that in the function of a team, we sort of had the power of communication to have the same style of deep communication with 15 people as we could have with five. Then human team sizes would be 15. Exactly. So all our team sizes are limited by literally nothing other than our ability to have a high communication saturation with it. The maximum number of people

that allows us to do that. Yeah. Which tends to be in at 6:55 area. Exactly. I was exactly going to ask that

because sometimes I feel like I am in a team. And right now, I'm in a bigger team. I've never been in a team. This big. I'm like, man, we have so much communication feels like overhead In trying to align this mental model. And it's right now, it's still very in cause we're very new and early as a team, but it takes so much extra effort.

It feels like, because we are of this size when it comes to Communication. In a lining, people like all sometimes we say, okay, we just have to document better. We have to align more. We have to communicate better in in my head, that is only a result because we are of this size that we have to do these. You might had extra things because if we were with a smaller team, then that communication overhead would not be. Any overhead anymore because it's easier to align that what

you're doing, then as a team. And but what is the specific size that you're in? Then, right now, I'm it like eight. I would say eight. Yeah, which is at the higher end, but I think generally, I mean, it gets really painful I've seen when you get around like, especially, like the 12. Yeah, very in there. Yeah, I think I've even had a team where it was first time at a stand-up and there were 24 people. Yeah, that is incredible. Where was I?

You don't know how fast I part. I sub partition them. Yeah, so because of that trick, well, maybe just one step back. It also is a function of how well, these people know each other and say, those eight people have been working together for a year. Yeah. Together. So they really know each other very well. So you also see and that's also why I'm not so sort of religious on a specific number. Yeah, I always look at that ability of a team to really

swarm together. So I've because I've seen teams of 10 work. Yeah. Why? Well because those people have been working together for two years knew each. Other in and out and could almost communicate without speaking, because they knew each other's mind so well, yeah. Then you can scale up larger. It had the history of those two years. Yeah, yeah. So that's an even. Then what you do, see the moment you get to the larger team sizes. You'd still see sort of sub partitioning happen and to and

this is a bit of politics. I've done it specifically at One customer where I had a team of 24 people to to, to work with. Yeah. And then so I didn't call them teams, I called them cells. So officially for the managers in the outside it was a team of 24 people and I said, I don't know. There's no, they're not teams their cells. Okay. So the team was and of course, the teams. Yeah. I was like that.

Yeah. This was just a nomenclature, but I found it helpful because then there are sort of a Isaiah. The prophet perception that they're sort of a light weights are petitioning the other really a team, but they did allow us to make a just a little sort of team of teams structure, the internal. Eames just had to be a, a business analyst as their quote, unquote product owner.

Yeah. But that was mostly for clarity doing product owner work, so the backlog work that was necessary for that little sub partitioning. And then the real overall product owner really was the person who saying okay first is stand, that and cetera et cetera. So that is a trick you may or may not choose if you want to, let's say those eight and I tend

to look at autonomy a lot. That's my big. If I do anything with any teams or structuring organizations, Large and small. It's always around autonomy. Yeah, because that is the most defining factor in lowering the complexity of your organization for anybody, who's a programmer, you know this, right? Yeah. Modularization keeping the complexity of your code low. Yeah. Fun fact. In human systems is Works, literally exactly the same way.

I've been a software architect for my big chunk of my career. I've been literally using all my software architecture skills. Knowledge about partitioning software into human systems. Love that. Yeah, Isn't that cool? They're so if you're a good programmer and you know, how to modularize your system, why High cohesion loose coupling right?

Yeah, that's exactly it. So what you want, if you look as ass like a software sort of architect or at your software system and you look at the same way as a human system. Yes. You want that same level of modularization and autonomy so that you don't have all these links. You don't have the spaghetti code like with with dependencies left and right. That's what makes We're human systems are complicated, so and so to come back to the sub partitioning.

So when I look at some partitioning, I always find the one that gives you the most of Ptolemy. So if you would be sort of you if you have a software monolith. Yeah and you want to say well I want to make two modules out of it. Then you think by yourself which of those the sub partitioning would make those two modules, the most autonomous, the most modular. And that's the partitioning you take is they're always like a

clear partitioning that you can use like what if those two? Only four people are just kind of doing the same thing in a Cell. Well then, then there was less of an issue if they truly are doing the same thing because they truly have the same goal should have what? I then can see what you can do is stand still. Do is to support ition them is sort of like, you know, sub-team one sub team to like red team blue team or whatever. Just give them a name. Yeah.

And so they can do the exactly the same thing but just with a smaller group of people. Yeah. Without any other petitioning, you can still do that and then it's short of random as long as you sort of. Make sure that all the Skill sets are covered. Yeah, that's that's what you need to do. I found that as far as if I look at autonomy, there's three things that I always look at first is functional autonomy. Yeah. So let's say there's two connected business, processes like mortgages.

It's actually example that actually owed. This is the example of that team of Twitter. Yeah, so where you have the process of getting to a mortgage is a We fundamentally separated one from the moment. You have your mortgage and sort of all the updates and upkeep that goes with it as you have it. Like there are two very different things, right? They want your thoughts your house.

There's a lot of work that goes into, actually, you know, getting the agreement, getting a contract, getting your money, all that kind of thing until you have the market, but then you're sort of it sort of stable, right? Yeah. All you need to do is some interest updates or things like that. So also the company was essentially partitioned into these two different pieces, but this team that I had was mostly about it. Forcing the reporting had to do

across the whole company. But since the business processes were so distinct. We some partition two of the teams to be one for this process, and one for that process, which may total sense. Because the reports that they made were completely separated from each other. They had nothing to do with each other. So that's functional autonomy. The second one is technical autonomy. So, to what extent do you have

your own technical stack? Yeah. And then, of course, it's nice if you have your own thing. So you know, if you have You can you run your own cloud instance? Yeah. That would be one form of autonomy. Or are you using shared libraries? Are you working on the same infrastructure, things like that? So the more in the more autonomous, you can get that the better. It's always not optimal or her new. Can you do not fully do it. But you know how close you're close.

Can you get it? That's one and the final one is what I say personal autonomy. Do we have all the skill sets we need and so there you get into trouble where there's this one person. Listen with the only one who has the knowledge about this P field of knowledge, or this technical thing. Yeah. And then you have to share them across teams and those are the people you need to figure out, you know, how do we share them? How do we, how do you make that scale?

How do we make sure that, for instance, this people, this person is in this team but then perhaps parentheses, you know, somebody else. Yeah, things like that. But those are the three things I look for. So functional, autonomy. Technical autonomy, personal autonomy, and that's then how I make my choices, interesting.

I've seen, technical autonomy, probably a lot also. No. But technical autonomy also gone wrong. All right there's where there's a responsibility and another responsibility but there's so much coupling in between that all of a sudden there's communication overhead there and then the end result is almost exactly the same as if you would have it in the same team except that team would then be autonomous completely. So the best you can hope for is to maximize it. Yeah. Right.

So to let's say if the there's there's a lot of luxury sheets. Technical debt in a sense, right? And sure but you still are able to achieve okay, we're still on the same. That form but we at least we have functional autonomy. Yeah. That's better than not having that. Yeah. So you just impractical fact, you'll never get there 100%. You get as close as you can get and then sort of you continue further building it out.

I was also 2012 in 2013. I was at TomTom and it was interesting that they had component teams there for the whole navigation core. Yeah. And normally we also know, effective teams are over component, times are bad should be feature teams of blah blah. But they're specifically there when I discussed it with the Architects. And also, with the leader for the navigation core. I said, this is actually a good idea. Why?

Because just because the way they had built it out because, you know, at that time, they did a massive effort etcetera and just through history and Legacy, it became a big monolith, you know, just like with any other software, this can happen for all kinds of reasons, but they were doing a massive effort to decouple. Everything to take all those modules and pull them apart. Now, the interesting thing is, All those component teams were essentially very nicely mapped

onto the modules, you'd like. Yeah. And so, there was also a natural tendency for all those teams to start to pull their own code out of the monolith. So if we would have had feature teams with that process have been a strong. Yeah, I I think not. So would I advise them is a, keep it like this up until you think the the course fully partitioned, and then only start thinking about component teams because there was a I'll drive for all of those teams. To achieve technical autonomy.

Yeah, that that's so interesting to me.

Because like if you would read online like what the best way to split the team is like obviously is context dependent, but what you might have might already be better than what is out there giving your set of circumstances and your own context, right? But then how do you know because it's really hard to compare the what if scenario versus the what you already have scenario, right? Again, you know, if you have software development, How do you know a module is autonomous is

modular. It's the loose coupling thing, right? Yeah it's high cohesion loose coupling it is literally not. Just look at your team's, do you see them being highly cohesive within the team? And do you see them have nicely loose, coupling with out with other teams? Yeah, that's what you're looking

for. So if you see two teams constantly need to communicate because there is some technical dependency in testing or the infrastructure, something's wrong, something's wrong or at least it's an impediment and you put stuff on the backlog and you Are fixing it right into to certain, you're maximizing the, the even more.

So that's also how I judge the choices to what extent just like you would have a software module and you constantly seeing connections going all over the place and it's tied like you know, if you look at your import statements yeah and you see like a gazillion Imports both ways you know sometimes what exactly it's really that it's like you know trying to for instance check make sure that you don't have circular dependencies but that also yes, What goes for human systems?

It's not that bad. I mean it's not like software in that sense but it has a similar feel to it like, you know, sort of how many import statements does one team have towards another team. Interesting, and that's what you try to avoid. I love that. So yeah, if you're a software guy, you know, how to view your, it's easy. Like, you're really pretty good. Actually, so easy, man. That's interesting.

Like, one of the final thoughts. I had in my head, we talked a lot about dedication or dedicated teams autonomous teams and even how you You could split the autonomy to where it makes sense, right High cohesion loose coupling.

Yeah. Have you had a set of circumstances where you created a dedicated team or dedicated organization or use the delegation canvas to do that in the sanitation, canvas to sanitize, all the responsibilities away TimeWise. And then throughout the years, reflected back on that to see if they stuck to that or if they've evolve that or if they've gone back to like old Behavior. I wish I'd known that for all the cases because this is of course the curse of being a consultant, right?

Very often You know, by the time the money is finished or everything is sort of going smoothly. Your job is done, you've moved on. Yeah. You've moved on and then you know how many times do you really have the time or do you take the time to really go to that old customer go and call them and you're like, oh yeah, how's it going? I would love to know. Yeah, so it's It's very, this is actually the something that has nothing to do with.

Actually, with you could say, the quote unquote, technical choices that were made with respect to structure and responsibilities. Yeah. This is only a question that I've only seen answered, like, do they fall back into Old Behavior or old structures or

does it go wrong? It's only leadership, it's only culture that's very literally, the only thing because any organization that does they're agile and maybe, you know, It might not go well for a while or they might fall to their knees or fall on their face, but any agile organization will then go, you know, something went wrong. You we started Retros improve it, it s back up and you'll fix it again.

So, the organizations that where you see really go, wrong was always the ones where let's say, there was a change of leadership that change of leadership didn't believe Angela anymore. They killed it. They killed it and then came up. Yeah, start from zero. Yeah, that's so sad. Dad. Yeah. And so but as far as an organization that does believe

in it, and one of the organization's, I know that sense the best is bolted. Calm when I was two together with two other Consultants, we were, we were involved in just changing the, IT department of that time into full scrum. That was 2009. Yeah. And And I've stuck with them for about one and a half years. So, one half year was like the initial transition. So that that time, they were eight teams and by now they're like 50, I mean, it's crazy. The scales like Beyond.

Yeah. So and and also, I stuck around, so the year afterwards because it was more of the portfolio, like the collaboration of teams kind of a thing. How do you scale that was sort of my first big assignment where I had to figure out like, how do how do I get eight teams to collaborate, right? So it wasn't really a very well-known thing. Nowadays, we have the Frameworks but the Frameworks is Exist at that time.

Yeah, we're sort of you. We sort of bootstrap it ourself and we came to a pretty close conclusions and it worked pretty well. But nowadays and I've spoken with some some of the people. I still have some contacts with every once in a while ball and they continued with their path. Mmm. But that was always because there was a full belief in, you know, this is the way to go. We should go and tell and they just continue doing it. Yeah. And they did. Do it perfectly of course. Not right.

They also told me, there were moments where they fell back and they were weird things happening or like, with any real organization. Nobody's perfect. But what is interesting is that they also did some amazing extra stuff, like they actually pulled in sort of social critic, ideas, things like electracy, and they made their own system. I believe the called spark where they said, well, all the agile

teams are working. It teams, they want to really work scrum etcetera, but we were sort of want a different feel for our more business-oriented teams, okay? And they then use that more search aquatic system to work with that. So they even evolved and changed it. Now that never could have happened if you would have had a management layer because that's still, I mean, that's the reality we live in, right? Yeah. It's still leaders who Indians say, this is the way we do things around here.

I mean, in the end that's just simply how our world works. So yeah, with that ever have happened, if there was a management change and they would say that, agile thing we don't think it's Listen, just kill the whole thing. It would have been killed. Yeah. So, and that's literally, you know, the only thing. And I've also heard that sometimes they, you know, they fell back to other things to had 20 struggles, things sort of went back, some steps and they went forward again.

But that's I think very normal for any organization. I mean even like you know with our organization here like it with the things he be all right? We will also have our moments that we do. Dumb shit and just, you know, things in the stupid, wake it back up. Yeah. It's also the power of our organization, right? The proactivity, the fact people just, you know, step forward and do the things that they need to do or, you know, have an opinion.

And it's not well because well, who are you, right? It's no doubt. The person with the opinion and if it's, if it's make sense. Is like a good idea. Let's do it. Yeah, it's interesting to me that it's an interesting perspective, right?

That the leadership Vision trickles down into the organization and then that is a way where it would fall back into Old Behavior or to just throw everything that you've built up in the Trash and start from scratch. Yeah, although there's three things again, I always three things, three things when I talk to leadership and what their response will, I collect top-level. Leadership, like executive leadership, what their

responsibilities are? I always say, essentially sort of product ownership at the highest level so a team is a team by grace of a common goal, right? Yeah. Well, that applies to the whole company, right? However, our is a team going to feel like they're cohesive and they belong together. If they don't have a shared goal together, So they're sort of product owners at the highest level, which then translates to strategy and mission and vision all that kind of stuff.

But that's really what they are. Scrum Master side. Same thing. They are the place where sort of the buck stops when there is an impediment, that maybe it takes like a fundamental restructuring of the HR House of job functions. Yeah. Well, you know, you'd have to be a pretty flat organization. If somebody just anywhere could say, let's restructure it. It tends to be the big boss who needs to say. Yes. So that's one of those other

things. There tend to be sort of the place where the buck stops with respect to the most high level impediments. But the third one and that's the one I want to talk about here, is I call them, I say, you're also the keepers of the culture which is very similar to Parenting in that sense. Let's say, you know, you have a kid and the kid, you know there's there's the cat and then the it's like a small baby and starts to pull on the tail of the cat. Yeah well this is also my

personal experience. What does your child do? They look up at you going like is this okay? This is smile gone. Is this okay? Yes or no? Do I use they want to see you laugh? Exactly. Because you are the reference for is this Behavior? Okay. They're looking for that. Okay. Is this a right or not? And in that sense this is where you see that's a very important. Like most of the time leadership doesn't even have to have a

vision. They just need to say sort of not and go. Yes this is the way we do things around here. Yeah. So then and they like to hear that I will.

So say you're the keepers of the culture. And the way things are done around here because that's, I think I like this very simple definition of culture culture is the way we do things around here but that's it right simply different issue of culture so if even if they don't know how to do Agile, for instance I tell leadership all you need to do is just not whenever I say that's agile. Yeah. And if they truly believe in it and trusted say yeah. Okay, I believe in the thing.

Don't know how it works. I don't even have a vision about it, but I do think it's important that trust that person to do it, then all they really need to go is go. Yes, that's the way. Things around here or when somebody else comes in and talk, after that, you'll thing is stupid and we need this reports and we need other the, and then it sort of, you know, it's it's completely different. It's conflicting and doesn't work very well.

That that leader then goes like, Oh No, but that's the way we do things around here now. Yeah, so go figure it out which is a fundamentally different message from? Well yeah, I don't know what it be or do you think? Yeah, exactly sort of or or yeah, that report is really

important. Well, maybe we should be, you know, doing our project tracking In based on hours because otherwise I don't know what my budgets are that I want to burn and so you know, that's a very fundamentally different thing. So I found that in all the cases when you know until they did or did not work in the end. Yeah. It was always a keeper of the culture thing, always, that's very powerful. Yeah, incredibly I've Loved this conversation so far shares year when it comes to Dedicated teams

and an autonomous teams as well. Your take on everything. Is there still something in there that you would like to add before we round off? So let's see, cuz of course I will. Yeah, right. If we had notes Here, I think we talked about dedication. We talked about common goal. That's on me, ecosystem. I think maybe two things that I one thing I would like to emphasize is that When you have about, we talk about effective

teams. Yeah, I fully believe that if you have a list of impediments of that team, why are they not functioning that 90 to 95 percent of that list is not the team itself. It's their ecosystem is the organization of society around them so many times.

I've been sent at the team going like they're a bunch of idiots, they're not functioning, go fix them and then it turns out that when you really start looking into it, oh wait a minute, the testing environment, never available, the requirements are never clear. Yeah, people people getting pulled in and out of the team by somewhere else. So there's this manager or the sales guy constantly coming in from the side and disrupting the the behavior tea, etc, etc. Everything around it. Yeah.

And then, I don't know how many times then also, you know, in the cases where it really works. I mean, of course, you know, you never guaranteed to have to success but where it really worked. That's then those managers would ask me like okay, you know how did you do that said, well nothing. I just make sure they could do their job. Yeah. Because the people never Any change?

They just, you know, they were sort of you just took away all the impediments because that's the fundamental sort of lean as a way of thinking people are fundamentally awesome. You just need to take away the impediments that prevent them from functioning. Yeah. And they did their thing. Yeah, so that's also one of the

things I think is important. Also again, that's also why it's so important for leadership thing, because so many times, the people in those teams don't have the Mandate in our still are hierarchical world to actually fix the things that need to be fixed. So that's also where it's

irresponsible. And the fifth thing I had we had on our list that we discussed also before is psychological

safety net. And that is also one of those ecosystems things because the reason you feel safe or not is a function of the culture, as function of the ecosystem, its function of leadership is the function of the behavior and also the example behavior of leaders or people you look up to or people who are your reference because let's say, you know, somebody is your boss and that's the person who in the end gives you your salary. Yeah. Their behavior will. Influence you.

Absolutely. I mean it well I mean you can't deny that. So I'd say sort of this combination of both looking at the ecosystem, but also making sure that the psychological safety is there. Because how otherwise will, you know, we were talking about, you know, this whole discussion earlier where we talking about sort of that, swarming effects and having a conversation of who does what? Yeah, how is that ever going to happen? If you're scared?

Yeah, it just want you not going to say anything. Yeah. So that's again, another quote.

I use a lot in my work. I also say fears the great killer. Hmm. So if people are afraid in a team or in an organization anywhere. Yeah, it's game over. Yeah, that's it. I'm just getting more. Because people will have very weird behavior and it's always

like. And I've also learned to recognize in this sense, especially if you're a bit less experienced and you have somebody you encounter and they have like, what you would call quote, unquote, insane Behavior sort of in a business context, right? Like why are you doing that? We can make no sense. There is always a reason underlying it. Yeah, that makes sense. And it's very often based in fear. Okay. So I'm like, I'm worried that my Up manager will kick my ass.

I was very worried that this this release will not go out the door and I'm so worried about it that I'm getting this control Behavior because the set of the way I deal with my own stress. Yeah. So maybe that's as far as a bit of advice is concerned. If you see that kind of thing happening, empathy is going to be your biggest weapon in that sense were your biggest Ally figuring out what's underlying that behavior, why are you doing that?

What are your goals? What are your fears and then speak to those because very often, you can then Fix the thing instead of just trying to fix the system and sort of going like go away. Go away. Kind of. Yeah, that won't work. Why are you constantly coming to me? Why are you constantly bothering me? Why are you so worried about this? Yeah and then having the conversation about the actual fear that they have and saying okay this is how I'm going to

redress your direct fear. That helps a lot. Yeah it takes the underlying pain, underlying pain away. Yeah and again a lot of my work tends to be sort of identifying

that and going like hey interesting so So if I always I've taught myself to never go like oh you know that they're that person is an idiot. Yeah. But you always have the response. How? Interesting I love that. I think I've taken I've taken note of that and I do that. That's how interesting. Yeah cool. We're going to round it off here everyone. Sergio boom! Oh, I'm going to put all his socials in the description below. Check him out. Let him know you came from our

show. And with that being said, thanks for listening. We'll see you in the next one.