Jurgen Appelo - The Unfix Model

The Agile Toolkit.

Hi, I'm your host, Bob Payne, and I'm here with Juergen Apelow, starting the podcast

for the third time, I believe, and hopefully we won't have any technical difficulties this

time, but Juergen, I'm really interested in talking about your unfixed model and some

ideas that you have about organizational design and scaling and the patterns language that

you've developed in that model.

Yeah, great to be here, Bob.

Indeed, fingers crossed.

Hope we nail it this time.

So, yeah, I've been inspired by Agile scaling frameworks, which are, well, I have a love-hate

relationship, I always say, with scaling frameworks, and they are full of good practices, but at

the same time, I don't like the way those practices are packaged as things that we need

to implement and that we need to roll out in an organization.

I am a fan of pattern libraries, like team topologies, but also sociocracy and liberating

structures and so on.

They're collections of suggestions, options.

Everything is optional in a pattern language, and you have to build your own method or framework

from the available options.

And as I said, team topologies was one of the sources that I was inspired by because they

offer four patterns for team types, but there's also dynamic reteaming by Heidi Helfand and

Network Scale and Agile, another book that offers some structural patterns and more that

together, at some point, came together in my head and nudged me to start doing something

about organization design because I thought organization design, organizational structure

was underserved.

In the Agile community, the suggestions were rather naive and poor, in my opinion, usually

resulting in matrix structures, and I think we're losing you again.

I can actually hear you, so I think we're okay.

Okay.

All right.

Because you're frozen on my end.

I'm so sorry.

I'm going to go off video.

Yeah.

All right.

Thanks.

And from various sources of inspiration, I have started making the unfixed model.

Great.

And I know that in talking about this in other contexts that I've heard you speak, you talk

about this idea of a collection of Lego blocks, and that strikes me as a good analogy.

Yeah.

I think that the first thought when I saw the visuals for the framework was a bowl of

Skittles, and I'm not sure that that candy necessarily translates to your context, but

it is a very colorful mapping.

Yeah.

We would have M&Ms on this side of the pod, but very much the same thing indeed.

Yeah.

And yeah, the most important thing is that everything is optional.

Right.

Yeah.

So, of course, as in Lego, some blocks are more obvious than others.

There are a few types of blocks that you basically use nearly all the time, and some are quite

specialized.

It's actually interesting to know that Lego offers nearly 4,000 different types of Lego

blocks.

Oh, I didn't realize it was quite that large.

Exactly.

You're not the only one.

Most people don't even know that there are so many.

And that is interesting.

You know, to create more options, to offer people more possibilities to deal with all

kinds of things that they would like to build, you need a large box of options.

Of course, you do not use all those 4,000 blocks at the same time.

That makes no sense.

Actually, the fewer, the better.

That would be the art of making a nice Lego model to use as few pieces as possible out

of those wide variety.

And that satisfies the idea of what they call in systems thinking the law of requisite

variety, which some people say is the most important law for management.

That is that a system needs to have a sufficient variety on the inside to deal with all the

possible changes that happen in the world outside, because it needs to respond to an

ever-changing environment.

And the more options it has, the more variety.

The more, the longer it can survive in a changing environment.

And that, I think, is sort of the reason why I offer the unfixed model to help people

create network organizations that are able to survive in an ever-changing environment.

And that requires options and flexibility and versatility, as I sometimes say.

Yeah, I'm later today giving a talk on our webinar.

I'm at Lightspeed, and it is called Agile Evolution and the Selfish Meme.

And I sort of bring in this idea of creating variation and needing that variation to be

able to find situationally appropriate or situationally optimal strategies.

So I'm a really big, big fan of that.

And I always thought that...

Any of the scaling models, even the team models, for the most part, if just implemented

sort of, I don't know, implemented, we can just leave it at that, was potentially a problem

because you're not creating a situationally optimized situation.

And in lean thinking, they never would have looked for that perfect end solution.

It was always...

You know, better was a terrain that you navigate to try to find a slightly better

solution.

And that...

So I think you and I are fairly well aligned on that sort of philosophical foundation.

I think so, too.

And indeed, just staying with the systems thinking, complexity thinking background,

so we need to find the optimum in the fitness landscape.

And that requires us to change ourselves all the time.

And to, well, to prevent people from having to reinvent the wheel, I would like to offer

a set of patterns.

And that is what Christopher Alexander did a long time ago in his book, Pattern Language

in the 70s, Patterns for Cities.

He showed that every city basically has town squares and promenades.

And...

And other well-known solution, only every city has them in different combinations because

they all have different environments.

And that is a nice way of explaining what patterns are for.

Yeah.

It's interesting in the agile community, we have, you know, design thinking that came

out of this idea of a wicked problem, also from urban design space.

So...

Yeah.

So, what, where do you, what's, what's a particular pattern that you feel has been

really badly neglected in the agile space?

You probably, it's like asking which one of your children is the favorite, I know,

but...

Well, one of my favorites is about, you know, the, the, the, the, the, the, the, the, the,

the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the,

the experience of the, of the, the user of the customer that goes beyond the product

delivery that we usually focus on in the agile community.

And I, that's not my own insight.

I have that from one of the books where they say that agile transformations have often

resulted in islands of agility...

...various products and products that...

Sure.

correct areas that are optimized for their particular Island but customers are not interested

in individual products they're interested in an entire experience so for example um when I when

I make a transaction a financial transaction with with my bank I'm not interested in particularly

the app or the website or whatever the only thing that interests me is sending my money to someone

and for that I use a variety of products that the bank offers now I have experiences that are

sometimes uh quite horrific using these various apps from the bank because they do not offer a

holistic experience you can see that the different team creates the app and a different team makes

the website and so on things are poorly integrated individually the app is updated pretty often same

for the website

but I have literally been stuck a year ago uh between the app and the website when the app

required me to authenticate myself and change my password on the website and the website required

me to validate the password with the app and they were sending me back and forth between the two and

that was a typical outcome of of uh Islands of agility um where I as a customer I'm interested

in the entire experience and for that I offer

the experience crew um as I said inspired by by one of the books Network scale and agile that I

read where they say some people should have a laser focus on the entire experience with all

the touch points that a customer has with the business and that even includes Finance that

sends invoices uh um uh and the service desks and physical stores and so on

um because the customer has an experience across many different touch points that needs to be

optimized and that and people in the experience crew could be data analysts they could be service

designers using user Journey mappers human interaction designers whatever they should

inform the product owners and the teams of those various uh products uh what are the things to solve

uh across

their own boundaries yeah that that's that's really powerful I saw um and I I've been unable to find

this graphic but at some point my son was potentially looking at scad which is a uh fairly

um you know the Savannah College of Arts uh and design and it's a fairly well-known um program and

they had there's a there's a very

very famous I think she's Michelin Michelin starred chef in in um in Savannah at the gray

and they had a they had a service map or an experience map uh that was the intersection of

um the people making a reservation interacting with front of the house back of the house uh it

also had uh tendrils coming out for onboarding new Associates

to those and it was just uh it was a really wonderful graphic that I saw when I was there

and I've been unable to find a um a public uh display of that so it may have been just something

that they have um shared with the restaurant and at their uh their site there um and

I I think you're absolutely right that that idea of customer experience um is certainly an important

one

and and uh you know the work of folks like Jeff Patton and Marty Kagan among many others in the

agile community have really emphasized that need for not just features feature factories but um

you know understanding uh that user interaction yep yeah I agree and and personally I have been

more inspired by other communities such as the jobs to be done

where their primary Focus is this experience the job that the product has they literally say that

the the customer hires a product to get a job done to get an experience

with famous examples such as why do people buy a drill well that's not to create holes in a wall

nobody is happy with holes in their walls uh ultimately it's about hanging up paintings and

uh or or photos and the process of creating them is very important in the community uh and going into what's happening around the world and what's happening with the industry as a whole is so important for community development and purposes towards business and the future and I'm going to stop there i'm going to continue with question and answer questions for the rest of the session and then i will see you tomorrow.

Thank you very much.

photos or whatever because that's make that's what makes us happy so the experience is decorating our

house our homes uh that is that creates the happiness molecules as i as i say so the job

of the drill is to help us decorate our home and then once you figure that out then you might come

up with alternative ways to help people decorate their home that does not involve drilling holes

in your wall um but other means of hanging up paintings and so on so i i know there is some

attention to that uh idea in the agile community but not as much as i would have liked because

let's face it we have a lot of product oriented terminology product roadmap product backlog

product manager product owner and so on but the word experience uh is not used very often still

and in other

communities they uh they have been they are ahead of us

yeah so um there were a number uh there were a number of things that also jumped out of

at me about some of the patterns uh that was um to a certain extent intuitive but when you

gave it a name it was very helpful um uh and that's you know the the different

types of uh the different types of uh the different types of uh the different types of

of bases i i think in in um agile uh we often look at especially the scaling strategies

this idea of a fully integrated

base where everyone is pulling towards the same end goal certainly um you mentioned safe and and

less um and and and those two come to mind where we have you know

we're we're we're we're we're we're we're we're we're we're we're we're we're we're we're we're we're

creating a team of teams that is aligned to a particular goal but that only applies

to those sorts of uh of problems um where have you seen um i i look at life speed

and because we're a consulting company we're probably somewhere between a strongly aligned

and loosely aligned base um but where have you seen you know what companies are great examples

of

of or parts of an organization that are great examples like fully segregated loosely or

strongly aligned bases yeah so let's let's uh explain the idea for a for a moment so the the

whole point of having a base is to have a micro enterprise a small business unit that is ideally

uh self-sufficient and and autonomous and small enough for everyone to feel that there is a

um a sense of belonging with their psychological safety and trust and respect uh and so on in in

quite a few organizations this is lacking my my own example and experiences 20 years ago when i was

a consultant uh um sent to a customer uh together with three other people from around the company or

4 000 people i only met them at the client and then we formed a team and i like my team but

the only people that i knew back at the consultancy company were my manager because he decided how

much i got paid and i knew the hr person because she paid me right and i didn't know anyone else

in in the whole in the whole company and and christmas celebration with 4 000 people in a

big event hall was one of the most one of the saddest experiences i had in my life

where everyone at the table had to be introduced to each other and and

tell each other what they were doing at that company of 4 000 people um there was no sense

of belonging whatsoever so i quit within a year and this is one pattern that i have picked up

um you should have a small group of people whatever they're doing but people need to

have a home a base that's why i call it a base some people might call it a try but

i understand some people don't like that word because of cultural appropriation or whatnot

so i've have the

to to base as the as the term to use and and then there can be different flavors indeed as you said

uh safe and less make sort of the assumption that the various teams that work together

on one product that naturally will have to work together as a team of teams as you said

they form one larger unit you indeed you can call that the base but if you have a couple of teams

that do not work together on one product there's still a reason for them to feel a sense of

belonging in a larger team of teams because um otherwise they might feel lost and so one example

is indeed the the loosely uh loosely line base uh where well that would be a consultancy company

where you have a couple of

teams perhaps

working at different clients but they need to know that there is a home to come back to

that there's that they know the other people on the other teams which is something that was lacking

for me 20 20 years ago sure um an example of uh of a fully segregated base that would be um

well maybe an r d unit or an incubator inside a larger enterprise where you have a number of teams

working on separate ideas that could even be competing with each other where multiple teams

are trying to solve the same problem and made the best win it it would be sort of a friendly

competition uh it's very similar to a games company or the mobile games for example i often

mention um robio the makers of angry birds in helsinki i was there a number of years ago and

they make lots of small games it's just a combination of a bunch of games and they're just

It's just three, four, five people on average for one of those games.

So multiple games, teams would together form one base because there should be a sense of

belonging in a larger group.

And they are competing because they compete for eyeballs.

A person can only play one game at a time.

But management doesn't care which game is winning as long as they have some winners.

So it's a friendly competition.

So those are different kinds of bases indeed, I offer for in unfix language.

But the primary reason for having a base is to have that sense of belonging.

And there you see also the cutoff point for what some people might refer to as traditional

agile.

Because in 2001, when they got together, the 17 gentlemen.

They defined the values and principles.

They didn't imagine enterprises of 10,000 people or larger.

They were focusing on small, relatively small number of people working on the software products.

And of course, individuals and interactions over process and tools works well, until you

have 100 people or so.

If you have 4000 people, you're going to need a little bit more.

Yeah.

For people to feel psychologically safe and so on.

In fact, I cannot feel psychologically safe among 4000 people.

It doesn't scale this value.

So you need a smaller unit to sort of contain traditional agile, you could say, within one

base.

Everything that traditional agile says that applies to one base.

But if you go to multiple bases, and I prefer to scale out horizontally, not scale out horizontally,

not scaling up, then you need other ways for those bases to work together in a self-organized

manner.

And that involves other kinds of practices.

Yeah.

And that's where I think the work with holacracy or sociocracy really took that idea of a network

of nodes and ran with it.

For example, yes.

Although.

Both.

Holacracy.

And sociocracy.

One is a framework and the other is a pattern language, in my opinion.

They do not make the distinction between circles at the small level versus circles at a larger

level, where at the small level, you can do without lots of rules and policies and roles

and so on.

Because it's all self-organized within a base.

You can leave a lot of things undefined.

Yeah.

At the larger scale.

The larger scale.

The bigger scale.

The larger scale.

The more you have to define things and set the rules.

That's why we have governments in countries, because anarchy has proven not to work.

And you cannot just scale self-organization as described in the Agile Manifesto to 100,000

people at the cutoff point beyond the base level.

You need different kinds of practices that serve the same values and principles.

And that might involve contracting and defined procedures and whatnot.

What is your guidance for the size of most of your crews, if you're looking at bases

being in the hundreds or low thousand size?

So, in my book, Measure 3.0, I once...

Yeah.

I said five plus or minus two.

That was 13 years ago.

Yeah.

Based on the research back then.

Uh-huh.

Yeah.

It is funny.

When I talk about the selfish meme, I think that was one of the memes that denied us early

on the variation that we probably needed to understand.

Right.

Yeah.

So, yeah.

Five has always, for a long time, been the optimum of 4.6, as Richard Hackman suggested

in his work on team size.

I think teams have become a bit smaller on average, is my hunch.

I have no evidence to back this up, but I think because of remote working and digital

technologies...

Yeah.

...the smaller end of the scale, so three, four, five people is maybe more obvious than

five, six, seven.

Of course, smaller and larger sizes are still possible too, but if you're asking me about

the averages, then I think the average has gone down a bit.

And that's the crew size.

That's the team size, indeed, that we're talking about.

The base, that would be, well, anything below Dunbar's number, 150.

Okay.

I sometimes say keep it two digits.

Maybe up to 100 to stay safe.

Larger is possible, but at some point, it's going to break.

I can imagine people feeling a sense of belonging among 200 people, not 2,000.

I don't know where it ends, or how far you can stretch it.

Sure.

Yeah.

Well, what are your...

Because you've started pulling in organizations...

Yeah.

...in organizational design, certainly Lightspeed is not one of the organizations that's larger

than that number, but most of the clients that we have are much larger than Dunbar's

number.

Have you thought about extending the pattern library to look at base interaction and then

whatever that, to use the circle analogy, whatever that circle looks like at that level?

Yeah.

So my inspiration is Hire, the Chinese company that I visited 12 years ago, where they had

just gone through that huge transformation of turning into a network of 3,000 self-organizing

micro enterprises, as they call them, on average between 10 to 20 people, though some are larger

and some are just a handful.

But they work together.

They collaborate.

They collaborate horizontally.

And what you can see in how Hire operates these days, and there are several books on

that company, Rich and Already, you see the same patterns repeating themselves.

So if you can imagine a new fridge or a vacuum cleaner being launched on the market, one

team of 20 people cannot do that by themselves.

They need multiple teams.

As the makers of the machine, they need factories, they need marketing and whatever.

So multiple units in the multiple micro enterprises in the network get together.

And they do contracting, they do smart contracting, it is all automated.

But there is no management direction necessary to get that organized.

They decide on these things themselves.

If they can get friends in the network to team up, launching a new vacuum cleaner or

a washing machine or whatever, then they can do that.

And what you can see is that some form teams of micro enterprises, you could say, that

would be a value stream cluster instead of a value stream crew.

Some of those micro enterprises offer platform services to the rest of the network.

For example, Internet of Things.

All those devices at higher, all those machines, they want them to be Internet of Things capable.

Absolutely.

Yep.

The most advanced company in the world and the number one IoT company in the world, it

is often said.

And that was one of the constraints of the CEO a number of years ago that all of everything

had to be IoT enabled.

So of course, there are some micro enterprises that specialize in offering those services

to the others in the network.

So those are platform units.

Like the platform teams, the platform crews within one base, inspired by team topologies,

you have platform micro enterprises in the network offering their services internally.

Then you even have micro enterprises that specialize in the user experience.

The only thing they do is watch data.

They detect user needs and sell that information to the other units so that they can act on

it.

That is what, within a base, an experienced crew would do.

At the larger scale, that would be experience-oriented bases or micro enterprises.

So you see the same patterns repeat themselves.

You have some doing platform stuff, some doing value stream stuff, some doing outward facing

experience stuff.

Some work with partners.

Okay.

Innovation networks, universities, even competitors and so on.

Some micro enterprises are specialized in that, in opening up the boundaries to collaborate

with others outside of the network and make that talent available to the network.

So the same patterns repeat.

And that's why I love the idea that it is basically self-similar at scale, almost fractal,

you could say.

Right.

And within the base, you see them repeating.

It's not exactly the same, but it is self-similar, as we say, at the network level.

Now hire is unique, I would say, in that respect.

There are 80,000 people or something these days, 4,000 micro enterprises.

That is astounding.

I don't know any other companies organized like that, but for me, they are the example

to follow.

They only have two layers of management, basically, and then that's it.

For other companies of that size, they have at least 10 management layers in between.

Yeah, I very much like the idea of self-repeating patterns.

I mean, when you get down to it, all of the scaling methods, for the most part, that are

prescriptive, really look at if a team needs to plan together, then a team of team needs

to plan together.

If a team needs to manage internal dependencies and impediments, then a team of teams needs

to do that.

I think it is valuable for – I always emphasize this in all of my classes or consulting, that,

you know, there's nothing particularly sacrosanct about these ideas.

They just have worked for some people and may be appropriate for your situation as well.

And sometimes, those are completely antithetical to finding an optimal solution.

I always use the term best fit practice rather than best practice.

I've always hated that.

Yeah.

That term for a while.

Sounds good to me as well.

Yeah.

So, I know that I have been excited about Unfix.

What sort of traction are you getting in the marketplace of ideas?

I noticed that you ended up in Jim Highsmith's most recent book and just curious, you know,

what the – what's the – what's the – what's the – what's the – what's the – what's the

the interest and uptake has been for – for you guys?

I know that you rebranded your company with that – that branding.

So, what's the future look like, Juergen?

Oh, gosh.

The future.

Well, I can only talk about what we're doing now.

Sure.

And only hope about what could be possible in the future.

Indeed, Jim Highsmith.

He included a page or three in his book on Unfix.

I'm very – very proud of that.

There has been quite a bit of pushback on certain Agile scaling frameworks among the

signatories of the Agile Manifesto, and I think for good reason – good reasons.

And I'm very happy that at least the idea of a pattern language is embraced by one of

the 17, at least.

Maybe more.

A good – a good follow.

We will see.

The traction, yeah, we have case studies coming up.

I mean, I started a year and a half ago.

So, it takes time for people to find this and start experimenting and exploring.

And we are now getting the first results of people reporting back that they made some

changes and that they were very happy with what they have done.

And then it takes some effort to convince them to create a case.

So, we have a case study with us, and then writing that takes a couple of weeks and sometimes

months because of all the permissions that you sometimes need and the interviews that

you need to do.

But, yeah, the case studies are becoming available on our blog, so we are quite proud of that.

And my workshops have, in some cases, been selling out.

Not a single one has been cancelled, so that is a good sign as well.

That is.

I do myself one per month.

That's great.

Thank you.

So, we are one per month, but we also work with partners who organize their own workshops.

And next is, well, I'm working on the next version of the OnFix model that I hope will

be finished by the end of August to at least have some answers to all the questions that

Agile scaling frameworks have answers to, but then in the form of a pattern language

instead of a framework.

So, I say that we are on par.

Thank you.

On par with what else is out there, and people can draw their own methods and frameworks

with the available patterns that they have a much larger Lego box, you could say, to

start building stuff.

And then the next thing to do would be, well, first of all, new version of the workshops,

of course, but also I want to start showing pictures of what you could do following the

examples or the metaphor of Lego.

So, people do not receive a big box of 4,000 pieces of Lego.

They receive examples of what you can make, like a hospital or a truck or a dragon or

whatever.

That's what you get with a little manual on how to make it, and then people learn or kids

in some cases learn that this is how Lego works.

And then it might be a fire truck for one day, but next day, they've turned it into

something else.

That's how it works with Lego, right?

That's the fun part.

They've turned some of those blocks into barefoot landmines for parents, undoubtedly.

Exactly, yeah.

So I would love to follow that example and offer people starter kits, you could say,

with the platform.

And that's how we get the patterns of the language.

Like, okay, this is a starting point and this is a starting point.

But don't treat it as a framework.

You're not stuck with it.

You're supposed to take it apart and add other stuff and turn it into your own thing.

That's when the fun begins of organization design.

People understand that with Lego.

So as long as we follow that analogy, then I hope they will also get it and not as with

frameworks.

They get stuck with a certain implementation and that people are certified with the correct

implementation of the framework.

That's not the way I want to go.

Yep.

In many ways, it's very similar to some of the disciplined agile work that Scott Ambler

and others did that has since been sort of kited over to the PMI.

But I saw that.

It is.

Maybe less.

A little bit of patterns, also some toolkits, but the goal was not to implement any one

of them.

They were examples of ways of using those ideas together to create something that would

work for you.

Indeed.

I had a glance at disciplined agile.

There's also other stuff out there.

If our Jacobson, for example, and his essence model.

So fortunately, I'm not the only one who was in patterns rather than frameworks.

So there's opportunities for collaboration and friendly competition.

All of that is great.

But I sincerely hope that the industry as a whole moves away from framework implementation

towards more.

More Lego modeling with patterns.

Yep.

And the other thing that I've found many agilists are very dogmatic about is this idea

and ideal of a steady team.

What is it?

I sort of roughly know.

Roughly know some of the thoughts that you have on that, but where do they get that potentially

wrong?

Well, I agree there is quite a bit of bias.

Yeah.

And maybe I should back it up because it's not wrong in many situations.

But where are the spaces where that may not be optimal?

Well, we can see in other areas.

Yeah.

We can see in other industries that the steady team does not work.

There are no steady teams at fire departments, in hospitals, in news crews, whatever.

Airline.

Yep.

And so on.

My wife was a pilot for many years and often she'd be with a completely new crew,

people she'd never flown with.

Yeah.

And the environment dictates what is the best.

Yeah.

The best teaming option.

And for sure there are plenty of benefits of having a steady team, the same people working

together for a long time, but it is sub-optimization because ultimately it is about the experience

for customers, not the team boundary is not the most important thing.

And I often use the quote of Martin Fowler.

Martin Fowler, who had said a long time ago, if it hurts, do it more often.

Right.

Yeah.

And he referred to a software releases, as you know, Bob, when we shipped CDs in the

90s, that was incredibly painful.

So we learned how to do that more often, releasing software and remove all the pain that was

involved.

And for 15 years, I've been part of the Agile community and coaches and consultants have

said, don't change your team boundaries.

Because you will hurt velocity and you will hurt throughput.

Well, if it hurts, why don't we do it more often?

That is not a good argument, not to change your teams.

That is just dealing with the symptoms.

So we have to learn, I think, how to do reteaming better.

And Heidi Helfand wrote an entire book on the topic, because in some cases, it makes

sense to form new teams.

How often?

That depends.

At RedGate Software, they wrote blog posts about them reteaming every once per year.

People voluntarily picked new teams to work for and about one third changed to other teams.

And I would call that dynamic teams because the teams themselves remained, but people

moved in and out between the teams.

So the boundaries were permeable, as we say in systems thinking.

But other examples are.

There are fluid scrum teams, Willem-Jan Hageling, another Dutch guy, wrote about scrum with

a team of teams, a team of around 50 people, where every sprint, they formed a different

team depending on the sprint goals that they had.

And people picked the sprint goal that they wanted to work on.

So the same larger team, you could say the same base of 50 people with small mission

teams.

And they were able to do it for a sprint.

That is a fine solution.

It worked for them.

We have Tesla as the last example.

They are extreme.

Joe Justice does keynotes on the topic.

He worked there for a year, and he says the teams last for three hours there.

So that is reteaming to the max, you could say.

Every three hours, they pick a new combination of people in the factory to work with, and

they all self-select.

Which is a huge advantage.

They want to contribute to these jobs they want to contribute to.

So different options, different environments, different ways of doing teaming.

The steady team has its benefits, but it is not the only one.

Right.

Yeah, we had, we did some work, geez, probably eight years ago, maybe even a little longer

with a big data organization that was working to help people.

And help power companies reduce, you know, household usage.

So they had some products that would, were typically purchased by power companies.

And they did dynamic reteaming, well, it was not fully fluid, it was every quarter they

would, they would complete.

Yeah.

They would completely reteam and kind of blow the teams up and, you know, Motley Fool for

quite a long time has had this, this idea of, of you just, they, all of everybody's

desk is on wheels and you literally just unplug and there's network drops in the, in the physical

plant on power and you just pick up sticks and, and move whenever it makes sense.

Yeah.

To do that.

Yep.

And, and valve and, and companies like that.

Yep.

Indeed.

Great.

So where can people find out more about your work and, and, and hear you and, and, you

know, learn from you what's, what's, what's that look like now?

The most obvious place to go is unfix.com.

I don't think.

Yeah.

I don't think I even need to spell it pretty simple.

Fortunately, the domain name was available a year and a half ago.

So that's where you can find the model, the patterns that we're working on new ones are

still in development, as I said, or a new release before the end of the end of the summer.

And there's a community there's lots of cards, playing cards available for download.

And PDF for all the patterns.

I wanted every pattern to come with a card so that people can create games and exercises

with them digital and physical.

That is very much appreciated.

I noticed and yeah, shoot me a message in the community and I'm, I'm happy to chat.

Excellent.

Well, I want to respect the time box.

I know we had scheduled.

This to 11.

So I want to be mindful of that.

And I really appreciate having you on your gonna I'm looking forward to seeing that next

iteration of unfixed.

Thanks for the invite Bob.

The pressure.

Yeah.

Thank you very much.