Loosely Coupled - Recognizing and managing Cognitive Load

Hello, welcome to my lecture.

Good afternoon and good evening for all of you tuning in to loosely coupled a live stream by bridging the gap.

I'm your host Karol Skrzymowski.

And today we're tackling another loosely coupled topic.

Well topic loosely coupled to tech because it's a I think a very important topic in in tech in the industry specifically cognitive load and cognitive load.

I don't have a lot of knowledge about that.

I know it affects me.

I know I have some problems with cognitive load.

I mean, I suppose everybody has.

I know that is a troublesome topic when I'm managed.

And today joining me on the stage is Radek Oroszewski, a accredited Kanban coach and professional trainer and also a team topologies advocate who provides training and consulting across Europe to teach team topologies and implement all of that with customers.

And Radek today is going to be talking with us here about cognitive load and the implications that it has on our work.

Hi Radek.

Hello.

Hello.

I got all good to be here.

Thank you for for having me here today.

All right.

Radek, tell us a little bit about yourself and a little bit about your work as a trainer and team topologies advocate because Kanban here is a little bit less important in the context of our chat.

Yeah, but they are interconnected because we're going to talk about limiting cognitive load and Kanban is very much about limiting work in progress, which in the end maybe is the same.

But yeah, you introduced me as a person who works with team topologies.

That's true.

Well, looking at my professional career for close to two decades, what I try to do is I try to help people, organisations to work in a more pleasant and effective way.

And yeah, I discovered two years back, the topologies.

Many of us have read the book probably.

And for me, this was really interesting that it looks at IT industry, looks at knowledge based work from this socio-technical perspective.

So on one hand, we have this human factor.

On the other side, we have, yeah, increasing and increasing everyday complexity of solutions that we develop, that we build.

And yeah, I'm happy to say that the team topologies community was very open to welcome me.

So I first became an advocate, as you said, to someone who promotes and educates about this approach.

But in my everyday life as a consultant and trainer, I provide classes under my brand lineage.

We are authorised to provide the team topologies classes.

And yeah, I work with people like yourself.

I mean, like, you know, people who are architects, people who are managers and leaders, and they try to somehow balance how we approach everyday complexity.

And we try to find something in between, I believe, two ends of the spectrum where we say, yeah, we would like to be specialised.

We like to do what we do well because we are recognised for doing that.

And on the other hand, we would like to have some flexibility and go beyond our existing roles or responsibilities.

That's when we discover that cognitive load is a thing.

Like you said, you feel affected by it.

I feel affected by it every day.

And this is really interesting topic that the industry is not, I would say, unified how to look at the cognitive loads.

Maybe that's also a topic for us to discuss today.

I'm sorry, I'm a bit distracted because it seems that we have a bit of a technical issue today.

Mainly that, unfortunately, we're not streaming on LinkedIn for some reason.

It didn't start.

So I'll just pop in a message on LinkedIn to say we're sorry that there's a technical issue and invite everybody to join us on YouTube.

But all right.

So it affects cognitive load affects every one of us.

Right.

So perhaps for those who have no idea what cognitive load is.

Well, I wouldn't say I have an idea.

I have a very basic understanding, probably a little bit misguided.

Yeah, perfect.

Sim, thank you for info.

Yeah, we know it's working on YouTube.

It's it's only the LinkedIn.

That's the problem.

So if we're talking cognitive load.

All right.

And we're going to probably jump into the more detailed explanation of our types and etcétera.

So what would you say is the like the core elements that we need to watch for when we're talking about cognitive load?

How would we observe cognitive load as well?

Specialists, human beings, whatever that is.

Right, right.

So I believe it makes sense to maybe take a few steps back in the history because the term cognitive load comes from psychology of education.

Australian scientist, researcher John Sweller coined the term in 1980s where basically he proposed the approach or the idea that it really depends how we expose people to new knowledge.

I mean, students at school like primary school kids or students or professionals learning something new.

And that if we if we basically expose them to too complex content, if we don't deliver the content in the right way, if we don't provide instructions in the right way, we can lead really quickly to a situation of this cognitive overload, even that we say I cannot consume.

I cannot digest, let's just say, the knowledge that the content that you expose me to because it's it's too much for me.

It's maybe too intense for me.

And I believe this, let's just say education and psychology track goes on until nowadays you can if you type in cognitive load, you can find materials for professional educators like like teachers at schools.

But the term was, I don't want to say stolen, but maybe hijacked by professionals working in industry like IT, where we say, well, a part of our work is also learning something new, right?

Every day, many of us are facing challenges of doing something for the first time, doing something the only time because we produce something unique, right?

We are exposed to new technologies.

Hey, there's a new language.

Hey, there's a UI, AI.

Hey, there's a new framework or there's a new business context.

And because we are lifetime learners, I believe I can I can speak not only for myself, but for many of us, right?

It happened that, well, the rate that we are exposed to new challenges or new knowledge can also trigger some, let's just say, behaviours, some symptoms of too high cognitive load.

And of course, there's maybe this, you know, academic discussion or debate if that's the correct tool to hijack and use the term cognitive load in this domain and apply not only to individuals but also to the teams or organisations.

I don't want to go into it today.

And I believe like many of our viewers are not interested in it because I don't find it really practical.

I would say the cognitive load is like a bad smelling air.

Yeah.

Coming back to your question, what would be the, you know, the how would I recognise it?

Right.

So you say, well, if you enter a room and you feel like bad smelling air, you say, oh, something smells bad here.

But after you stay in this environment in this room for quite some time, you know, our sensors in nostrils like becoming immune to it, we don't feel it anymore.

It becomes like, oh, we just work slowly here.

I'm now translating this to other symptoms, right?

Our brains adapt, basically.

Exactly.

Yeah, we don't deliver.

Right.

And and this is this is really interesting that we we say we enter our professional environment with certain capacity, with certain memory that we have available.

Right.

And if we see some symptoms, we're going to go deeper into it.

Individuals and teens exposed to to certain, let's just say, factors start showing the results symptoms that, you know, we cannot focus, we cannot deliver.

We juggle too many topics.

We do not meet the deadlines.

And it has, I would say, again, social technical consequences.

So on one hand, people are like, you know, completely checked out.

They are overburdened.

They feel like, oh, this is the professional burnout in the end, maybe that I that I suffer.

And we also see it reflected in the outside technical results of our work.

Right.

So so the work is far from something that we would be proud of.

The solutions that we choose are, well, far from perfect.

Right.

And yeah, it's it's it's good to say, are we not designing?

Unfortunately, I'm not saying that we designed it.

But like as the whole industry, don't we design the environment to even increase this cognitive load and and to make people.

Yeah, in the end, suffering.

I know it's a strong word in the environment because, well, A, we don't know it's there.

That's the topic of today's meeting, like identifying, recognising, acknowledging that it's there.

And the second step is like doing something about it.

So so managing it right.

And there's no one silver bullet solution because we need to first identify what type of cognitive load do we deal with and and then decide, OK, what kind of strategy, what kind of solution?

Probably we're going to come to it today is like maybe applicable best in this context.

That was a hefty explanation.

Heavy, heavy. Yeah, I know.

So let's maybe play around with some analogues.

One of the analogues that came to my mind where we were discussing this topic before the stream was a very known law in IT, which was which is Conway's law.

So Conway's law is a design law so that we're reflecting analogues in our life in terms of how we design things in organisations in a specific ecosystem.

So we're reflecting that it's either we're going to be blindly reflecting that or we're going to change something to do things better.

Right.

And as far as I remember, Martin Fowler was describing that in one of his blog posts, the one on Conway's law.

You can either ignore it or not be aware of it and then you will suffer the consequences very dearly.

You can accept that it's there and just give up and follow, fall into that and just do with that.

Right.

So deal with that with in the case of cognitive load, that would be accept that it's going to be slower, accept that it's going to be there's going to be frustration and whatnot.

And then you can in Conway's law, you'd have the reverse Conway manoeuvres to change your organisation so that you can change the way Conway's law is applied within the organisation.

And I think it's a little bit similar with cognitive load.

If we start changing the way we work, we will still have cognitive load, but it will be probably applied differently because it's not going to go away.

Right.

Yeah.

And this is really interesting to start talking about the details of cognitive load, because not every time I even revert this sentence, cognitive load doesn't need to be a bad thing.

And there are certain types of cognitive load that you would like to, let's just say, experience, not suffer from.

Right.

So maybe this is this is the moment to go deeper into, let's just say, practical exercises.

So you asked me, how would we recognise that we suffer from the cognitive load?

As a consultant, as a trainer, I meet people from tens of organisations here.

And sometimes I just stay with one organisation a little bit longer.

And I keep hearing from management or agile coaches or scrum masters assisting teams, for example, that all they don't deliver, they continuously take something from one sprint to another, etc.

And we say, okay, let's try to discover why is it like this?

And of course, we can stay at the surface and say, well, the team didn't manage to complete everything.

Okay, that's the surface, but why?

And now we can go deeper and try to understand that maybe we have at least, I want to say, three different types of reasons connected to cognitive load that we can observe.

So the first thing is like, just like with the education, we want to understand if our people are actually skilled with the right knowledge, techniques, frameworks, programming languages, whatever it is, to actually do the work that it's supposed to be done.

Right?

So if you're like a software engineer, like, can you actually proficiently develop in a given language or given a given framework, right?

And if we observe that we have a problem with it, then it means that what we actually see is the first type of cognitive load.

And now I'm going to start sharing the screen card or probably you can do the magic.

So we don't overload our viewers and they can focus on the content, right?

And then we say, this is something what we call intrinsic cognitive load.

So this is really connected to what I'm supposed to do, right?

So if I'm a Python programmer, am I proficient in Python?

So I have my skills, I have my mental tools to actually do the work, right?

And this is basically a basic thing which is, I would say, very often neglected because we have this halo effect.

So we're going to say, oh, Carl, you're the smart guy, we're going to put you in this team and we want you to start doing X or Y, right?

And we don't know if you're skilled with the tools or programming languages or whatever is necessary in this team.

Because you're the smart guy, we have this halo effect around you.

So we'll assume that you will do it.

And I think there is a general assumption that people over a specific IQ, and I found that in some YouTube videos, people over a certain IQ are capable to pick up any topic.

Yeah, yeah, that's, that's an assumption, right?

That's an assumption, right?

Yeah.

And, or we hire someone completely new, and maybe during the, I don't know, recruitment process, this person was showing, let's just say, some skill set.

And yeah, we believe that he or she is capable of doing that, right?

And very often we discover in really professional organisations that this is assumption, and especially if the organisation is under heavy, I don't know, wave of changes like newly formed teams or some migration of people between the teams.

We cannot be sure that people are actually skilled with this, you know, really basic things to do, right?

And if we see it, then of course, we're going to talk about it, we need to address it correctly.

And the second type of cognitive load is something that we called extraneous.

And I like to explain it that you hire smart people, but unfortunately, they are told to operate in an environment in which doing the things that they can and won't do is not easy.

Right?

So, yeah, so what I'm going to edit here is word environment, right?

And this is interesting how we waste skills of our people, of our teams by, you know, telling them you need to figure it out by yourself, or you need to do it in this way, or no, you cannot do it because it's not allowed in this organisation.

And the different levels of, you know, bureaucracy or politics, or sometimes we see, yeah, super strange things like, okay, you cannot work with the system, you cannot talk to these people because yes, they are the part of the same organisation, but a different entity.

You're an employee German and you're an employee in Switzerland, so you cannot cooperate, whatever.

So, you know, different things.

But, yeah, very often it is also about the technical things, right?

So, you hire a person who is skilled with all the things that you wanted from here or her, yeah, all check marks here, right?

And then this person starts thinking, okay, how do I do it here?

I can give you the example.

I often see people moving from, there's maybe this trend, smaller companies to bigger companies, and in bigger companies, they are struggling how to do it because in the previous job environment, they had more autonomy, more freedom, more independence.

And here we have processes, and I don't want to criticise processes, but for example, these processes are even hard to unhide them, hard to discover them, right?

So, okay, I'm supposed to deploy my application.

How do I do it here?

Yeah, I'm supposed to apply for a training.

How do I do it here, right?

And we create, you know, platforms, Wiki, SharePoint, intranets, video tutorials, whatever, right?

And people are still struggling how to find the very basic information.

And I'm not surprised that few years ago, I've seen like a, you know, a research result saying that an employee in a bigger company becomes really helpful after 13 to 14 months.

Why?

Because only after a year, this person builds like a social network.

So, if I spend enough time in the organisation, I will learn that if I need something from IT, I will write to Karl directly because he's the nice guy, he will reply me, he will explain me how to do it.

There go procedures out of the window, right?

Exactly, yeah.

And there's a really extreme case, maybe, I remember during one of the fast flow conferences, so the event hosted in London, one of the presenters, she was telling about the history of a bank, I guess in the UK, and they had an IT, inside the IT department, they had a cloud team.

And this cloud team was offering such great services that one part of the bank decided to establish their own cloud.

Because like, you know, utilising whatever was provided by the experts, right?

Was so inadequate, was so not matching the needs, right?

So hard to, you know, configure or whatever, right?

That they established their own cloud entity, which of course was a risk in case of security, additional costs, additional mess, right?

So we say...

But this is not a seldom occurrence.

I worked as an enterprise in a large networked environment with multiple entities in one country being connected by one brand, and then that also connected globally to other entities in other territories.

Within one territory, I believe we had four or five different IT units that were operating on their own, because the one that was provided by the unit that was supposed to take care of the inside, the central unit, was so slow and so red taped that it was impossible to...

work with that.

Because any change needed, and any approval needed to build anything for a customer or prepare a project even for internal users required four or five months just of bureaucracy.

Yeah, I see a comment in the chat.

Yeah, of course, it's a learning opportunity, how to do it right, right?

But on the end...

And I don't want to lose track of our audience.

I want to say there is this good type of cognitive load, because I started with this sentence, right?

That cognitive load as such doesn't need to be something really bad.

We have this third type that we called germane, and this is something that it's actually about delivering value, building whatever we are supposed to build.

And now if we will understand that, you know, yeah, again, there was this comment talking about the bucket, right?

So like, I have my brain or we as the team have the bucket and this is our mental capacity.

And if we say we spent a lot of this mental capacity on, you know, dealing with our maybe deficits, unspoken lack of skills in what we are supposed to do.

Unfortunately, I would say there is a big pile, big volume of this extraneous, how do we do it here?

We would like to do it.

If only we could, yeah, I don't know, whatever comes to your mind.

Then there is a very little space for this germane cognitive load, right?

And I would say if we look at the ratio, naturally, we would like to see it differently.

So there will be always some kind of intrinsic cognitive load, because if we are lifetime learners, there's always something new that we discover that we learn, right?

If we build the environment around us, then, of course, we can hopefully reduce the orange colour here, so the extraneous connected to environment.

And then if we have this finite volume, then, yes, we spend the time, we spend the effort, we use our brain power to basically think about the things that we were hired to do, right?

That we are supposed to deliver, right?

Like, what's the best solution for our business?

What's the best solution for our customers, internal, external, whatever?

So this actually kind of sprung into my mind the original thought behind scrum teams, where the scrum master is supposed to at least guard against the extraneous cognitive load so that the team can progress.

With the tasks and the scrum master is the one guarding them so they don't be disturbed by the environment.

I think that would land in one of the responsibilities of said scrum master in that sense.

Yeah, I would agree to certain point, because, well, the good scrum master is someone who should have this knowledge about the context, about the network.

He or she should be the one that will say, you know, I'm not going to do it for you.

I will tell you how to do it.

Let's go together to find a solution.

And definitely, that should be someone who should know what kind of cognitive load are we struggling in a given team.

And I need to say that because of my profession, because of what I do, I need lots of scrum masters and agile coaches.

And when we talk about cognitive load, I hear very open statements for which I'm happy and thankful when they say, you know, Radek, I never looked at it from this perspective.

I facilitate retrospectives.

I participate in reviews.

But I'm not sure if I can say what kind of cognitive load do I deal with with with my team or teams.

And if you don't know, then you cannot help these teams, right?

Because you don't know if there's like one or two team members who are missing certain skill set, right?

And they should be somehow educated, supported, learning it.

Or maybe that the team is like, you know, perfectly optimistically forecasting sprint to deliver some kind of scope.

And they figure it out only later that, yes, they all have the skills that we need.

But unfortunately, because of environment, let's just say, boundaries or something, invisible walls or whatever, right?

They, yeah, it's beyond their capacity to really deliver it.

Yeah.

Mm hmm.

That's that's very difficult to say which is which and what we're actually handling.

I think that would that would require some some really hard reflection.

Yeah, to understand that, to make it even more complex, there's always content context and context is the king, right?

So.

Right.

So asking simple questions can actually lead to, yeah, interesting conversations.

If something that is easy for you is easy for me, is it a matter of my skill?

Is it a matter of how long do I work in this organisation?

So I know how to do it, right?

It's different for organisations who work on well-established, long-running products.

It's different in organisations which are building products from scratch, right?

And we have maybe not well-established processes, but again, that's an opportunity to build them the right way.

You know, to build them that we don't design them to generate a lot of extraneous cognitive load for our teams or employees.

So a few examples that come to mind in terms of also handling this.

If you worked in large organisations, they have certain procedures of, for example, onboarding professionals.

I found this, I think, several times in many different companies, that, for example, to limit the extraneous load, there is something called the buddy system.

So on onboarding, you get a colleague of yours assigned to you as a buddy who is supposed to answer all manners of questions that are not management level questions.

Would that be considered basically tackling a part of the extraneous cognitive load for somebody who's a new employee?

Yeah, I believe it does.

I mean, first of all, it's such a setup that we have a body that we can refer to with our questions.

I would say, again, a symptom that we recognise the fact that new people will have questions, right?

They may feel, I don't know, too shy to ask them to go to your manager, like you said, right?

Or maybe it's hard to find this information.

Yeah, so that's probably one strategy.

What comes to my mind also from this perspective is that, yeah, I know everyone's talking about AI now, but I think it's a good case.

This is no joke, right?

That I know teams who are basically building their own models or agents, and they feed them with curated information about the context of their product, technological solutions, whatever.

So you may have this kind of virtual body, right?

So you can ask a chatbot or a solution like this to say, you know, tell me, how did you do it before?

Where can I find the solution?

So we are not talking about the AI agent here working, like doing the work of a developer, for example, right?

But being this virtual team member, which provides the context-based knowledge, right?

So we can have our own, whatever, cloud, chat, GPT, or whatever instance, right?

And say, this is fed with our data, curated one.

So maybe it will reduce the chances of hallucinating, right?

And this is our 24 hours never-sleeping body that will help us, right?

And one more sentence, thinking about Team Topology's approach, if we say good platforms are self-service platforms, right?

So this kind of solution, right?

Could also be used company-wide, if I want to know how to do whatever X apply for holidays or what to do with the beers from my business trip or whatever, right?

Then, of course, I can first try to find it on a Wiki or SharePoint.

I can try to read the static PDF explaining it, right?

Or I could have the AI agent who will just, you know, tell me how to do it, right?

And it will lower my extraneous cognitive load.

It will be more friendly.

It will reduce the time that I'm supposed to spend on something else better than digging the company internet.

That brings me to a very interesting realisation now that I actually have been lowering my intrinsic cognitive load heavily by using specialised AI.

Because since I do own a licenced Google workspace environment, and since January, Gemini is included in every licence, and basically that the plugin for an AI is available in every single tool.

On top of that, you can specialise your Gemini chat with a specific persona that has a detailed plan what it's supposed to talk about and do.

So I'm not a specialist in many things.

I am a specialist in enterprise application integration.

So basically, while I have, let's say, an interest in educational psychology, or I do enjoy beekeeping, because my stepfather was a beekeeper.

I have limited knowledge about other areas of life, because, well, never going to be a specialist in those.

And, well, I could read up on them on those topics, but the day only has 24 hours.

I still need to sleep.

And I have two kids and a wife, so that kind of limits the possibility for me to gain new skills.

So for example, if we're talking about marketing or business planning for trainings that I do, or planning even these live streams, I'm not first with the LinkedIn algorithm and doing social media.

So basically, instead of that, I did what I do best.

I solved the problem by doing something IT related, which I actually know and understand.

So I built myself a specialised chatbot to figure out for me, based on whatever is in the internet, how to deal with social media posts, and how to approach writing those or strategise content creation so that I don't burn out just from doing content.

And I just now realised that actually I've been very heavily influencing the intrinsic cognitive load on my shoulders, so I can then deal with actually having the germane cognitive load.

Yeah, okay.

So shifting this way.

That's an interesting observation, because I completely did not realise I've been doing that.

But it helped a lot.

Yeah, I mean, we started the conversation talking about the cognitive load, something that is present in our lives every day.

It's present in our non-professional or private lives as well.

How do I shift it to increase cognitive load or increase my mental capacity that I can spend on doing these things and reduce whatever is here on the left hand side, be it the red one or the orange one, sticking to the colours.

If we say the volume, the capacity is finite, right?

It's not like our brains are stretchable endlessly.

But I want to say here that it doesn't mean that we cannot grow in terms of our skills, right?

Because if we identify this high intrinsic cognitive load, then it's a signal that we are asked in our professional environments to do something that we are not skilled enough to do or maybe to do in a proficient way.

And that's a signal that should, I would say, radiate in the organisation and organisation should support us, right?

And if we look at the org chart, it's even more complicated.

Why?

Because not only the cognitive load has its all flavours that we just discussed, but they also change in time in different parts of organisation, right?

So we started with Conway's law when we say that often the product of organisation reflects the structure or reflects the communication pathways, right?

Who is speaking to whom and who is not speaking to whom.

We can see it every day as users of commercial products like, oh, this clearly was done by two departments, right?

This is so incompatible or so broken, UX is in it.

And I see it every day as an integrator because I'm in the middle of everybody and seeing how they are.

I bet you do, right?

Two systems are completely siloed and never exchange a single word between them.

And they need to exchange data.

Those people probably not even attended the same integration part, right?

That's another topic.

So if we look at the organisation, we could say, oh, I have a picture of organisation.

I'm copying it.

I will explain in a moment why.

And I could say, oh, I have a team and this team is relatively new.

It's composed of, I don't want junior people or something like this.

And yeah, we see a lot of red signals.

So sticking to the colour code intrinsic cognitive load because these people are maybe not not skilled with what they are given the task of now.

At the same time, we may have a team who is, for example, given challenging task, requiring communication or support or services from teams which on the org chart look relatively close.

But we see that they belong to a different department, right?

So maybe there is a high extraneous cognitive load because they're trying to get someone's help, get someone's engagement, maybe access to applications, whatever else in here.

And of course, this is basically reducing the space that they have for the germane work because I would like to do it.

But how do we how do we spend more time on the blue if we have the orange here?

And we're going to talk about maybe certain strategies or techniques in the moment, but think of it this way.

Orchards are usually static and orchards change when we see a big shift like transformation, acquisition, merger, whatever, right?

That the changes changes it.

But we we cannot forget that, you know, organisations are living beings and we may have, let's just say, maybe I will add some comment here visually, you know, even like six months later, right?

Six months later, we may have the same the same org chart, but we see that, oh, maybe now the situation in this team is really better because they sorted out something, some communication patterns with the other teams and they don't suffer.

They rather spend their time with the right type of cognitive load.

But, yeah, in the other team, we may have even more of red.

Why?

Because this this box looks static, but it's not stable because, let's just say here we had, I don't know, four people who are staying with the organisation for quite some time.

We had three new people and six months later, unfortunately, we have six new people in total and just one single member of the team who knows what's being done before.

He cannot be the body for all of them, right?

So the situation is unfortunately worse, I would say, because the more red, the more of intrinsic cognitive load.

I don't see too many scenarios when that would be a happy scenario, right?

So this is not only different team by team, but it's also not static in organisations, even though the org chart may fool us a little bit, right?

I think that the team is more mature because it exists for six more months, right?

Well, may be true, but may not.

So we're having problems like employee retention affecting the cognitive load.

We're having problems like completely different responsibilities and lack of common understanding and language, which will be affecting the extraneous load and also intrinsic in certain situations.

Then just simply by having different lines of reporting would be already something that is quite problematic at times with the extraneous cognitive load in that sense.

There's so much to that.

And then I'm looking at it from a perspective because I worked most of my life as an IT consultant, and it's a difficult topic.

Like I'm looking at it from a perspective of an architect consultant that joins a company to help that company solve a specific problem.

For me to join the company and be effective in that company and gain sufficient context, that is a minimum of two months engagement to just gather context.

And a lot of consulting companies do it the way that you have so-called parachute architects, that you just drop them in a client and then grab them away after two, three weeks because that's the budget.

There we go.

Wow, there are so many variations.

First word problems.

Yeah, first word problems.

The thing that comes to mind here, also looking at the comment coming from Dominique, who's mentioning...

Yeah, fully agree.

I was going to comment on it.

The thing that comes to mind with this particular comment, and I saw the model of flow, and I absolutely had no idea who this psychologist is.

The name was unfamiliar, but Jim and I helped really quickly resolve that one.

And the concept of flow to be the immersion of in an activity.

This, apart from the comment itself, this brings me into also the topic of neurodiversity and having the cognitive load affecting people that are neurodiverse probably differently than people who are neurotypical.

And that is another interesting topic.

Me, myself, I have ADHD with a slight pinch of autistic traits.

And I know that when I'm in a flow state or a hyper-focused state, as it's called within the ADHD community, nothing else can exist.

And their main cognitive load is just skyrocketing, but then it comes at a cost.

So it's interesting to...

Let's go back to that comment, and then we've been into the model of flow.

What's your point on that here?

Yeah, so Dominique, thank you very much for the comment.

I fully agree.

Yeah, this is maybe something that we will talk in a moment, talking about strategies, especially for the intrinsic cognitive load.

So how do we build people's skills?

How do we increase team's proficiency in using certain technology or even techniques?

I don't know, interviewing customers, whatever, doesn't need to be a hard technology-related skill.

I want to say not to overwhelm all of us, but you're right, Karl, the fact that if a person is somewhere on the spectrum of certain challenges with focus, with whatever else, is one aspect.

I want to refer to the off-the-stage conversation about different nationalities.

These days, even different generations, right?

Like, I'm 40 plus, right?

And one could say, oh, he's going to perform differently than the Gen Z people.

Yeah, but are Gen Z people also all the same?

Not, right?

So I would say this is a role of a leader or maybe someone assisting the team as a scrum master, someone else, to understand.

Yeah, who do we have on this team, right?

Are they really looking at it from the same perspective?

And following Dominic's comment, I want to say, yeah, going into practise.

So, yeah, we recognise, we acknowledge cognitive load, different types of cognitive load, the fact that the cognitive load in the teams can change over time and will change over time in teams, in organisations.

Maybe start, or start talking about, okay, what do we do it, right?

And if we imagine, yeah, organisation, and if we imagine that, you know, there is a team, and we wish from the team topology perspective, that that should be the stream-aligned team, though.

So they should take a problem and they should deliver the solution, right?

If it's a scrum team, if it's product team, it doesn't really matter.

You can use different vocabulary here.

And we say, we see in this team that there are some, you know, symptoms of this intrinsic cognitive load.

Following the flow, or Trixie Nihali, the concept, yeah, how do we approach it, right?

And now I see many anti-patterns in organisations.

So we say, if we are missing, let's just say, skill, which is red, what we are supposed to do, well, let's hire the red expert and let's insert him into the team, problem solved, right?

No, we have a bottleneck, we have one, a mass factor one, and if we don't basically propose any solutions, it won't be that naturally by osmosis, this red skill will spread across everyone else, right?

That's not it, right?

So what do we try instead?

Well, maybe we will find people inside our organisation or outside of our organisations.

Let's create the red team, and red team knows that they are actually revaluable to the organisation because they are this redness centre of excellence.

So let's build the ticketing system.

So every time the yellow team wants something from the red people, please create us a ticket.

This ticket will wait in a long queue of other tickets, right?

And maybe in a few months, we'll come back to you and do, right?

Okay, again, something really stupid.

And sometimes managers...

So we basically solve the lack of scale by introducing extraneous cognitive load.

Yeah, exactly, right?

Because we need to figure it out how the heck to create a ticket for this team.

So that's...

And then all the frustration by waiting for that team to actually deliver something, okay?

Yeah, yeah, yeah.

But I see, again, I'm not judging that these are bad intentions, right?

But I see the team and they are missing this certain skill.

And I see that the manager leader says, like, go and figure it out.

I want you from, as of next Monday, be expert in red, be expert in this missing skill, right?

And this is something what very often frustrates people naturally, because, well, how am I supposed to be an expert in it?

How about even be proficient in it?

We are surrounded by people also because of neurodiversity who want to be very proud of what they do, right?

They don't accept some inferior solutions, right?

They would like to be really not ashamed of what they see.

Plenty of perfectionists in IT.

Exactly, right?

So what do we do, right?

And I give here a simple analogy.

So it's still the summertime.

So let's just say you want to learn how to say it.

What do you do, right?

I mean, you can go and say, I want to watch many YouTube videos about saying it.

Okay.

Probably you're going to learn a lot of language, a lot of theory.

You don't know if actually theory applicable to your needs, because you may be watching videos about ocean sailing while you're going to be the lake sailor in the air, right?

That's quite a difference.

I'm going to hire a skipper with a pipe, like every sailor, right?

And stripes.

And the crew.

And I'm going to sit on the boat, and I'll tell them to operate the boat for me.

I will learn by watching.

So for me, this is, of course, silly strategy, just like I would say, because I have flown this year already more than 20 times a commercial aeroplane, then I'll become a pilot.

No, I'm just a passenger, right?

It doesn't make me any closer to be in terms of sailing that would actually this approach would actually be probably closer than the YouTube tutorial.

Yeah, exactly.

Yeah, yeah, yeah, you're right.

Yeah, because in the commercial aeroplane, I'm not even allowed to be in the pilot's cabin, right?

So I don't know what they press or what they pull, right?

Here, I could watch it, right?

And naturally, when I ask people, so, okay, if you say, this is not the way, and this is not the way, what would you do?

And they say, oh, I would hire an instructor, or I will sign up for a sailing camp.

So I meet other people like them.

And as a group, right?

And I say, okay, then why don't we do it at work?

If you believe this is a good way to acquire a skill, right, to build, increase the skill, like, why don't we do it at work this way, right?

And what would it mean at work, right?

So at work, it would mean that we introduce this concept, as you can see, I have a lot of icons with team topologies, I'm going to find one that we call enabling, right?

And enabling team is not the team that's supposed to do something for you.

But they, okay, enabling team, enabling team comes to you just like the sailing instructor, and they ask you, okay, at what level of profession, professions, professions, you're supposed to be, do you want to be, you know, an ocean sailor, who's gonna go for the, like, you know, around the world race, or you just want to feel secure going with your friends on a small sailing boat, right?

So what's the goal, right?

What do we want to accomplish, right?

Now, okay, how fast do you want to accomplish that?

Well, I have only two weeks, then my summer holiday is gone, so I would like to do it in two weeks, okay?

So we have a time box, right?

We know that this is going to be two weeks, right?

So let's start, right?

And maybe the very first time, you are actually just an observer, and someone else is at the helm, right, of the boat.

But every day, every time you are during your sailing course, the instructor basically enables you, empowers you to do more, right?

You can start operating the sails, you can start operating maybe the engine, or I don't know the radio if it's on board, and then, of course, steering the boat, etc.

And he gives you the feedback, right?

He gives you the feedback, like, are you on track at all?

Yeah, maybe you don't need to really perfectly polish this kind of skill, but maybe work on something else, right?

And if we have good teachers, and if we have people who are skilled at what they are supposed to teach the others, then we can say, we can add this skill to everyone, maybe differently, but across the whole team, right?

And if you see techniques like mob programming, or per programming, if you see people who come and say, I'm not going to do it for you, I may do it with you, right?

I may help you with it, and I will give you feedback, I will tell you what you're already good at, and whatnot, right?

But what is really important is that we have this time box and this goal, so it's not building another dependency, another extraneous cognitive load.

Okay, now my instructor is gone, what I'm supposed to do, right?

What's his phone number, right?

Because I cannot do anything without it.

This brings to mind two specific things.

One, that this enabling team or enablement team in large corporate environments, that probably would be usually or should be usually the L&D.

So the learning and development unit should be, but I would say the enabling team should not be a concept which is absolutely unknown to learning and development.

It should be something fairly new.

The problem I'm seeing already with this popping into my mind is that people in learning and development are often, especially in the tech environment, in technical companies, technological companies, they're not techies themselves.

So that means they lack the context to properly understand the problem space of the lacking skills to enable the team with proper skills that they actually can learn.

And a very similar situation, and again, context is king, is with recruitment, right?

So we have a company that requires a specialist, we have specialists on the job market looking for a job, and in the middle of that we have a recruiter.

And the recruiter, in my opinion, has a very high extraneous cognitive load all the time.

I would say at times, at least those that don't care enough about their job, they have very low domain cognitive load.

And if they want to learn and actually be proficient in the field that they're recruiting in, they would probably have a very high intrinsic cognitive load.

Because I've seen time and time again where recruiters were posting job postings, especially in recruiting tech, where those job postings have made no sense.

Yeah, or if you disseminate that job posting into actual skills and usual roles in a healthy environment, that would be a whole department, not a single person, right?

So these kind of things.

And if a recruiter already has the skills, soft skills and technical skills related to his job, so understanding of that field, they would basically challenge their client, hey, you're looking for a unicorn, that is not a job posting that you'll get candidates for, because it describes half of a department.

It's impossible, right?

And then that builds again, more extraneous load on the candidates, because if you have a vague job posting, well, it is what it is.

Yeah, it's a tough topic, I would say, because you are right if someone is not familiar with the, let's just say, hard skills that the candidates are supposed to have.

Or the teams that we're enabling.

It raises the risk.

On the other hand, when you said it, I heard in my head, my colleague, who's a psychologist, and she said many years ago, remember Radek, we hire for skillset and we fire for mindset, right?

So, you know, maybe it's also, what I want to say is like, I believe in such case, of course, there should be some kind of partnership, right?

So you are right.

People from learning and development may not have the skills or knowledge to say how to find the right expert to teach on X or Y.

But they should, again, have, I'm going to go back to this, go back to this picture, they should have maybe a tech lead and a scrum master or whoever else, as partners, right?

So I'm the HR person or learning and development person, and we all together communicate to understand what is needed, what's the best approach to positively attack this high intrinsic cognitive load in this team.

I don't know what's the expectation of our viewers, but we said how to recognise and how to manage cognitive load.

So if you don't mind, I would like to move along because we also need to talk about this orange, so extraneous.

Okay, yeah, right.

So what to do when we figure it out that this is the situation right here, that we are like really suffering from smart people having very little time or definitely too little time spent on the right things because they try to identify, yeah, how to do certain things in this organisation.

And I'm looking again at our chat, I don't know if Sim is with us, but there was a statement, shadow ID is both threat and the learning opportunity.

I will look at this learning opportunity as a good thing.

Why?

Because if we really observed that, you know, people moved from one solution provider to another, then we can identify what was the pain point using the initial solution and what was better with, hopefully better with the with the latter solution, right?

Like what was better then.

And if we look at the team topologies, from team topologies perspective, if we have a team which is not independent completely in delivering because let's just say they are supposed to deliver something.

But again, it would really overload them to learn quickly something that they don't want to have pH yet.

Like I want to use cloud, right?

But but do I need to be all certified AWS and expert or whatever?

Probably not, right?

If you're like me, then yes, I would like to be the expert in everything.

Yeah, depending on the role, right?

If I work in the financial sector, maybe there is a central anti money laundry system in our bank, and I don't need to, I don't want to write it from scratch, right?

I would like to use it.

Yeah, just just use it in a safe way.

And now what we say, if we start looking at these, let's just say services as platforms, as internal platforms.

So on purpose, I give it the blue colour because in this colour coding, we show platform teams or platform groupings in there.

So we say, okay, what is really the need?

What kind of services are needed?

So the yellow team would be speeding up because they use this cloud in the right way.

And the problem is that we very often see that the cloud team is building something completely overscaled, completely inadequate for the needs of the engineer.

They don't just take me as I am.

This is what we've built, right?

You don't like it?

Go away.

And sometimes they go away, right?

Like this example that you raised, yeah?

But it is really important.

And I believe you can find lots of statements from Matthew Skelton, the co-author of Team Topology, saying that, you know, if you leave building this platform to technical people, they will very often build something too complicated, too big, first of all.

So we have this concept of minimum viable platform, right?

So, like, you know, what would be the minimum set of services that it's enough?

And believe me or not, a few weeks ago, I heard a story from one of the students in the Team Topology class who's very deep into platform engineering perspective.

And he said, well, yeah, I've seen that, you know, the platform that we've built was so complicated, so sophisticated, that even people inside this platform team were not exactly sure what some of the services are for, yeah?

And, you know, this is slowing us down.

This costs a lot of money, right?

And it's slowing down the people who like to use it, right?

So we say the good platform is the self-service platform.

The good platform is the platform that understands the needs of their customer, their internal client.

And it tries to solve these problems.

It provides the services which are, like, really here matching the expectations.

And, yeah, the smaller it is, the simpler it is, the better, right?

We don't need the whole, you know, big machinery behind maybe our use cases.

So just give us the use cases.

Provide us, you know, good documentation.

I don't know, video, tutorial, whatever.

So we will be independent, right?

And a lot of this extraneous cognitive load can be solved this way, right?

By simple things, right?

I also provide trainings.

And sometimes I provide these trainings, like, in person, for example, in Warsaw.

And we, after every class, we look at the questions, what people were asking about.

And we know that one of the training spaces is really too hard to find, despite it's like city centre in Warsaw.

So what we did is, like, we recorded a video, how to enter the building, right?

And everyone said, whoa, that's a game changer.

Like, how did you figure it out?

Yeah, it's like, well, because I come here, and every time I need to answer five phone calls, how to enter the building, right?

So I understand my customers, right?

And I want to provide them something self-service, like, okay, we are having training here.

Here's the video in case you cannot find it.

I want to go back to the platform example for a second.

I've been this year to the main trip in Design Europe, which is a very lovely conference, now hosted in Antwerp in Belgium.

And so happens to be that this year around, we had Gregor Hohpe visiting the conference and giving a talk on the first day.

And well, he's now very famous for the Architects Elevator topic.

And basically, he's dealing now with platform engineering.

And he showed it.

He described it over triangles, like a normal triangle and flipped with the top upside down, right?

So like this, yeah.

So basically, this situation where if we put infrastructure, structure and the platform engineering team from the bottom and the users on the top, this is a very unstable situation where we are under engineering and providing not enough support for our users.

So our platform is too simplistic, and we'll have a problem.

In the other way around, then we over engineer, like you already said, that even some users, some platform team members absolutely do not have a problem.

You do not know what the platform does, but it is somewhat stable.

Now, Gregor postulated a very, very interesting thing that the ideal situation for a platform in terms of being a platform is enablement.

So provide enough germane cognitive load for the capability to provide to get that germane load with basically then low intrinsic and low extraneous load, so that you could actually merge those two triangles creating something like a hourglass, right?

Well, yeah, something like that.

So basically, well, more of a like, literally, one on top of one on the other.

Yeah.

So basically, yes, like this.

So basically, you create a platform where you have a stable infrastructure, and then you are surprised as a platform team by your users.

What they can achieve because you gave them the tools to build something.

So instead of giving them capabilities with which they're frustrated due to intrinsic cognitive load or extraneous cognitive load, because they now need to suffer this platform environment, find information in a in something being a bad documentation or something.

Now they have an environment that is an enabler, so they can create new things with this platform.

And if your platform team is surprised by what users do, that would constitute a good platform.

Yeah.

Yeah, I'm not going to say I'm the expert on platform engineering.

I realise now that I used the wrong term because we call it like finished viable platform.

But yeah, I think it's still close to what you just said, right?

Like, I understand that, again, from a team member perspective, who is, you know, asking for a service from this yellow team.

I may want to just one simple service.

But of course, it could be a simplistic, superficial view, and maybe the platform should have a more stable basis, right, for security reasons, scaling reasons, whatever else, right?

So I'm not saying it's only this that, you know, that the smallest possible solution will be, yeah, making all requirements.

But a solution that's an enablement would limit those loads.

Yeah, still what's really critical is understanding the needs and having conversation here, right?

Not presenting services, take me as I am, but understanding that, you know, okay, for this team, we need this service.

And maybe the service is like, really okay.

But there might be a different team in our organisation, and they may have a different need.

And we shouldn't say just no, because we already provide service A, and we are not going to have a premium or B.

But really understand that we are, as a platform, this kind of servant role in your organisation, right?

Okay, we are necessary, but we are not here to, you know, force some policies, rules on others.

There's a very good statement that the good platform is the platform that, you know, the customer are, customers are like, you know, willing to use, not because they must, but because they choose, right?

So if I could have my own IT department and the shadow IT department, then I go to the first one because, well, they provide the right set of quality, whatever.

It's defining that, you know, my happiness factor of using it.

But to touch upon a quite important topic, that is, I think a very live one, especially this year in the DDD community, is because DDD usually stands for ubiquitous language as one of the basis of the whole movement and the whole field of the main driven design.

So building that common understanding of things and the commonality in language so that everybody understands within the same bounded context, the thing in the same way.

And I've seen that time and time again, that while we may be applying that on the level of solutions or business problems or business products, processes, this ubiquitous language often is not something that happens on the level of an organisation.

And this is also where these, this extraneous cognitive load kicks in heavily, because we can be talking about exactly the same thing, but because we're using different terms for the exact same thing, we create a complete disconnect and we're not able to communicate with one another.

And that leads to frustration, burnout and whatever else is there in a sense of those different problems, cognitive problems, cognitive load problems.

Yes, you're right.

And I see also the other end of spectrum when we use the same vocabulary, but we understand completely different things under the same names, right?

And I could say the examples that we just shown here are like very good examples, because when we say a platform, what people imagine is like software platform, like SAP, Jira, AWS.

No, we are talking about the service platform, like what do we provide you?

How do we enable you to do something, right?

How do we speed up your work, right?

If I had a case of working with, yeah, in a training with a group of people who are safe consultants or trainers, I'm not an expert on the latest revision of safe, but there's also concept of enabling things in safe, but the concept is really, really different under the same name, right?

Because here we say, I come to enable you.

You know that I'm going to go away.

I don't want to take hostages.

I'm not going to make you dependent on me, right?

And very often in the safe environment, I hear enabling things are actually things like infrastructure or DevOps or whatever, which are actually operating in this, give me a ticket, I'll come back to you once.

Somewhere in the future, yeah.

So instead of being enablement, they become bottleneck teams, right?

I'll put another, and if you don't catch that early, right?

I'll put you another example from a perspective of learning languages.

And you're absolutely right.

It's not only about using the same terms and words, because it's also about the semantic understanding of things.

Those words.

So we need to build a semantic dictionary of what we are actually talking about.

So that common dictionary, and that will limit the extraneous cognitive load.

But that takes a lot of intrinsic cognitive load than to do.

Yeah.

But just to give you an example, I was just before our stream, I went to the shop just to do groceries.

And while exiting, I met a language partner that used to be assigned from a nonprofit here in the Netherlands to my wife for her to train in Dutch language.

And we dive into a little bit of a conversation, and I told her what's going on in our lives, and she was very happy to see me, and I told her I'm beginning a new job.

And she said that in Dutch that there is this phrase, I didn't exactly catch the meaning, but it was like a very positive phrase, not maybe congratulating, but like hoping for the best of something like this.

And the phrase was toy, toy, toy.

And in my Polish brain, when I hear toy, toy, it's like, yeah, I already do not retain the meaning of that phrase because in my brain, it opens up a little bit of a box with portable toilets, right?

So yeah, toy, toy, portable toilet.

Same phonetics, same word, maybe different spelling, perhaps, but already the semantic meaning of the term made it completely impossible for me to comprehend what's going on in the conversation at this point.

And that happens a lot of times with companies using abbreviations all the time.

Like, what is MVP?

MVP?

MVP has so many meanings that when somebody says MVP to me, I'm like, I have no idea what you're talking about, because I know so many definitions of what an MVP is that you have to be more specific.

Sorry.

Right?

Yeah, yeah.

So, Karol, I will now do the segue to my Kanban.

Right?

So what I try to teach people is that if people come to more like more advanced Kanban classes, they are like coaches, consultants, whatever.

I say, remember, every time you hear we do Kanban, we want to do Kanban, we are moving into Kanban.

First thing, ask, what do you mean by Kanban?

What do you mean?

Is it just a board?

Is it a pull system?

Is it a method?

What do you want to accomplish?

How would you say that we reach this Kanban?

What's the success criteria?

Exactly.

Yeah, exactly.

And it applies to language, to enabling other things.

How would we recognise that we enabled them?

Right?

How would we recognise that we really did our job well?

Yeah.

How would we say that if we are the only cloud to use us, but if there would be another cloud, they would stay with us?

So, how would we really fulfil their needs because we really understand what our customers want?

That's a difficult one.

Yeah, and this is a good segue to this germane cognitive load, right?

Because take a look at this.

We somehow naturally moved into this area because if you are a tech leader, if you are an owner driver of a platform, then of course you basically repeat the same lesson inside your team.

Are my people skilled to build the platform, right?

So, do I have intrinsic cognitive load in my team, right?

Are my people facing some kind of extraneous cognitive load?

Because, for example, procurement and purchasing and licencing is a pain in the back in my organisation, right?

So, I know what I'm supposed to do.

I know what I should buy for my internal customers to speed them up or how do I do it in this company, right?

But we cannot forget and we want to focus on this germane cognitive load.

So, who are our customers, right?

What are their needs?

Do we have any signals that their needs will change in a quarter of a year, right?

So, continuously probing, right?

Okay, you ask for A.

You got A.

You're happy.

We see that you consume service A.

But, yeah, we shouldn't say A is like forever like this, frozen, you know, in carbonite and never going to change.

No.

What's next, right?

So, it's endless story.

And, again, just like we showed that, you know, it could be different in this team.

It could be different in this team if this is the end, this platform team, right, which provides something to our product team or streamline team or something like this.

I know while you were describing that, I was like in my brain analysing my situation, let's say, with bridging the gap and my team would have been bridging the gap because there's five of us now.

I'm looking at this this way.

Well, okay, we're doing a lot of research in the field of enterprise application integration because that's the mission statement within bridging the gap to enable our readers with tech agnostic, proper training and information about the field.

It's like, okay, this is this is a huge intrinsic cognitive load because we're getting a lot of information.

We're trying to classify that information properly, learning new things about the field that we haven't considered anyhow, and then turning that into the domain where we actually describe that as articles and do video elements and prepare training.

But at the same time, because we are working as an open source and after hours, this is more of a project of a passion than actual work.

We have a lot of extraneous cognitive load because all of us are working full time.

Most of us have families and I think only two of us don't have kids, but we have our families.

We have our own specific problems with, let's say, health, dealing with psychological health or trying to stay on top of things that the number of topics we have to handle.

So if I'm looking at this from a perspective of bridging the gap, we have a bucket full with extraneous cognitive load, a little bit of intrinsic and a thin layer of germane on top of that.

But because we're not doing this for profit and we're not earning anything from it, we cannot really do anything about the extraneous load.

The only thing we can actually work with is intrinsic.

And since this is mostly research, again, we cannot do anything about that at this point other than bring other people in.

And then on top of that, if we're doing initiatives like exactly this livestream, before doing this, I never streamed anything in my life.

So being a perfectionist and having ADHD, imagine how much intrinsic load I had just researching which streaming platform to choose for the purpose.

It's interesting to look at everything I do from this perspective because it's a completely different way of looking at things in terms of cognitive load and how big of a cost that is.

Yeah, listening to you, I naturally started drawing like a wordly map, so the hope for you and your initiative is that you say a few weeks ago, months ago, the video stream was completely new to me.

And as you can see, this is also visible for our users, so it's also relatively high on the other axis.

It's going to stay here, but it's going to move to the right, almost to commodity because you are now more proficient with it.

And I want to say that I often mix both Kanban and Team Topologies because for me, it is very compatible that we say, well, another factor that we haven't spoken about yet today, and maybe that's a good segue to your next guest because I know that you're going to speak to Aleix Morgadas soon.

It's also like a different perspective at cognitive load.

Don't throw too many things at the team at once.

So you cannot say you are supposed to take care of project A, project B, products, whatever, because naturally you're going to have a pick in everything that's related to skills, for example, necessary in all the projects.

So stop starting, start finishing, like Kanban says.

Take one thing and move it to the right.

And if you publish something, then naturally you start with this intrinsic extraneous germane, which is like this article, video, whatever you produce in the end.

And then we take another path from left to right, also from this perspective, and then we free up, let's just say, our capacity to, well, I don't know, automate whatever.

So we have more for this because we hopefully have under control what's red and orange.

And it's okay that the ratio of the colour changes, right?

Because like we said, if we are lifetime learners, then naturally, sometimes we are craving for red.

I can here give my personal life scenario.

I have this podcast, the audio podcast in Polish, Kanban Przy Kawie.

I started it as a passion project and I loved discovering, you know, all audio production software, right?

But is it really the best time investment from my side?

Probably not.

So after some time, it's been automated, it's been, let's just say, externalised to someone.

So I have time to work on, you know, inviting interviews for guests for the interviews, right?

Yeah.

So I had the same, pretty much the same workload around that.

I had no idea how to do proper invites.

So I was like experimenting.

I had no idea how to deal with video.

I had to start experimenting.

So that experiment, which was very, that very high intrinsic cognitive load turned into a very nice germane cognitive load, because now I have a template for all invites to the live stream with a nice graphics and a nice backstory.

And I just then change just a few, tweak a few things so that they just go correctly, right?

Same with video.

If I would do YouTube shorts, which I'm going to do from this live stream as well.

Now I have a template ready in Google Vids, so I can just paste in the specific piece of video.

And then I already have transitions in, I already have some graphics in, I just need to cut it, paste it, see if it works, add a commentary and publish.

And it became more of an automated process, because it requires a lot less attention from me than it used to.

I don't have to relearn it because that's already a skilled game.

So it's in that sense, it's a journey of discovery.

But for that part, I didn't have that much of extraneous load because I just did the research and it's good.

But in general, if we're looking at the whole picture of bridging the gap, for example, the extraneous cognitive load is humongous in our work.

Yeah, so again, contextualising, for example, certain processes is something interesting then.

And I thought about it like, okay, how to wrap it up, right?

Because we covered these types of cognitive loads.

We covered some strategies about approaching the intrinsic, approaching the extraneous yet not being happy that we don't have to remain cognitive load, because we should have it.

And I think it's good to wrap it up that we started with cognitive load as a definition and how to recognise that it's there.

I know that there's this academic argument, if it's there or not, if it's applicable to teams or not.

Now what comes to my mind is like a quote from my favourite writer, Philip K.

Dick, who I believe wrote in one of his books that reality is something that still exists even if you stop believing in it.

And I believe this is with cognitive load as well, right?

You may not believe in it.

You may pretend that it's not there.

You may argue, right, if it's the right name for the phenomena.

I'll argue as a big fan of quantum physics.

Okay, it's there, right?

If you call it this way, if you name it differently, that's your choice.

Just don't have it in your blind spot because it's going to hit you.

You as an individual, you as the team, you as the manager or leader of organisation.

So it's good to be aware of it and understand it.

Where are we with it, right?

And creating this kind of simple visual like we just did here.

Okay, what kind of problem now we have in this team, what kind of deficits, what kind of challenges we have in the other.

This is the first step to define some action, some strategies against it.

And yeah, it's always also going to be there, the good type of cognitive load.

We are not going to get rid of it.

But yeah, if we're not going to do anything about it, then it's going to be this kind of anchor, be this kind of hiccups.

You could get rid of it.

Just do nothing.

Yeah.

Okay, joking.

No, like seriously, what would it mean that we don't have it, right?

It means like, you know, our company, our professional growth, our even existence as a human being is gone.

It's done, right?

Like, okay, if the company goes into bankruptcy, yeah, you don't have cognitive load.

But still, maybe some lawyers have cognitive load.

We will not get rid of cognitive load because we still need to think about things and produce things as human beings, because you would have to be in a vegetative state not to have cognitive load, basically, in that sense.

And even then, some people might argue that the brain is still functioning because you still think, or you still dream, at least, let's say, which would mean that you still exhibit some sort of a cognitive or, let's say, subconscious, maybe, but that also could be considered.

So as far as that there's a joke, I mean, yeah, it's a joke.

But yes, cognitive load would be then always, it's a matter of balancing which type we experience more.

Exactly.

I think that's a very, very good takeaway for the end of this particular stream.

Now, to be fair, we'll be coming back to cognitive load in a, in September, because we're having this live stream with Aleš soon enough, that's not going to be that far away, just a month away.

So we're going to be then talking more about measuring that and diving a little bit deeper into the science of cognitive load, which is going to be probably something also very, very interesting to see.

Because right now, if we're looking at companies that are mostly measuring performance, I'm a huge fan in that sense of measurements, I'm a huge fan of what Simon Sinek says about performance, that we should also start measuring trust.

But looking at cognitive load, we should also start measuring this more actively, because while trust is basically important, this is a very important thing to be able to recognise and manage the cognitive load we're doing, because that might be actually a destructive force in our work.

Right.

So, last chance for the audience to pop in with comments, questions, anything, we have a, it looks like Sim was still watching us.

Great.

And yes, redundancy hits hard.

That's true.

And yeah, if we put value in the things we know, instead of the value of our capabilities, then yes, well, we should start shifting the value a little bit else.

So so that that is a very, very, very valuable comment there.

All right, just the last few words, then, and I'm going to move to a to a slide here before we say our goodbyes.

So, next up, in pretty much a week, we'll be talking about publish subscribe, that's even from an architecture.

So we're shifting the topics back to tech and architecture.

This time around, I'll be joined by Adam Lee from Solace.

He's a former developer advocate, and now he went back to being a solutions engineer.

That's going to be quite an interactive session as well with some really fun examples.

And, and I think Adam has a bit of a game for us if we will have people in the audience willing to play, all based on publish subscribe.

So that's going to be a probably fun thing to do.

And lastly, if you're still with us, and still listening and watching, hit the QR codes.

You can read about enterprise application integration, which was not the topic of today's stream.

Bridging the gap, we have some articles touching upon various aspects of working in it in integration, you can subscribe to sub stock where those articles will also be based on an RSS feed or a subscription based newsletter, and also subscribe to the YouTube channel.

So you can get notifications about new streams, new topics that we'll be handling.

All of our live sessions are on YouTube as well as LinkedIn.

Well, today, luckily for us due to a technical glitch, we're actually not on LinkedIn.

Sorry, LinkedIn.

That happens from time to time.

I'll investigate later what actually happened because restream is saying we're streaming on LinkedIn, but LinkedIn says, ah, so subscribe on YouTube.

That's a seems like a more stable platform for watching.

And if you're watching us on the recording, well, tune into another live stream so that you can actually participate.

Ask questions, comment on the topics.

And going back to our video feeds.

Radek, thank you so much for explaining cognitive load.

I think the examples you gave really gonna hit a well and land with some understanding.

At least I know I'm educated better on the cognitive load and the different types of cognitive load right now.

And I know how to I know better how to apply this knowledge on my daily struggles as a specialist or a father or husband.

Definitely going to be something something useful there to watch for and manage that better.

Yeah.

So hope everybody enjoyed the stream.

And Radek, any parting words?

Last piece of advice?

Thank you very much for having me.

Yeah, it's great that some stayed with us and we see comments until the very end.

So hope it wasn't boring.

If you're more into this topic, definitely I recommend watching next stream with Aleix on cognitive load because I had the privilege of watching him with his co-speaker at the Fast Flow conference in London.

So I know that he's really practically into topic of measuring cognitive load.

If any of the topics that I presented today are interesting, you know, just type in Radek, get in touch, leave some feedback.

I'll be happy to hear.

Thank you very much.

Just to just to give context, the stream you're mentioning with Aleix is on the 10th of September.

So near a little bit more than a month.

So at this point, I invite you all to join that stream.

And thank you all for being with us.

Thank you for joining and see.