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.