Loosely Coupled - Understanding Cognitive Load

Good morning, good afternoon, and good evening, everybody.

My name is Karol Skrzymowski, and I'm your host today for another episode of Loosely Coupled livestream by Bridging the Gap.

Today, I hope you have some nice beverage and a little bit of a clear mind after days of work, or if you're watching this midday, hope you have a slow day today so we can dive into the topic of cognitive load, and we're going to be having a conversation about how cognitive load influences our work as IT teams.

I think that's something worth exploring.

Joining me today is Aleix Morgadas, who is an engineering strategy consultant and ex-CPTO at Temperature, and Aleix has more than ten years of experience in tech and specialises in engineering strategy with domain-driven design, team topologies, and worldly mapping, which I have no idea what that is, but I'm certainly going to ask Aleix later about that.

So, he's been sharing his real-world experiences on his personal blog on Substack, and at conferences, and now he's joining us today to chat about cognitive load.

Hello, Aleix.

Hey there.

Thank you for inviting me.

Happy to have you here.

So, cognitive load, that's a broad topic, I suppose?

Yes, it is.

Depending to who you ask, it will be very different responses, so looking forward to debate about this.

All right, Aleix, let's start off with you telling us something about where you're coming from, what you're doing, and why cognitive load?

Why team topologies and all those things?

So, what I do or have been doing for the last years is, of course, I started as a software engineer.

I have a computer science degree or a background, so I have been developing for a lot of years, and at some point, I decided to start in management because of two reasons.

One is, in order to influence how the organisation works, usually, you need to be in the room where decisions happen, and often, that's a room that was at least on the company I was in for managers.

So, I was interested in more like, okay, how things happen and how we can influence where ideas originate instead of being buried in the end of the delivery process.

So, that is kind

of my intrinsic motivation, and that decision about being more involved in the beginning,

it meant that I had to learn about product, about business, about a lot of disciplines that were not

mine, and one of them was strategy, about how we can make better decisions with the limited

information, and that's kind of how everything started, and at some point, I just had to start

sharing my learnings because I thought that, okay, maybe it's only me, so I started sharing some of

those, and some people got interested, so that kept me motivated to keep sharing, and I guess by

sharing, I learned way more than by doing because usually, you have to think about, oh, I understand

this.

You try to put that on a post, and you're like, okay, I don't understand this completely, so you need to push yourself to learn more and more about things, and, yes, that's a little about myself.

I mean, I definitely shared the teaching-learning mindset.

I found myself that I learn a lot more by teaching others in my specific field of application integration, especially with my ADHD chaos in my brain.

I know I have the knowledge, and I can use it, but the moment I need to teach it, it basically is brought to structure, and then I realise, like, oh, I don't know this.

I need to fill the gap.

I need to find the answers.

I need to put more into there, so do research, because I cannot teach that because I don't know this aspect of my work.

Oh, that's interesting.

And that's because we're, through experience, we're basically exposed to a limited number of factors, not the whole thing that is a field that we work in, and that's also very interesting that, in IT, we stumble into other fields like psychology, which is exactly where cognitive load originates from, right?

That's correct, and, indeed, we sometimes use those concepts.

It's true that we are not psychologists, and sometimes we overuse those, and we shouldn't in some cases, but at the same time, we found them useful for driving actions or driving improvements, right?

So, at the end, it's like, hey, maybe we're not 100 per cent accurate based on the

psychology theory, but at the same time, we're like, okay, we're understanding where it comes

from, and then putting in a way that is actionable, that's really where it can help us

to make this happen, and you mentioned where this everything comes from, and you mentioned

team topologies, and it's true that team topologies influenced me a lot.

Indeed, I have been sharing a lot about team topologies and how it helped, not only in cognitive load.

I think cognitive load played a role.

Today, we will talk about it, but I guess that what it helped me,

what I liked back then in 2020 when I started reading and trying to apply some of the concepts

is that this is your main approach, but also that it was very different to other books I read

before trying to apply which is very US-centric, and I found a book which is more European value

centric, and I like because the authors are from the UK, from Portugal, so the good thing is that,

okay, this is another kind of vision I felt more related to the approach that they were describing,

and one of them were how you apply cognitive load to understand that if the team is exceeding

their capacity, and how you can use that as a data or information to make your decision making more

taking the humans into account, but sometimes, we forget that we are all like it's about people,

right?

So, that's the moment when I realised, okay, this is interesting.

Let me bring this because we focus way too much on systems, and it was missing the human point in the equation about socio-technical system at the end, right?

So, a lot of things together that are connected on how you add more points of view, or it helps you to shape better your decision making at the end.

Yes, that is very true.

I find it that we as humans, we have a tendency to oversimplify things, and that's the modelling tendency of model everything.

We do it subconsciously, basically, because we need a simplistic version of life to exist and cope with it.

If you would understand everything, that would be definitely too much of a load on our brains to comprehend and be able to work with, so we simplify things, and then we have biases, and then we have problems of all sorts of manners, including also understanding how people actually work in different environments, which is, again, something we will be touching upon today.

And I find it also baffling at times that in this lovely day and age of generative AI, and all those lovely co-pilot improvements, generative code, architecture as code, etcétera, a lot of companies are striving for speeding up, like drastically speeding up delivery and processes, and I think they forget often about that human component.

I often saw posts online on various media about the 10x developer, and that doesn't mean what it originally meant.

It meant, like, we're going to limit the number of people in our organisation because now we have AI, so our developers can actually deliver ten times faster, which is probably measurably not true, in essence, but that also ties into the velocity of a team and the capacity to deliver, capacity to process information, etcétera, right?

There is, you mentioned already, we went already on AI thing, and I will be honest, I don't have enough data to make claims on anything.

At the end, it's like, since we see things, tendencies, or other claims or expectations on how this will work.

So, based on my limited exposure to this, because I'm not having all the data for all the companies, I'm sure that big companies trade different to small companies, but seeing things like, if you are a smaller company, you do more things, therefore, you have a lot of context switching that is adding new content.

It's true that maybe the AI helps you to have more nuances in something, but before, maybe take you two hours to do something, maybe now take you one hour, but the context switching between topics, for example, I'm doing a web page on this, meanwhile, I'm doing a blog post, meanwhile, I'm doing a, preparing a talk, right?

So, it is like, now you have three contexts, maybe the AI is helping you a little on each of them, but now you have more content in your mind.

So, in terms of cognitive load, you have way more because of the context switching.

But now we just imagine that we only focus on, you are only a developer, you need to do more things.

Before, we were, all the industry were moving from big PRs to smaller steps to small increments, and sometimes I see a backward step, because now it's easier to create more code with less time, now I see way more bigger PRs, I'm like, are we repeating the same mistakes again?

And then it's like, how do you review this?

It will be an AI reviewing it, or it will be a human now, instead of reading 20 lines of code to understand the change, now it needs to read 200 or 1,000 lines of code for the change.

And that's now, again, more cognitive load, because now you need to understand the change.

And the problem is, when you ask the person about, why is this, because the person didn't write it, it is like we're missing communication, because now we have three parties, at least, it's like me and you, and us and the AI.

And in terms of, I don't remember right now this image that this is about the connections, if you have two people, now you have one line of communication, you have three, you have the explosive communication.

So just imagine a team of five, that each of us is using AI, so now it's like, it's not five of us, it's 10 of us.

There's 10 people, 10 agents, all of us following information and not sharing all the information.

It is even worse in terms of the explosion of things that are happening on each team.

So I'm not sure, or at least my intuition says, we will go slower, because as humans, we cannot process this amount of information.

If we need to, you can believe the code, but at the end, the system will tell if it works or not.

And usually, we're still working in a deterministic world.

And that deterministic, it means test, it means specific things.

And I'm still to see, the more code you have, the more variables you will have in the prompt or in the tokens or whatever it's in the input, and the more context window, the more variability on the output, and so on and so forth.

And I will close here, which is the models.

So the people, we pay per input token and per output token.

So sometimes I'm thinking, these people have the intention or the incentive to give you more code, because the more code they produce, the more they charge you.

So sometimes I'm like, hey, they want to give you duplication of code, or not having the right distractions, because they will be able to charge you more per prompt.

So at some point, I'm like, I don't know if we have the right incentives.

Yeah, that's evil.

That's kind of evil.

I'm not saying they do this, but the incentive is there, right?

True.

It's like with certifications with different companies, right?

I've seen somebody post some time ago that we were passing, the person was passing some sort of AWS certification.

And that person actually had robust experience with AWS and cloud computing.

And they were asking about a specific use case, what components would that person use to build it?

And he, because I was a guy, he answered truthfully to his experience, because he knew which components would be the easiest to implement and least cost and the most manageable for this particular use case.

Of course, the answer was wrong, because the test was not testing the knowledge about cloud computing, but it was testing how you conform to the marketing of the particular cloud platform, right?

So there's always this risk that we're not only introducing more context and more load onto us and teams, but it's also risk of introducing a lot more bias in the process.

That's true.

Bias that is you don't know where it comes from, and it can change, because if the model changed tomorrow, maybe it comes with another assumptions about topics.

And I mean, I come with an automated design background as well.

And what happens is like, hey, the language is super important.

And delegating the language to the LLM is like, be careful, because you're delegating the ubiquitous language to be defined by the external.

And there is one thing about human design, which is the core domain is unknown.

You need to discover, you need to define it.

And LLMs are trained on known data, which by definition means supportive or generic subdomain, which means you don't get money on this, because it's already done.

So what it can produce the LLM, it's known area, which therefore cannot be core.

So we are using LLMs to create core domains, using...

And it will produce known subdomains, it will not be able to give you the space.

And that is still how you can collaborate with domain experts, and how you deal with users.

And of course, you can use AI to summarise some calls.

Yes, you can use it, but be careful on delegating thinking and critical thinking to LLM, because it will give you, it will move from how you need to trade uncertainty and learn and feel and iterate into, hey, this sense of, oh, clarity, because it will tell you what you need to know.

So it is always, just be careful.

Or tell you what you want to hear, because they're trained to be helpful and not critical, for example.

And that's another level of cognitive load that we're getting into, because we need to check the outputs all the time.

If I use a generative AI for any number of purposes, without putting in my content, whatever that company may be, transcript or text, written text, whatever, and I try to work it in my specific field, most content in enterprise application integration is content that is paywalled.

AI has no access to sources that would be credible, which means that it hallucinates instantly, and I have to check every single output, which, again, increases the amount of work I have to have every single time.

Let me do one step back, because I want to do some concepts, because cognitive load, we can get into the details about the difference between cognitive load that influences us.

And I will give you now the argument,

and now I will give the explanation, because one thing is true is that maybe you have cognitive

load about interactions with people, and you can heavily reduce that by, I don't want to

have a conflict with you, I don't want to make all the effort to talk with different departments,

and that is sometimes unpleasant, like, oh, I need to go through the same topic three times.

Okay, let me talk only to the LLM.

Of course, here, there is a reduce of cognitive load.

The question is, like, maybe that was needed, and now we are losing soft skills, because instead of having conflict, now I can avoid it and delegate that to LLM, and that can be a possibility.

But I say that is because cognitive load, or at least how we learn it, was thanks, was thanks to team topologies, and what happens when you get into team topologies and cognitive load is that you rapidly find a wall, which is what is intrinsic, what is extrinsic, and what is germane.

And each of them, we can say that germane is about the domain complexity, the inner thing that you want to solve, and then you have extrinsic, which is about the environment you're in, the tooling, and, for example, how to make things work, like CI, CT, things like this, and intrinsic can be seen as a code.

That's at least, if I remember correctly, how the code, the book says.

And then each of those examples could be a different type of load for a different person in the organisation.

That's right.

The thing is that then you move into, at least, I want to be specific, I move into this book, which is cognitive theory, you read it, and you say, like, ah, it's hard to apply in a real world.

It's true.

It's very hard.

And I am not able to fully analyse the impact.

So, usually, what it moves from is, like, I cannot use cognitive load per se, I use a proxy thing, which is developer's pain, or developer experience, which is a good kind of touching the same things, but not in the same way.

And developer pain can be, okay, we don't understand the problem, we don't understand how to communicate with other teams, we don't know the responsibilities.

So, there is a lot of things that can influence the cognitive load at the end, because when you ask a developer, how is your load, they can say, it's a lot.

They know it, they feel it, or it can be super low.

But then you realise one thing, which is, if you ask a person why it's high, it's like, oh, it's because I need to give five talks in one month.

Of course, let me help you reducing your cognitive load.

Let me reduce the amount of talks you give per month to one.

It's like, no, no, no, because I like it.

So, it is good cognitive load, because it's what they like to have.

At the same time, it was talking to another developer, okay, what's your cognitive load?

Oh, it's very low.

Then it's good.

It's like, no, no, I'm thinking about changing job, because this is not challenging.

It's like, okay.

So, the cognitive load is depending on the context.

So, you cannot measure cognitive load and not have a conversation.

You can have it, measure it.

You can assess it, or you cannot have, like, it's two or three.

It's hard to put that kind of level of numbers to a person.

But you can give, like, okay, this is the area that we can talk about.

This is causing cognitive load.

Then you need to talk to people to understand if it's good or bad.

Because the number is half of the picture.

You need always the human conversation.

As far as I remember, an individual, in terms of team topologies, is not the lowest point of study.

It's actually the team that's the smallest object of study.

That's right, because at the end, you want to understand at the team level instead of individual.

It's true that you need to talk to individuals, because as people, we will signal what is happening, and it will help us.

And then, let me show briefly the screen.

Yeah, sure.

On this.

This is a product I was building with Manuel Pais.

The thing is that, here, is that Laura, she designed a way to understand cognitive load into four clusters.

She has a PhD on this area, and she's very good.

I was super happy that someone was working on this in a way that is actionable.

So, for people watching or watching the recording, so you can follow on a different screen or open it up.

This is the link to this particular page with the four clusters of drivers that Alex just opened on a screen share.

So, if you'd like to follow us on a different screen or visit this page later, you can just find it over this QR.

All right, cool.

Going back.

Yes.

So, the thing is that, at the end, is, hey, where are the cognitive load coming from?

And it was the task characteristics, team characteristics, work process and practises, and then work environment and tools.

And it was like, I feel very related because, of course, you can have cognitive load about the complexity of the task.

For example, I don't know much learning, but just if you ask me much learning, hey, you need to do a new algorithm on AI recognition or whatever.

I'm like, okay, my cognitive load will go through the roof.

But at the same time, what happens in the team lab?

What happens if you have way too many stakeholders?

What happens in the work and practises they've done are coherent and we miss them, right?

So, a lot of the things that happens to us that influence our cognitive load.

And she was able to get into a lot of them, like problem definition, solution alignment, and it was a task complexity, contextual complexity.

And I was reading this.

It's like, oh, that's super true.

Like, we have too many team members.

Maybe the teams are too big.

Maybe we don't have the right skills and we need to have handovers.

Maybe we don't have clarity on what is our role, which is my responsibilities, right?

I am in the right.

So, there's a lot of things on processes, consistency, maybe the piece, maybe the performance.

It's not clear.

So, I wanted to briefly share this because at the end, when we talk about cognitive load, we have a lot of dimensions.

There we have several, but it's like, you need to talk to people to understand which is the area that we need to talk.

And AI impacts in some and helps others.

And the thing is, like, we are moving the problem somewhere.

We are not solving everything.

We are moving the problem somewhere else.

And maybe before, as a PM, you needed to talk to a developer to do a query to get some data.

And now with a cloud or open AI or whatever, now you're able, you're autonomous, and you don't need another person to generate a report.

Super.

You improve your cognitive load.

You reduce the interaction.

It improved everything.

But then there's another part that they are not good enough, right?

So, AI, as I said, it's helping in some areas and making things worse in others.

And AI, sorry, cognitive load can help us to identify where we are going south.

And because it's lovely to see, like, if you see snapshots of the teams and you see a team that before AI, they have, it's not only AI.

There's a lot of things that influences a team, right?

But let's assume that AI has enough impact to see a change.

You can see how it changes across the organisation.

And then you can see patterns like, okay, we implemented AI, and now this cognitive load improved a lot, but this other went to the roof.

It's like, okay, how did this happen?

And then you add things like another system metrics, like tickets or bugs in production or donor metrics.

And through the conjunction of all of those metrics, you then have a hope, a picture of how your organisation evolves through time.

This reminds me of an interesting study.

I don't really remember which company was that and when exactly that happened, but I read about that, I think a month ago or so.

A company replaced their call centres with AI IVRs.

So basically, interactive voice response, right?

Mm-hmm.

And apparently, they moved all the complexity of that interaction, basically back to the users.

They have decent statistics over customer care and handling complaints, cases and whatnot.

The moment they implemented the replacement with AI-based IVR, complaints skyrocketed.

They quickly backed out of AI IVRs and went back to having a proper call centre because the complaints of the callers with not properly handled cases were just skyrocketing.

I think that's a very nice example of where that load went into in that sense.

They basically increased the cognitive load of their customers in that sense.

That's true.

I don't remember the name, but sometimes I'm happy that someone else did the test.

Unlucky that it affected people because I believe that you can do the same test without firing people for a month because it took a month of data to understand the impact.

So it's like you can do the same thing, route the traffic to the half of your users, the other half of the current employees, and then you have a fallback in case this doesn't work.

If it works, then it's a nice use case.

But we are oversimplifying what is the work of customer success, or I don't know which was the part, right?

Yeah.

As I say, I like that other people do these kind of very crazy tests so we can learn from the outside without having the impact, which is a good thing.

The other part is like, hey, we underestimate the complexity of a lot of things as leadership.

Sometimes we think, oh, we understand better.

No, we have another vision, and that's the combination of multiple team members, multiple teams, and dimensions that we make a good product or good experience for our customers.

We understand way more.

I remember a lot of cases like people like able to detect in the tone of voice on the things, they're able to connect with other staff, and they're, oh, I understand.

Oh, I remember a conversation with another colleague.

I understand how he comes from, and then they're able to make the connection.

That in AI, maybe in the future, but I still don't see that we are able to get into the point.

Based on the current context windows, because it will be, just imagine the context window size of our mind into a machine.

We are still way more than the other.

I think we'd have to invent things like arc reactors from Iron Man to be able to increase that context window sufficiently enough, or some other infinite source of energy, because currently it's already a cost of energy that is overwhelming at times, and it's difficult to increase that, scale that.

That's true.

Sometimes I'm like, try things.

It's good.

We are experimenting.

Okay.

I will say I'm a follower in some degrees.

I'm like, hey, I'm using some stuff, and others are bets.

I know that people need to do huge claims, because at the end, they need to raise money, and that's a game they are playing.

Yeah.

So we need to understand that they are doing this because they want to build a company, and maybe they don't do at the end, and maybe just get half, but that's already a product that can serve a million of users.

Happy about that.

But sometimes I'm like, had those crazy visions.

I'm like, are you sure you're doing this for the product, or to get money to do something else?

But at the end, I would say that if people can share the learnings, even though they fail, we can learn a lot more together on this space.

But going back to different interactions between people in work environments, it kind of sprang a thought to me, and I never considered that in this particular way.

Some time ago, when I was preparing to give a class at O'Reilly, I stumbled upon, in my preparation and my research on integration architecture, I stumbled upon Tesla's law.

Tesla's law being mostly used within the user experience space, stating that's a law from somewhere in the 80s, stating that every problem domain has an inherent complexity that is irreducible.

We can build more complexity on top of that, but the inherent problem domain complexity is irreducible, but we can move it around.

And the question is, who is going to handle that complexity?

So, in the case of Tesla,

that was an interaction between a human and a computer, or a piece of software on a computer,

which means, should we spend more time developing the software to handle the complexity of the

problem domain, for the user to spend one minute less on the problem themselves, or should we move

that complexity to the user, so that the user, every time they go into that software to use it,

they spend one minute more solving their problem, right?

And I think this is somewhere also there in the human interactions that we're having, also with AI, also related to cognitive load, that law kind of rings true as well, especially delegation of tasks and delegation of the context.

I relate a lot, because I sometimes I can spend six hours in trying to automate a one-minute workflow.

And you get, I mean, and sometimes you are that manager at the end, you say, oh, I will do a tool that is like, use Excel files, that does the job, and you handle the complexity yourself, and that does the job.

It's more load on you, but sometimes it's doing an application that only works in your domain, the applicability is that low, that the cost of doing it and the others doesn't pay off.

And in terms of human resources or processes, sometimes it's only about replying emails.

I relate a lot with this.

And it's true that as, for me, I have a way to understand if I have too much cognitive load, which is, I think it's called in English, brain fog.

Brain fog, yeah.

You're like, and I detect this when I'm working, it's like, it's Wednesday.

I thought we were Tuesday.

I'm like, oh, I didn't remember that I lost a day.

Or I lose information, that before I was not losing it, because I have too many things on my head.

And then I need to go back into writing things down, because otherwise I forget about stuff.

I get that when I work in different languages, because I constantly operate in three different languages, because I speak Polish at home, English at work and Dutch at work or outside of my home.

So basically, at a certain point in time, my brain goes completely foggy.

And I don't even remember how the word I want to say is in any of those languages.

It's just like, oh, dictionary shut down.

It's like, what am I trying to say?

What is that word?

I know that I feel the concept of that word in my brain, but I cannot express it at all, because I'm lacking the...

The same thing, I would have the same thing.

Sometime when I was working in the office some years ago, it happened to, at some time it was working.

And then I went into the metro station, and I don't remember going out from the building and going into the metro station.

And so maybe I replied to people in English, instead of Catalan.

Like, I need to switch everything.

And that's for me, the level of cognitive load that I'm like, I start to be concerned.

Well, starting not, I will be like, okay, I need to slow down.

Maybe my way is to go to vacations or this and that.

But the important part is that when we use the term about cognitive load at work, what I try to use is a way to understand what is really causing cognitive load.

I say this because people usually, we complain about one thing.

And as that thing becomes a topic, I will, for example, say, we blame JIRA.

And now everyone has been blaming JIRA for a while.

And now it's becoming a thing.

And what is really happening is not JIRA, is that we have 10 stakeholders changing priorities, and JIRA isn't able to deal with the amount of that is happening.

But JIRA is where things are materialised, but the problem is somewhere else.

It's symptomatic, basically.

Sorry?

JIRA is the symptom, not the cause.

Sometimes it's a cause.

I would say no.

But it's true that the symptomatic is like, okay, what is this changing?

And then you try to overuse a tool for the wrong purpose.

And then you need to have these conversations which sometimes come with conflict.

And what happens with cognitive load, or at least how we design it in temperature, is that people are missing what is causing them cognitive load.

Because we're trying to say, oh, my problem is the architecture.

My problem is that these API changes a lot of the time.

So, I need a portion of the architecture with an anti-corruption layer.

It's like, okay, you're protecting yourself from what?

From a human problem, and you need to try and solve it from a technical problem.

And I think Fran will like this.

It's like, we try all the time, fix things through code, but the problem is human.

So, I found is that with cognitive load, in how the first book about topologies is trying to solve it, I think in the second edition, there is some more, they expanded the things on cognitive load.

I think the second edition is coming this month, or, so, it's coming this month, and then maybe you get it in October.

And there's way more information on cognitive load as a thing.

So, I lost a little.

So, the thing is that, yeah, there's a lot of things in my brain.

Cognitive load, overload.

Cognitive load, overload.

So, take a moment to think about the next sentence, and I'll just pitch in on the human problem.

We just had, a little bit back, a live stream on data mesh versus application integration, which is not a thing.

It's not versus.

They are synergetic.

And there was a lovely statement there that, basically, tech is never the problem.

It's always the humans.

And that reminds me also of the lovely talk by Andrew Harmel-Law at DDD Europe 25, so, this year, where Andrew put in a talk stating the second hardest problem in system architecture, or software design.

I don't really remember that.

That was variability.

So, Andrew went through that talk for, like, 50 minutes.

Lovely content.

Absolutely great.

Great topic.

And then somebody in the audience in the Q&A asks him, okay, Andrew, what's the first hardest problem in software design?

And he was like, oh, yeah, I didn't mention that.

All of you!

Humans are the hardest problem in software design.

And it's always that.

We're actually facing organisational issues.

We're facing relationship issues.

We're facing just human problems.

Communication problems.

We're not facing tech problems.

Tech problems is, I think, in my personal opinion, a really small percentage of the problems we're actually trying to solve at work.

Most of them relate to human problems, or problems created by humans.

Not tech, per se.

I sometimes use tech to relax.

Like, okay, there's let me do a little TDD, and I solve a couple of use cases, and that relaxes me.

So, not me to reduce cognitive load, I just need to code.

But human problems, we say, like, understanding the customer, and there's a lot of other things.

Because at the end, and we sometimes we don't like this, but customers, you cannot tell them, buy me.

Right?

So, you have all the things about profit, that is things that you cannot control, and cost is everything you control.

So, that's people focus on what they can control, which is their employees.

But that's the wrong place to focus.

Because what you need to do is help them to try to understand why these people are not buying, right?

And now I'm able to cycle back about cognitive load and human.

Which is, for me, cognitive load helped me in two ways.

One is, as a leader, I'm able to understand how my organisation is evolving.

Like, if I have multiple teams, each of them are different.

So, you cannot compare team to team.

Because all of them are unique.

But the tendencies, you can compare them.

It's like, okay, these teams are improving, but this one is getting worse.

Like, what is happening here?

Right?

So, tendencies, you can kind of inform you if you're doing a good work or bad work.

But the other thing is that by how you assess, you cannot measure, I will say assess a cognitive load.

Is that you, by doing the questions, you help people to understand their problems better.

That's the thing about people blaming Jira.

And the problem is that they have ten stakeholders, right?

So, what happens is that because each team is unique, they share, like, oh, my problem is this one and this is very specific.

And you, when you're head of engineering or you're in responsibility, and you hear each team being quite different to each other, there is no way you can invest to help them all.

You need to put the responsibility back to the team because it's a team specific.

But when you start giving them the names or the patterns or the cognitive load areas, and you see, like, oh, most of them score high on team complexity or problem solution definition.

Then, okay, here is an area that I can invest and do a cross functional investment to help multiple teams at the same time.

So, you move from unique and specific that you need to get, and probably you've happened this to you, which is it takes you three months to understand, oh, that's a problem.

Because you have, you need to talk to a lot of people, right?

When you start, like, measuring cognitive, assessing cognitive load and you start seeing these patterns, instead of you going blindly to all the teams to having conversations to at least identify where is the problem coming from, because you need to create a relationship so people can talk to you about the hard problems.

Nobody wants to talk about the hard problems with a person that they just met, you need to create a relationship.

So, what happens is that if you start creating this shared language about the cognitive load, people start to, oh, my problem is not this one, it's this one.

And then from team to team, it's like, oh, we have the same problem.

And then you start creating this shared language, shared awareness, then you're able to say, oh, we can improve on this area, and then we can assess if we are actually improving.

And that's a use case, I think, that's a use case we did at Creditas, a company that was applying a lot of the concept about topologies.

And we succeeded quite well, locally, in a tribe, because it's very hard to scale that manually.

Indeed, temperature was borne out of the need assessing cognitive load at the scale, and it's doing it fine if you are more than 10 teams, because if you're less than 10 teams, you should know which are the team problems.

But when you have like 500 developers, everyone with the same, their own thing, you need to create the shared language, and that's when it works.

So, you basically went domain-driven design on human interactions.

Kind of, because context patterns, I hope this is called context mapping, on domain-driven design, tells you a lot of information about systems.

Sometimes I'm missing the human part, and that's when team topologies was helping.

It's like, okay, this team is interacting with five teams all the time for a year, and these systems having these things and trying to protect from what?

Okay, the problem is human.

Sometimes the problem is different.

It's tech, and then the human has the consequences.

But you are able to pair the two views on the same problem, and then you're like, okay, I see how moving things here change things there.

And we cannot be naive about being like, I do a change, and then there is a consequence, because this doesn't happen in complex systems.

You try to nature a change, and you hope for the best, that it will have the nice intent, and then you put some wire traps to understand if this is going in the wrong direction, and my wire traps are going to flow.

It's like, I want to try this change, and then instead of waiting three months to a person to come to me saying, hey, this is blow up, everything is on fire, you start noticing that this is not in the right direction, then it's when you take action.

I say this because when you're head of engineering or director, maybe you are five people until the teams.

So I always say, like, the team members need to realise they have a problem.

Then they will bring that into retrospective, if you have retrospectives.

So imagine that you have every two weeks.

So let's assume you have the best case scenario.

In two weeks, you notice that the team level, they will report that to the tech lead or the DM.

They will try to fix it first.

They will not.

And then they will escalate that, and by the time the information reaches you, it's three months in.

So cognitive load can help you, like, if you created a bad decision, you want to see it as soon as possible.

And of course, you need to have a good culture about psychological safety, people sharing the issues.

But it's true, like, people want to solve them first, and they don't want to escalate it next day.

But if you start seeing, like, multiple teams noticing this boost on cognitive load, you need to intervene.

That's basically, you basically described something we joked about being the mushroom theory for directors.

I don't know if you ever heard the joke.

This is a joke about, well, very bad management in that sense, being that a good director is like a mushroom, kept in a basement in the dark.

Yes, kept in the basement in the dark and fed with manure, right?

So the level of information that actually reaches the management, the top management, is very limited.

Some studies say it's about 4% of actual problems that happen that get to that level of management, which means that you have not implemented a good feedback loop to actually measure what's happening in your organisation.

Sometimes it's impossible, sometimes you need to delegate, but then again, somebody needs to make those decisions.

It's very hard, because if people are able to solve this by themselves, it means that they have the right tools, so they don't need to reach you.

So it's a good point here, which is like, you delegate enough, and you empower, you delegate decision making and authority to lower level, and then you're able to solve that at that level, super.

It's a good job.

And the problem is that the things that are not solvable at that level, how things reaches the top, and of course, don't shoot the messenger when the information reaches you.

So it's very hard.

So for me, as I said at the beginning, I was a developer.

So I was having TDD, CICT, trunk-based development.

So it means that my feedback loop moves from seconds to hours.

As a manager, it moved to days to weeks.

And then as a head of engineering, it went to months to quarters.

I can only imagine people like CEO or CTO is like, I'm sure that they are working quite blindly, to be honest, and hoping, like, providing information and sometimes hoping for the best.

And also, that's why I went into strategies, like, I want to understand how people make a strategy.

I noticed that not much strategy.

There is more like vision and hope, but not actual ways to communicate.

And having this feedback loop about, you have this intention, you have this bet, how you notice that you're going in a good direction.

If you're lucky, you'll do this once a quarter.

I saw many companies doing this once a year.

So everything I do is about how I can do faster feedback loops as a leader, regardless of the organisation size.

And there is no one thing.

There is multiple things you need to do together.

I saw people doing this programme manager, management thing, where they tried to create the standard reporting structures and having this kind of people in between teams that they're able to move information around.

That's a way to try to solve it, to be honest.

It's human-based, which we need that, because it's through the humans and connections that we are able to flow the information faster.

And of course, when you are a developer, you're like, oh, my God, my tech lead all the time asking me for a report faster.

Let me code.

And when you become tech lead, you're like, come on, my developers, just please let me know what is going on, because otherwise you need to be talking to each of you to get information, to have this structure of reporting working.

So there's a lot of tension between things.

If you don't report, then there's going to be a lot of move to tech leads.

Indeed, I will tell you that in Temperature, the people that came to us were two kinds.

C-level, that they want to understand what is going on in my organisation so they can invest on the teams.

And the other is tech leads or agile coaches that they understand there is a problem, but they are missing data to prove that there is a problem.

Okay.

So both top-down and bottom-up, basically.

Yes, both.

And usually, the cognitive load ends at the tech lead.

Below, usually, they don't have that many, because the people that manages all the cows, they try to control and make it good, it's this person.

We are burning managers super fast.

And with the AI thing, a lot of this burn is moving into the managers.

And of course, as senior developers or developers, we have cognitive load and there is madness.

But I saw a lot of people really pushing to protect the teams from the cows.

Sometimes I'm like, be careful, because you're burning yourself.

And when you end up burning and you need to leave, you will burn the team anyway.

So try to find another way to make this sustainable.

That's also kind of like scrum master role, right?

The scrum master is there to protect the team from influence from outside, taking on all the cognitive load of managing all those interactions.

Yes.

Sometimes I'm changing opinions all the time.

Before, I thought, oh, good managers are able to shield the team from the cows.

But sometimes, hey, we don't need to protect the people, they are adults as well.

So we don't need to babysit a team.

Because then we're surprised that the team is not mature enough to deal with some news.

It's like, you are 25 years old, 30 years old, you need to, come on, this is real life, right?

So you need to be adult in certain situations.

So there is a level between, hey, you don't need to expose cows too early, so you need to do that.

But be careful about babysitting too much.

So I sometimes I'm like, in extremes are not good, just be okay.

Because at the end, it's like you want to signal or create awareness within their condition that there is a problem.

And sometimes I learned that the best way to signal that there is a problem is let things burn.

And okay, now it's everyone's problem.

And then people get enough.

If it's important that they burn, sometimes you don't need to let things burn.

But sometimes, hey, there's a lot of cognitive load.

Okay, and let it burn is, okay, let me go on vacation two weeks.

And this will refer to things.

If I come back and nothing happened, okay, it was everything on my mind.

So I was wrong, which is good.

The second is, okay, it was a problem.

And now we need to signal that this needs to change, which is also good.

Right?

So that's the way I had to signal.

And that's good for me, because then I don't burn up.

So going on vacation is very important on vacation.

That's the use your PTO.

Yes.

So that's the thing.

We're getting a lot from cognitive load.

We're touching a lot of things.

Yes, yes.

You know, I do love the aspect of letting things burn.

I used to have a colleague in consulting when I was working for PwC that said this lovely phrase that turned into a meme and a background in many laptops within the teams that worked with him.

We are all consultants.

We all love a good dumpster fire, because that's where we as consultants come in to fix things.

And this is where we do the work.

So basically, we ended the project with me sending him a miniature toy dumpster fire with a tea light in it, just sending to the London office for him to have it as a memorabilia after that project.

But basically, that turned out into a lovely meme with the fire starter girl, like with the exact quote with his name on several laptops.

And this burning is for consultants is amazing, because then we have a problem to solve.

This is our domain.

We are consultants.

We want to solve problems.

We want to help clients.

But for a lot of people, that's the problem.

That's the cognitive load that they're suffering from.

That's the problem then with retention of employees.

That's the problem with retention of customers, etc.

Yeah.

And this was quite interesting.

We had in Temperature, we had one of the clients we worked with, which is we assessed eight teams.

They shared some patterns.

We understood that this was needs to be solved.

Six months later, same kind of loads, no improvement.

When you then you say, okay, what is going on here, because they know there is a problem, but then you realise that the problem is not solvable at the team level.

It needs to be solved at a management level, because otherwise, they will already solve it.

And then you analyse the cognitive of management.

And we sometimes forget about management cognitive load.

And then you realise that they were overloaded in many areas.

It's like, of course, they don't have able to improve, because if the people that have the tools or the authority to make the improvement, they are overloaded, the organisation cannot improve itself.

So it was quite interesting to say, we sometimes focus a lot on the team level, which we need to, but there is a lot of supporting structures that need to help them.

At some point, the supporting structures are burning.

And it can be the management, but it can be also platform teams.

Platform teams that they need to help streamline teams to get less who thinks about their cognitive load.

Then you create another platform team.

But the thing is that these people that are supporting, if they're burning, be careful, because if they burn, they are supporting a lot of the structures.

So be careful, because if they, for whatever reason, they break in whatever area that may happen, it will have a huge impact everywhere.

As the same way they improved everywhere, it doesn't work, it has a huge impact everywhere as well, right?

So we found that assessing the quality of the platform teams, enabling teams, or agile coaches, people that have a supporting structure is key to understand if the organisation can improve.

And the same thing about HR, you need to understand if HR is burning, or customer support, or recruitment, every area is like, hey, everyone is, maybe you have a huge attraction.

It's like, okay, we need to replace this.

But then you assess the cognitive load of the people, the people management team, and they are burned out, because they are trying to retain people, they are unable to, and then they also need to start sourcing, and fast, because you need to, before that person leaves, we need a replacement.

And if that is not healthy, you will also have a problem, right?

So I see the cognitive load is helping you to, it's a healthy check about your organisation.

And sometimes we are blind on some areas, until we just hit the problem, it's like, okay, why is it happening here?

And then you change your focus as leadership from product development, about serving the customers, to sustain the company.

And I think that's one of the main problems.

You are sustaining the company structure, and not focussing on helping people to create value, or capture value.

You're already in a bad shape.

It's an interesting analogue there, that popped into my brain.

So basically, if we're looking at software, well, we're building software to support the main business goals, and the business of the company, right?

So this is like the core, using the domain driven design nomenclature, the core software.

For that, we have the support software, and we have the generic domain, where core and support are important, because we're basically building that to drive the business.

But then you have the generic domain.

And if you don't have support, proper tools to build that software, if the generic domain would be your ID, your copilot LLMs, your HR software, your Slack, Teams, Office tools, whatever that may be, right?

If that fails, and you're wasting time on figuring out how that works, because it's not intuitive, you're wasting your processing powers, right?

And same would go into then the organisational structure, being an analogue, that you just mentioned, that of course, we have the teams, they're driving our business.

But then you have all the support there.

So HR, your management teams, your L&D, your recruitment, whatever that may be.

And if that's burning, then they will not be able to support your teams.

They will not be able to give proper tools to those teams to deliver, which means that those teams will suffer as well, and they start burning as a consequence.

But their burning as a consequence is a symptom, not the cause.

That's the thing, that sometimes we need to understand that they are, when these people are burning, you need to understand, of course, and sometimes it will be the cause.

But usually it's like, you need to understand how everything else is causing this.

Sometimes that the CEO and the CPTO or the CPO or the whatever in the top, they don't get along for whatever reason, and that cascades.

And it happened to me in big organisations like, why this request is coming from here and you didn't know?

It's like, oh, because it has a different report structure, people don't talk about it, and then it clashes at the end.

And then you need a lot of work at the bottom to resolve the conflict and mediate everything.

And the problem is somewhere in the end, it's like the symptom is here, the root cause is somewhere else.

Sometimes we think that there is root causes, sometimes they don't exist.

We sometimes are like, oh, there's a root cause, complex systems.

You don't know what things causing what, you need to try multiple things until some of them work.

Sometimes it's just the combination between the different things that cause a problem.

They're not the problem themselves, but in combination, they become a problem.

And sometimes you need to, we are naive that we think, oh, there is this cause consequence, and then I can do this and do that.

It's like, no, you will try to do the best to intervene and then do multiple things at the same time, and some of it will work.

And I will cycle back this idea about generic and supporting things and AI and control and profit and expenses on the organisations.

So companies, they cannot control profit.

They can only control cost.

True.

And what happens with cost is like, oh, if you are in Europe, we have good labour rights.

So you cannot fire people because you want.

But what you can do is like, okay, well, let's stop paying providers.

So the move is, instead of, I will stop paying this generic subdomain, and I will have my developers that because they cannot produce new features to create new revenue, they will create features to reduce the cost.

So now instead of externalising feature flags or externalising this and that, now I will integrate it and try to reduce that.

The same thing with moving outside the cloud.

I will reduce my bill on the cloud and then I will pay to having an on-prem.

And I will not say that all of those are crazy decisions, but hey, now you are focussing on reducing costs, which usually on the long term, it doesn't pay off.

Because if people start, instead of firing, I just imagine you have 50 developers and you say, oh, I don't need them or 100.

I don't need them.

I only need 20.

What happens if the competition next to you don't fire them?

It means that they will be able to produce five times more than you.

And instead of focussing on one area, these people are experimenting way faster.

So sometimes you need more runway because you're a startup, you're losing, and then you need time to market to heal.

And then you need to make those drastic decisions.

Fine.

You need to survive because you're a business.

But sometimes I'm like, hey, where are you putting the focus?

And sometimes we are seeing the focus in cost reduction and custom building generic subdomains or yourself.

I'm like, you don't need that.

You don't know the cost of maintaining.

And then you start creating software that does two things.

One is the cognitive load for the software that needs to create value.

Now all the cognitive load and context for the software that needs to run the company, which is different users, completely different user sets.

You're creating another product internally that is available on the market.

So your context will explode.

And of course you can have the hopeful mindset or naive approach about thinking that, oh, it's a couple of lines of code.

And don't get me wrong.

LLMs are good and generic subdomains because that's what they are trained on.

So I'm sure that they will be able to get into a workable solution fast.

But the problem is that the last 20%, that thing is not available.

It's not public.

So you will need to figure it out by yourself.

And that's where the cost resides.

So again, that moves.

It's the same thing about creating more cognitive load.

And then you need to maintain software on maybe hope.

Sorry.

But you also go into moving that cost inside.

So you outsource that.

You have those tools outsourced to whoever is your supplier.

So basically the complexity and the cognitive load related to maintaining that or building that or providing support was outside.

And now you have a certain set of developers.

You maintain that because you want to reduce costs, but you want to maintain your staff.

But basically you're moving that complexity back inside.

So you're dropping the cost on the supplier side, which is the monetary cost, which is your OPEX, CAPEX, whatever that may be.

But that's not the only cost.

That's just budget.

The cost is also in the workload that you need to handle inside.

And this is where we create that cognitive load.

And we are having that on those teams that we already have, which was your finite number of let's say 50 developers that were supporting your business.

But now those developers are now supporting your core domains and your generic domains and your support domains, which means that you added a bunch of cognitive load onto them.

And not only in the way of, okay, we can wing it with AI copilot, which are trained on the generic domain, but we need to still figure out that 20% that you mentioned, right?

So we're actually adding that load into that mix of already somewhat loaded with germane and extraneous and intrinsic cognitive load.

Yes, I totally agree.

The thing is that I, for me, I'm more like an externalizer than a buy it myself.

I always try to, hey, if there's an option on the market, use that because it will, everything which is generic, it will give you speed.

So you can focus right off there, right?

But it's true.

This decision is happening.

And from a finance perspective is having a stable cost, which is developers have these variable costs here.

What if I move this 40,000 a month cost?

I remove that and I move it inside.

From that perspective, maybe it makes sense, right?

Because at the end, it's like, hey, we are unable to create more value.

We are not capturing users.

So we're focussing more on reducing that and you're using the developer team to focus on reducing that.

So I could understand the reason, but for me it's a bad reason from a cognitive load perspective.

Yeah, because looking at, let's say you have those 50 developers and you devote part of them, let's say 10 developers to handle the generic domain.

That is outside of the scope of their understanding.

They were handling your core domain, your support domain, which they understand because they understand your business or your problem domain.

And now you're dropping them into a different problem domain, which is running the business, not the business itself.

And there's a lot of then for that, that will be what?

A lot of intrinsic and extraneous cognitive load basically, right?

Before it turns into germane.

Yeah.

No, I mean, problem and solution space, you need to start over things.

But how many times did you see this?

How many times people created their own future flag system or their own?

I mean, this is happening already in some organisations like, oh, I can do it myself.

Sometimes I hate dev tooling as a company because there is always some team in a company which when they're big enough, when I mean like a thousand or 2000 developers, that they will have enough resources to say, okay, I can build it myself instead of externalising.

Because it's only a survey with a couple of things like try it.

So this happens more often than we think.

I mean, I see that in my field being enterprise application integration.

We have a lot of vendors that already solved certain problems in that space by creating software that is reusable with building blocks, which is composed what we need to deploy it and it's running.

But a lot of companies, because of the licencing costs of that software, the integration platforms, etcétera, they figure, oh no, no, no, no, hold on.

We're not going to pay them for the licences.

We're not going to pay for that software, which is in my case, that's usually the supporting domain, not the core domain.

So we're not going to pay for that software.

We're going to build it in Azure, for example, or build it in AWS.

So basically what we're doing is now we're building an integration platform using either Azure Functions or AWS LabDOS.

So basically we're putting hard code skills into the mix to build them because Azure Functions and AWS LabDOS, they don't have the building blocks to support application integration.

So we need to reinvent the wheel and build those blocks ourselves to support and build an integration platform from scratch.

The amount of work, the amount of cognitive load that goes into figuring out, okay, how did those integration platforms actually work?

What did they support?

What did they do?

What libraries do I need to build for the Azure Functions or AWS LabDOS to support that?

What language do I use?

Do I write it in JavaScript, Java, C++, C Sharp?

What's going to happen?

How do I choose for that?

How do I figure out what's supposed to happen there?

So there's a lot of things happening.

So things that can happen is the team thinks that they can do it faster and cheaper.

Sometimes it's like, hey, it's fair.

If you want to do it, you do it yourself.

I found sometimes that people say like, oh, we will do it ourselves and we will create a protocol on top of it that we will sell.

It's like, what?

That's not reasonable, the consequences that go to market and things.

So usually it's like why people like to do these things internally when they are supportive is that when you see more complexity, let me, you know, context mapping?

Context.

No, I give up.

Let me, one second.

Because it is easier to make it.

It is the canvas, which is the canvas.

Bundled context canvas, no.

Core domain charts.

There you go.

Okay.

And this happened to me in the past.

So what happens when we are in the core is that the more complexity and business are high, at the same time, the uncertainty is quite high.

And we don't like uncertainty as developers.

We want things that are specific.

And what are the things that are specific in supportive engineering?

So we find some kind of, we can do a good job and a good architecture and a good testing on things that are known.

So there is a kind of, so I saw a lot of companies, not, but some teams that are like, oh, I like to work on, so this happened in my company to me where we externalise the core domain and we did the supportive.

Why?

Because a supportive has one trait that is quite good, which is it is way more predictable than a core domain.

Because you can get into the things, you know the things, the data is there and you have experts and you can define it and it will be done.

Maybe they fail for one week, but it can be done.

The core domain is not.

It is uncertain.

You will fail.

You need a lot of things.

And if you are in the wrong company and you have blame culture, the supportive is a safe bet.

You can do a good job on time, good architecture, good looking code.

It will be done.

The core on the other side, it will be messy.

It will be changing requirements.

It will be the focus of the business.

Therefore, we will have a lot of attention on a lot of opinions.

So in some degree, I understand why people maybe want to do that supportive because it gives that, hey, I'm doing a good job in terms of coding, not in terms of business.

But I can understand some of those.

When you are in some tough organisations, maybe that makes sense.

The good thing is that if you have a good organisation with a good learning culture, instead of seeing failure as a failure, but as a learning opportunity, you can learn a lot and enjoy doing a core domain and talk with people.

At least I will give you this.

At Creditas, for example, one thing that was happening is that the collaboration was very tough between people because everyone tried to do their best.

We were in remote.

We didn't have a way to co-rate that we're using.

So what we did was doing a training on event storming to define problems.

And the good thing is that it started from engineering, but we also trained PMs. And then the PM and the engineering team, they were collaborating on event storming instead of only talking.

So we moved the collaboration from people talking and JR tickets into mapping the user flows, using event storming, instead of waiting for the designer to do the things on Figma.

So we boosted a lot.

And at some point, we joined some collaboration between teams and they all were using event storming as a shared language to communicate ideas.

So it was a way to, okay, how people were starting to get along super fast, because we reduced the cognitive load on interaction because we created a shared tool, which in this case was event storming.

Choose whatever you like.

I mean, for me, it was great because we had some people that like it and got traction and it become like a thing on the company.

But the frustration about not understanding how a core domain evolves, because usually things like, oh, you decide this and maybe next week it changes, but then you don't communicate.

And then the other teams notice one month later and everything breaks.

You solve that by having a shared mirror board with all the flow.

And then people are able to go inside and there's this nice view from mirror that says, things that you missed since last time you saw this mirror board.

And you're like, oh, what is this flow?

And then you realise like, okay, there is this command, this event, this risk, this node.

And they're like, okay, I understand everything.

And they become able to talk like, hey, I see you are mentioning this.

And they chat in Slack like, hey, did you take this into account?

Oh, no.

Oh, yes.

Okay, cool.

And that is how we solved a lot of the pressure on cognitive load domains.

It's about communication.

And this is something I'm touching upon in terms of design of interactions between systems as an architect.

This is also why I love event storming or domain driven design to bring all the people into one room and create that shared language.

But that does not happen as often as I would like to.

So basically, if I look at it from this kind of a traditional perspective or waterfall perspective of design, it's like, okay, we have our business.

Our business talks to the business analyst.

The best business analyst tries his best, her best, their best, basically, on understanding the business and translating that into requirements for the architect.

The architect then talks with that business analyst, tries to understand that and translate that the best way to design the technical requirements for the dev teams to implement.

The dev teams, they tried their best to understand the technical requirements and implement what the business wanted.

So on that alone, we already have one, two, three levels of assumptions being made.

So we're already increasing the complexity by making assumptions because people rarely understand that they made an assumption and they rarely validate is that assumption actually true.

It takes actually a lot of self-awareness to see that I'm actually assuming things, not checking them.

And then the load over time, the load over those levels.

And then if you're in a blame culture, that's a problem.

The load over those levels, the sheer cognitive load between those levels that it's created on the end of the chain of the waterfall being the testers or the user acceptance tests.

Why is it this way?

It doesn't make sense.

It doesn't really correlate with what the business wanted, what we wanted as users, what's going on.

And then of course, somebody gets blamed and usually the developers get blamed for not doing the job right.

But basically we have a level of assumptions where we created complexity.

We created cognitive load that wasn't handled through the design.

Wow.

You open a lot of things at the same time.

All right, go.

So the thing is that usually I haven't been in a company that has a huge blame culture.

I think most of the companies have been, they're good.

So there is sometimes lack of how to handle conflict that if you don't know, then you can interpret that as a blame culture.

But usually when you have good soft skills and then you understand conflict, you can turn those conversations into productive, improving things.

And I will be honest, most of them, I feel quite safe to speak up.

Or at least I have been quite lucky to be in these companies.

But usually it's that when you say most of the time it's developers, usually it's because we, or I found that sometimes we're lacking soft skills.

And usually people are very, that have these influencing skills, they know how to handle the stuff.

And it's not that we kind of get the blame because we don't know how to defend ourselves or how to put this conversation to a productive way.

So, but as when you learn people, I've never been in a company that people don't want to make things right.

It's about, okay, let's learn about this.

So I, people is always, I always had very kind people next to me on, and we were able to solve it.

Of course, there are some very exceptions, but I would say there are a lot of very things.

People usually have good intentions and they want to actually solve problems.

A hundred percent.

Sometimes people are- But they don't have the skills to communicate that and the language to communicate that often, because the language difference, the language barrier, if you don't do the ubiquitous language, then- And sometimes English is not our first language.

So it's another addition into the problematic.

But the thing about you said about the business, the business started with an hypothesis.

If you're in a B2B, probably the business has quite understanding about user needs, because usually they are experts in the field.

But if you're in a B2C, usually the domain experts are not the business per se, but this is how you try experiments.

So usually the company you are in or the market you're in will shapely who's the domain expert and how you create value.

But let's assume in our case, we had in a B2B setting, so therefore the business were quite domain experts.

And I will be honest, the VP of business, she was amazing.

She had a huge vision on, she really made it and created a really great product.

But what happened is that instead of giving problems, because we were late, we had a lot of dynamics that sometimes we're making things slower.

They said, okay, how we can help them go faster.

So with the good intentions, they give backlogs.

They try to make things as narrow as possible so we can implement things, which is good intention doesn't work in software because it's how we understand the problem.

It helped us to, because, hey, they assume a lot of things, how they work.

And even though with a good intentions, maybe in software complexity means way more complex.

And this is often, it is true because there is no software and we don't know them.

So by the good intentions, we create a problem.

So how we turn this around, and it was not with Evan Storming, it was with Lean Inception from Pablo Caroli, it's a workshop this one week.

And we said, okay, how we can involve them into the definition instead of they telling us on the quarter what to do.

So we ran a workshop and said, we need the business.

So we need you and product on these two sessions on Monday.

We only need you three hours.

And the rest with your information, we will run it.

We started during the workshop.

They stayed for the rest of the week.

We're loving this.

It's like, because the developers were like, oh, we don't understand this.

And they loved how people were interested in the business.

And they had like, oh, we thought developers, they only wanted tech.

But indeed, this team is asking us very interesting questions.

And we are dealing with a lot of things.

We are sharing them.

People is super active on the conversation.

And people is able to put all the unknowns or decisions into one place.

And at the end, everyone felt that, okay, we know what we need to build.

And we know what is risky.

We know how we will release this.

And everyone was happy.

So we move into we being told by us changing the dynamic into very collaborative thing.

And all the cognitive flow as understanding the problem, communication between people was reduced by putting everything in the same room and adapting the workshop to the business, not the business to EventStorming.

So that was key.

It's like, EventStorming, sometimes we want to force EventStorming.

But people saying like, oh, you need to talk in the past events in sticky notes.

It's like, what the hell is this?

Sometimes it doesn't work.

So you need to put everything there for like, hey, tell me your business objectives, which is the features you want.

Tell me the features.

Don't talk about that.

You can talk about this.

The product needs to do this.

Great.

To which user?

This user.

Okay, which is this user?

Oh, this user is the owner of the account.

Okay, what do they need?

Oh, well, they need this and that.

Okay, great.

How this helps the business?

Oh, they don't have the business.

Okay, can we just park this because it's low impact on the business?

Like, yes.

Okay, let's talk about the next thing.

And having everyone together talking about this, oh, it was enjoyable.

And this thing become a norm.

And then on the next following, it was like, oh, it's happening in one month, we have the quarterly planning.

Two weeks earlier, okay, let's have the conversations.

Everyone was involved.

And that's how you reduce again, by changing the environment.

And like, yes, that worked.

Otherwise, I will try something else.

So I would say that a lot of the conflict happens because of conversations or the lack of conversations.

So focussing on that give way better results than trying to focus on what you mentioned about this person gives a hand over a hand over.

Yeah, it's like, don't do that.

Put a room, everyone together, talk.

You need to know how to facilitate.

That's true.

This opens a another drawer in my head.

It's like, oh, are we actually talking about Conway's law here?

Yeah, in essence, in a certain sense, this is Conway's law, the way that the way we structure our system, the way we build is a reflection of the organisation communication.

So if we're developing shitty software, it's a reflection of how we communicate in a sense, right?

Or how we divide and where we have frictions is also how we communicate and design.

And if we ignore Conway's law and put two or three teams on the same repository, there's going to be friction.

If there's no proper communication, if there's no proper dismantling of the cognitive load that we create by putting three different teams on the same problem space or same code or same domain, and they do not cooperate properly, and we do not manage that their cooperation, or if we do not do the reverse Conway manoeuvre to adjust how we communicate to what we're trying to achieve.

Yes, what I will, it's happened at way too many levels.

Because first, the people that were communicating was PMs between them.

So by that already creates a bias about what will be done.

Of course, then what happens is that if people don't like to be part of the business conversations, then also creates a structure about how things will be done.

So in order to that, we need to do multiple things.

One was changing the hiring process.

It's like we need people that are product-minded developers, people that like to talk.

So how we solve things is like, instead of the product manager talking to the business and then getting requirements and then talking to the tech lead and the tech lead assigning work, no, no, no, no.

You senior or you meet developer or junior, we always say junior, you need to go with another person, but you need to be part of the conversation.

You are the future lead of this.

And you need to understand all the business requirements, understand the trade-offs and then communicate for the rest of the team.

And this is the expectation.

It's like you need to communicate this part.

There is one bad consequences about working like this, which is not very friendly for people that are in the spectrum.

Oh, yeah.

So be careful because not everyone needs to be safe.

There is people that don't feel comfortable on this.

So don't force these things.

But if they are not in the spectrum, it works quite well.

Or at least it worked quite well for us.

I'm sure that some people will say like, no, in this case, it didn't work.

Of course, you are right.

These are individual assessments, basically.

You need to always take into account that everybody is different and they have their own way that their brain works.

Exactly.

So I'm sharing my experience and it will not apply in yours, but if it works for someone, I'm happy.

So these work quite well.

And then we start talking between teams.

Because before, sometimes change happens or whatever reason.

Oh, I remember.

Before, the things happened in DMs. So people are like, oh, why did this happen?

Oh, this person told me like, okay, stop this communication because we're we will concentrate everything to the PMs. So you try to solve a problem about information being missed from people to person or person to person by concentrating all the information into the PMs. And also because of reporting.

Yeah.

So the problem is how you solve that.

It's not forcing everyone to go through PMs. It's like talking in a shared channel so that you have all the information available for everyone else.

And again, good intentions, not good results, and not challenging the approach, and then you can improve it.

So we solve this like, hey, we create open channels.

Everyone else that is involved in our team can post things on Slack.

And that's how you have the information radiation.

Everyone is informed.

And then again, you talk to the people.

Please, if you go through PMs, you redirect people to the private thing, and then you reply things there.

Or if this doesn't happen for whatever reason, you'll copy paste or do a screenshot, and you post it publicly.

Right?

And that's how we also improve the cognitive load on people because the PMs, those teams, they were overloaded.

And of course, they cannot have time for the developers for explaining things, because the reporting it was that high.

And moving all the information around and coordination that it's when they were unable to do the actual work, which is explaining the domain and what needs to be done in conjunction with the developer.

But then you land up with a different cognitive load problem.

If you share everything in open channels, perfectly fine.

You avoid all the DMs everywhere so that the information is out in the open.

But then basically you create an information overload on every single member in that channel.

And then if you have multiple channels that people are watching or added into because you need to have access to that information, then people start to go crazy about, why do I even need that?

Why do I need to be in there?

Why do I need to get those pings every single time?

Why can I just leave that channel?

And then you get people, instead of doing their work, they are looking at those channels because somebody pinged in that channel.

It's like, what is this again?

And then you can go overboard the other direction.

We solve that in another way, which is because we do pairing.

We did pairing back then.

So we did two things, which was quite interesting.

This tool is not longer available, but it can be solved with another tool.

But it was called Around and it was acquired by Miro.

But you can be done that with Zoom as well, which is as leaders, we stay as available as possible in a Zoom channel with breaking rooms or whatever.

And everyone is in that, in breaking rooms, working in pairs.

And then for example, you have three pairs, meaning you have two developers in each pair.

There is one pair assigning to add new things and one pair assigning to supporting.

So the only people who need to look at the channel is the supporting pair because they are doing supporting work.

It can mean things like doing refactorings, improving the system resiliency, supporting other teams.

So the other two pairs can focus on delivery.

Right?

So they can just like, okay, we just do this feature.

We share knowledge and we go.

And if it's not a huge incident, the supporting pair will do the job.

And because you have dailies and you have a rotation, all the information is shared quite approachable, I would say.

So that's how we solved that part.

Of course, this works because we have pairing and we have trunk-based development.

And we followed a lot of accelerated practises and team topologies principles.

When you reach this level of engineering maturity, that's what happened.

If you want to work with a Kanban maturity model, I am loving this because I'm a Kanban maturity model.

Do you know this model?

I haven't worked in Kanban that much.

I'm usually forced into a twisted version of Scrum for whatever reasons.

It never is Scrum.

I'm a trained Scrum master and I haven't seen yet a proper use of Scrum in any organisation.

So it's very interesting.

We're having sprints, we're having all those ceremonies, but they're actually not related to anything.

So instead of people and people and people, it's processes, processes, processes.

So at times it's very weird having that load.

Yes, Kanban maturity model.

Yes.

So this is part of, I always share this on my workshop on engineering strategy because I love this one, which is I use this one and say, hey, when you are in a team that is in a level zero, which means that they lack order, they're poor and stressed, they're unpredictable results and full of heroics, of course you have a lot of problems.

But as you make more, you start maturing and you move from lack of order to emerging processes into some point you manage demand, you have consistent end-to-end process, almost no heroics and short delivery times.

When you reach this level of maturity, and this of course is through talking well with improving the processes, improving the architecture, trying best development, good engineering practises, reducing errors, or at least one error is acceptable.

The same error twice, it's a problem.

Three times we have a huge problem.

So you have this thing about, hey, we have this problem, let's improve the systems or how we work so it doesn't happen again.

And if you repeat this enough, after three months you are in a good shape.

So that's what we did.

Every time we found a problem, we see how we can solve this.

And a lot of this maturity was driven by team topologies principles, but a lot of them where we didn't start with team topologies principles, we started with Accelerate and all the DevOps principles about running it and drug-based development and pairing and testing and how this is called this product mindset.

And that's how we reached this level of customer-driven.

And I say this level of customer-driven because moving from this to here, I was able to drive most of it.

Because you are improving things as engineering and you can do a lot of things.

But moving into customer-driven, you need product to be involved and design.

You cannot do this.

So you start having this collaborative collaboration with multiple, instead of having handovers, you start collaborating and you start seeing good things.

And we ended up after, this took us a year.

Maybe it's not this, but we moved from here to here in four to six months and here to here in one year.

And we were moving into feed for purpose at some point, but this took a lot of us our time to get here.

But again, it was a constant effort into how we can improve a culture about improvement on dedicated improvement.

And of course you're saying, hey, I have six developers in one team and I will dedicate two only on improving things.

Okay.

Just saying like, just telling you that you have three schemes of improvement.

You have three lines of work.

You're telling me that you are taking the 33% of it into improvement.

I say, yes.

But then you see the results.

It's like, oh, we are getting results every day.

They are like, fine.

Of course there is a section that then you meet everyone to do something, but all of that and say, hey, which is the cognitive load?

What is causing cognitive load?

Is this, okay, we need to dedicate things to make things happen.

It cannot be about, or at least it will frustrate me a lot, which is we identify there is problems to be solved, but then you do nothing about them.

I am an engineer.

I cannot do that.

It's like, we need to do something.

It doesn't mean that we need to stop everything.

It means that we need to do a little improvement so next time it's less painful.

And it was a combination of detecting the Dora metrics, some cognitive load, some team topologies, principles, things like, hey, you're collaborating with all the teams all the time.

This is not a good sign.

We need to move to something else.

So we need to, I like this a lot.

We need to collaborate.

So we stopped collaborating.

That doesn't sound intuitive.

Because usually you, at least 2020 was a year where collaboration was good.

Like, oh, you need to collaborate because collaboration is good.

And the more you collaborate, the better you do job.

It's like, no, you don't want to be collaborating with 12 people each day.

At least I'm an introvert.

The less people I work, the better.

So I need to work with the right people in the nice moment, but not with too many people because it will drain my energy.

So it was also like kind of my introvert nature trying to pull like, okay, can we kind of reduce the amount of collaboration between people?

Thank you.

So that instead of telling people how to use API, can you just send an open API schema and that's it?

Yeah.

I'm not, I'm an ambivert.

So basically I'm a bit chaotic in that sense, but 80% of the time my behaviour is introverted.

So leave me the hell alone.

Well, 20% of the time in mostly in social interactions, I'm perceived as an extrovert.

So basically I stumbled into something like this recently.

This is my social battery.

I love it.

And I have these on my team's background at work.

So I basically changed the background depending on how my social battery is.

So if it's charging or depleting, and what is the state, and basically during conversations, I just go like, I'm going down here.

I heard that the person that introduced me to the concept was, is the neurodiversity community leader at Capgemini where I work at, at the moment.

And she was like, I was in a conversation with my manager and during that conversation, the slide, it's sliding the spin down to zero.

It's like, oh, you can do that?

Oh, okay.

That actually is great.

So yes, collaborating.

Okay.

You got me.

Good indicator there.

Yeah.

That's another one.

Amazing in that sense.

But this all, all of this basically over collaborating, under collaborating, it all contributes to some sort of cognitive load, good or bad.

It's a matter of finding that balance, right?

It's knowing when you need to collaborate and when you're not.

When you are having a good collaboration, usually as a manager, you are in constant collaboration.

The thing is that all the team is in constant collaboration, but you need them to focus.

Sometimes you need them to be isolated so they can really focus on something.

Maybe they need to be exposed.

But I think how I see it is that things are changing or we need to adapt to each context and you need to constantly reassess, hey, I am doing the thing that is having the most impact in the organisation, whatever that means.

It can be, because it can be focussing performance or it can be focussing on unlocking a huge critical project.

So you will need to be constantly asking yourself, I am here and I should be here or I should be somewhere else.

And sometimes it happens that I, as a head of engineering, there is a critical project and sometimes you need to go very down into one thing.

And sometimes you need to be careful because like why this person is here, right?

So you need to be very communicative about why you need to be there and you shouldn't say, sometimes that can be perceived as micromanagement if you don't explain the reasons, but you still need to be there.

It's like, even though you can say that this is critical, so I hope you understand that I'm trying to do my best on the situation that's there.

Feel free to tell like, hey, Aleix, we understand, but we think it's not the best formula, but for what we want to achieve, let's change that and do it in another session.

I would say I'm happy to do that as long as we are doing this because it is, I'm saying this critically, it's not like, it's not optional, but I'm happy to do it in another format or this is a good format.

So I'm part of, I'm happy to do that.

But I'm sure that also having big bosses in a room of a very low team that also creates cognitive load and stress on people.

So you cannot do that all the time, right?

Because, and you shouldn't be doing that while you are there at all.

No, it needs to be specific.

But I say that because it can be, it means that you are in a very deep thing, or maybe you're included in a very big meeting with a bigger leadership or high level leadership.

And you need to adapt.

There is this book about the elevator or architect elevator.

Oh yeah, Gregor Hall.

So it's like, hey, sometimes the same thing in leadership, like sometimes you're talking about one year strategy.

And next thing you're talking about very specific thing in a complicated system that is key for, if that fails, everything else will fail, right?

So you need to adapt yourself into it.

And this is causing cognitive load because the context switching as leaders, it is constant.

You need to be, you need to get used to this because you don't have, or at least you don't have focused time.

I, or I said, the thing that they miss the most being a manager is not listening music.

It is like, I need my music time.

And I need to be this on sometimes what it is like, oh, let's for anything.

Like, nope, I will go alone to eat alone.

I mean, when I go to somewhere, I will just listen to music.

Right.

But as a developer, I was maybe listening to music four hours a day, right?

And it gets you and gets long.

But as a manager, it's like, maybe you're getting meeting, meeting, meeting, meeting, meeting, you eat and then meeting, meeting.

I get that.

I get that as well.

So to lower my cognitive load over the day.

And again, my ADHD is sometimes acting up because of the load that I'm having, like meetings back to back or something.

Basically, I'm not a fan of time blocking in a calendar, because that's sometimes creates a very different understanding of what that person does.

But basically, I often have body doubling sessions.

And with body doubling is basically where I listen to music, because then I need I have my focus time, I have somebody on a team's call or a discord or whatever other tool where there's a body doubling community.

And we declare we're doing this thing.

And we're creating this kind of focus time with that kind of a psychological accountability of just declaring for one another what we're doing.

And those tasks, they do not have to be related at all.

We don't even do the same things.

We are not even in the same units or whatever that may be.

But this is the time where we declare, focus, listen to music, go with the job done.

And it's difficult to do that when you're higher up as a head of engineering, I don't know, CEO or something like that, because that's meetings, meetings, meetings, meetings.

Yeah, I'm sure that's the context.

I'm sure that the CEO, I've never been a CEO.

So I'm sure that will be quite chaotic.

But as a head of engineering, what I was doing is with my peer when he had the product was like, Hey, I need to focus on this.

Can we just be in the same meeting doing our work?

And then we just chat when we need synchronisation on something.

And then it's like, maybe you're like typing and the other person is maybe listening music, but also typing, and then you are available.

The other thing I also like a lot is like, you are in a Zoom meeting that nobody is in, and then you're just typing.

And then someone is like, Hey Alex, do you have a moment?

Like, sure, tell me.

And that is for me, it's like team available time.

I'm available for you.

You can jump in whenever you need.

You can interrupt me.

It doesn't matter because I'm doing maybe something or researching something.

Then me being open, like during this time, you can interrupt me five times, 10 times.

I will not complain.

You can also bring me to another meeting and I will be joined there.

So having one hour a day for interruptions just so people know that they can bother you, it's very helpful.

The higher you are, the harder it is.

But when I was in a team level with the PM, she was amazing.

One of the best PM I've worked with.

I love that we sometimes we were like in this shared room doing nothing.

And then the team being in talking about something and the speed about resolving issues was like minutes.

I've never been in that environment like that fast.

Well, if you're in an office, maybe you're in this fast.

But in remote, if you need to say people like, hey, can you jump into a call?

There's no, it's very hard.

But if you're always available, that helps people a lot to do the same things.

All right.

Aleix, we're coming to two hours of the stream.

Let's do a little bit of backtracking and go back to the root topic being understanding the cognitive load that we're dealing with.

So, if we could place cognitive load and from the perspective of team topologies also, so the team being the lowest unit of understanding and give some advice to anybody who's watching us now or will be watching the recording as to how to start understanding the cognitive load that people are dealing with in their own environments that they're at.

What to look for?

Are there like common things that you can watch for to find and understand that this is the cognitive load?

The easiest way is delegating everything to a tool that is prepared for this.

And I say this because being honest, the amount of complexity about assessing a cognitive load is huge.

So, you can, I will share screen briefly.

All right.

There you go.

So, this is the temperature.

Being honest here, you can see all drivers and it is distilled and it gives you all information about all the drivers that you can find on a team with things that you can do to improve it.

You can go to the application, you can see a demo and it's fine.

I will not go in more deep.

So, going from zero to one without you learning everything about cognitive load, temperature for me is the go-to tool.

Right now, I think we did an amazing job.

And it's a standalone tool.

It works and you can get multiple teams to do this.

If you, for example, you say, hey, for whatever reason in your company, you cannot externalise this to an external tool because of legal, for example.

I can imagine multiple reasons why people choose, for example, to not.

Then I go back to maybe read the drivers.

But the important part is during the retrospectives, have a moment to explain what is cognitive load and somehow different cognitive loads about this.

Cognitive load can drive people away from the conversation you need to have.

So, instead of using cognitive load, you can use developer's pain.

And you can ask them, which are your pains?

Which is preventing you to do your job?

What is things that and then you open an open question.

You have a retrospective theme.

So, use mirror, for example.

And then you ask people to put the stickies.

Then you have patterns and then you explore them.

Based on your experience, usually people find their immediate pain, dig deeper about what is the thing.

Oh, my problem is zero.

Well, why is zero?

Well, because things are happening and changing.

Oh, because you have ten stakeholders with different opinions.

And then you need to drive people into the insights.

You need to do that in retrospectives or things that people have a high trust environment.

Because you need people to talk.

Otherwise, it doesn't work.

Temperature has this level of anonymity where people can share the things and they don't need you to be in retrospective settings.

But if you have high trust, do that model.

The only thing is that then you need to run this for every team.

The good thing is that you were able to understand more of the people and be exposed.

So, that for me is like if you don't want to introduce the concept of cognitive load, you can introduce the concept of pain.

And this is very related to the developer experience surveys and similar.

You know your teams.

You can also do specific questions and do Google Forms with one to five.

And then you do the leaker thing survey and you can do it yourself.

There are a lot of companies, big ones that do this, like Shopify does it their own.

I'm sure that there are a lot of companies that do this by themselves.

No problem.

But if you want zero effort, temperature.

You want to do this.

I started exploring pains, the developer experience and drive the conversations.

And it will be a long conversation, but it needs to happen this way.

So, that's my suggestion.

So, basically ask questions and then dig deeper.

Yes.

And don't get into the surface.

Also, be clear about the expectations.

Because maybe you find issues that you cannot resolve.

Maybe that frustrates people.

The issue is like, hey, we will have a follow-up conversation.

Because usually you have a problem about identifying the problem.

Then another conversation about resolving it.

My suggestion is don't try to do the same thing on the same retrospective.

Because it's way too intense to identify the problems.

You need to give people time to express the things and share.

So, sometimes retrospectives want to end up with actions.

I would say pause.

Analyse things.

Maybe do one or two teams.

And then find themes to explore.

And then you go into actions later on another session.

So, people have time to reflect.

Because people will start, oh, this person said the problem is this.

Oh, I didn't notice.

And now they find themselves in the problem in a meeting where that happens.

Like, oh, I start seeing things that before I wasn't able to see.

And that's why you need to give time for people to move from understanding the problem to solution.

And just naming the problem can be just emotionally draining and will not set the people in the problem solving space.

Because they'll be annoyed, agitated.

Yes.

Yeah.

Whatever the emotion will be that they go to when they're in that state, in problem state.

And that will be a problem.

Exactly.

So, you need to give these things out.

And you need to as a facilitator, you need to control things.

Because you don't want people to be too much in range.

So, being angry is okay.

Yelling is not okay.

So, that's the thing, right?

So, you need to give this a space.

Give people room for asking questions.

And hey, I don't expect to go into solution mode.

But I want to get things out.

And I also will kind of promise you to solve everything.

But I will do my best to bring these things into improvement.

Some things will be staying on the team level.

Some things can be done by management.

But the good thing is that it won't improve.

And then in the second one, you can go deeper and give time.

Like, hey, we understood that this was a problem after two weeks or after a week.

We still believe that this is the problem.

Oh, well, yes.

I think that...

Okay.

Great.

How we can measure that we are doing the right direction?

There's an amount of rework.

It's an amount of tickets.

It's about messages in the Slack to get into conclusion.

Amount of meetings.

So, getting some KPIs to know that you're in the direction.

And then you set some reasonable actions to improve them on the short term.

Short term, please.

Because if it takes six months to improve something, people will be like, this never happens.

We will not improve.

And also, you need to have the support of the organisation to improve things.

The worst scenario I saw in my life is like, we understood the problem.

We did nothing.

Now people are more frustrated than before.

So, if you cannot come in to improve things, don't try to understand the problems.

Ouch.

That's it.

That's painful.

That's a painful vision to me.

We understand the problem.

We're doing nothing.

Oh, my.

But that's when the management is overloaded.

Oh, yeah.

Okay.

It's not that they don't want to be in something.

It's that they don't have the capability or the space to do something.

So, be reasonable about your commitment.

If you're the one that is responsible for improving something, but you will not let something fail and you focus on improving the organisation, that's that.

This happens a lot with managers that they need to be present so things happen and they then cannot delegate.

Because they cannot delegate execution or they, for example, I had a person that said, hey, I cannot delegate things because nobody is doing DevOps but me.

So, I need to be all the time doing DevOps and otherwise things don't happen.

Like, of course, you cannot delegate.

So, why focussing on that other thing if you don't have the space to delegate on these skills?

So, maybe you need to do an intermediate step, which is training people or giving people the responsibility.

So, you can free yourself from groundwork.

Yeah.

Right?

So, understand the situation and then act on it.

But, for example, how I can focus on improving the relationship with business if the team is failing all the time on rework or issues in production, no, I focus first on moving the team from zero to one or two because then that I can delegate everything and then I can focus on another thing.

But it will not work to focus me on product collaboration if engineering is failing all the time.

So, step by step.

If you have a complete overload on production back fixes and trying to maintain the software running and how can you even focus on developing new features?

That's impossible, right?

That's insane.

But it quite often happens.

And then, again, we have different problems from expectations and managing those expectations and whatnot.

But, yeah, okay.

That is a sound advice to just go and understand and try to understand the problem, but also secure enough support that you can actually try and resolve the problem from an organisational standpoint.

Or if the problem is higher up than the team, then also try to address it higher and have that support as well.

So, look more globally outside of the team.

Usually what happens on the upper level is that each of us is trying to fix the problem from different point of views.

So, usually when you see a problem, someone else already saw the problem from another angle and is trying to do a fix from another angle already.

So, find these people and peer up like, hey, let's work together in this and what we can do together.

Because I had a client that recently, they're like, oh, we see this problem, but we're working maybe a little in silos and we need to involve more business.

And they say like, oh, there is a meeting where this person was trying to do something to align.

Okay, that person is trying to bring this up.

Before, you were saying like, what is this person doing?

Maybe that person was trying to solve that.

So, from a language or from a perspective that you were able to relate, but now that you identified that person, okay, work together and drive this forward.

And I'm sure that this, you're not, it's very rare that you're the first to notice this.

And probably other people tried before.

They maybe were not or just like, okay, I give up.

Find them.

Maybe they want to have a little more energy to try again.

And then you try to do things.

But usually a problem that was tried to be solved before somebody burned.

So, rescue that person, maybe learn from that mistake.

And then, or if that person's like, don't do that, brave yourself, don't touch this.

It's like, okay, you saved me from a burnout here.

So, yeah.

All right.

I deal with complexity every day.

But looking at the aspect of psychology, ways of working and cognitive load and all that, that's, I think, way more complexity than I ever expect from any problem that I'm solving as an architect.

I think this is essentially more complex than anyone would want to account for in that sense.

It really requires a lot of people to solve this kind of complexity at times.

And to first to create the awareness of said complexity and then to be able to delegate, distribute that complexity over people to actually be able to solve these problems.

Yes.

And patience.

Because I learned the hard way that even though you push hard, things don't happen.

And then maybe you put the seats and then eventually it happens.

And then you're like, why now it's happening?

I tried that for three months, didn't happen.

And now it happened alone.

Like, okay.

So, sometimes we are not the person to make that change.

Maybe you put the seats, but maybe someone else needs to finish that on.

That's fine.

As long as it happens, fine for me.

So, a little bit about working with your own ego, right?

To put it down a little.

It may be challenging for some people also.

Because it is to think about it and to notice cognitive load, I think this is a little bit of a shift in the way of thinking.

And you have to put aside certain things that you would hold dearly and very egoistically.

And patience is one of those virtues that you need to put up front at times to have that change being possible.

And that may come difficult for some people.

It may come easier for others.

And sometimes it's not you.

And sometimes it's not me.

Or anybody.

Yeah.

It depends.

It really depends on the situation, the context, and what is the actual problem versus what is the symptom that we see and consider a problem.

So, very interesting conversation.

I didn't know that we went already two hours.

All right.

I think we can wrap it up at this point.

If any of you reached this point, and I see that we have still a lot of viewers alive, if you want to go a little bit deeper into the definition of cognitive load to learn about intrinsic, extraneous, and germane, there was a previous livestream that we did with Radek Orszewski, who's a team topologies advocate and a Kanban trainer.

So, you can scan the QR code and watch this particular one.

Maybe not exactly at this point.

That would be a bit of an overkill.

But go ahead, save it up, subscribe to this channel, and watch through those.

Now, I'll do a little bit of promoting.

So, we're continuing the loosely coupled livestream in two weeks.

We are having a week of a break.

So, I'm gonna just swoop into the slide here.

So, we're going back to the topic of recruitment in two weeks' time.

We're going back and we're gonna have Philip Poynton again on the stream.

And luckily, this time around, we're gonna have Gabby Preston Pfeiffer again from Tooltop Raccoons.

Gabby is well and fine now, so no more health complications that bar her from speaking.

So, luckily, we're gonna have them both in the stream, and we're gonna have another conversation about IT recruitment, which is another difficult topic and dealing a lot with also cognitive load, I would say.

And that said, if you want more content, well, you can visit bridgingthegap.eu.com, which is where we write articles on enterprise application integration.

But you can also find a list of our upcoming events in the menu on the side.

You can subscribe to Substack.

We're publishing articles and different...

We're gonna get into more content there soon enough.

And you can also subscribe to the YouTube channel to get notified about upcoming live streams.

There is some other content pending, which again, I need to have more space in terms of my cognitive load to build that content.

So, that's gonna take some time, free up some space, not take too much on yourself.

So, there's plenty to do, plenty to watch, plenty to enjoy in the upcoming streams.

And for today, thank you, Aleix, for joining us.

It's been a pleasure talking about this, quite a complex topic.

My brain is buzzing, but I already feel that I'm a little bit overloaded after a whole day of meetings and then a live stream at the end of it.

So, we're gonna come to a close.

Thank you, all of you who stayed with us.

Hopefully, you enjoyed the conversation and tune in for more.