Loosely Coupled - Beyond the symptoms, A deeper dive into identifying problems

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

Welcome back to Loosely Coupled, brought to you by Bridging the Gap.

My name is Karol Skrzymowski, and I hope everybody has something nice to drink.

Today, for me, it's not coffee for a change.

It's a, well, black tea with ginger, honey, and all sorts of spices because I'm a little bit under the weather.

And speaking of all those lovely seasonal symptoms, we'll be talking today about symptoms and problems, and looking deeper into what are actually problems that we're experiencing, what are the actual, or maybe these are just symptoms that we're experiencing, not problems.

And to guide us through the process of the problem space of problems, we have Woody Zuill, a lean and agile software development guide, who, well, has been coding and cracking on with IT topics for over 40 years now.

And, well, I'm not going to go with lengthy descriptions from the bio.

I'll let Woody tell us something about himself.

So, Woody, welcome to the stream.

Karol, thanks for inviting me.

I'm really looking forward to this.

And, well, good morning.

Yeah, good morning for me.

It's morning where I'm at in the Pacific coast of the US.

So, we're in the morning time here.

And I guess you're probably in the mid-afternoon or something like that, a little later, almost evening.

No, it is evening.

It's seven o'clock in the Netherlands.

So, it's already evening time.

Hopefully, my kids will go to sleep as soon.

So, no unexpected noises on the live stream.

But it is what it is.

All right.

Woody, tell us something about yourself before we dive into the problem space of problems.

Well, when I started programming, I needed to have some software for myself.

And I couldn't afford to buy good software.

And most of the software I could afford didn't work very well.

So, I thought, well, maybe I need to learn to write software.

And I started learning to write software.

So, that's somewhere around 1983.

So, it's over 40 years ago.

And I did not have anyone to learn from, really.

So, I mostly learned it out of a couple of books.

As a matter of fact, I'm going to turn around right now.

I found this the other day.

I think it's the first book I ever bought.

I don't know if everybody can see that on programming topics.

And it's called Basic Advanced Topics, which I thought is really a great title to say, this is basic, but it's advanced.

So, anyways.

You know, it's got a lot of explanations, but it's also got code that you can type in and copy into your stuff.

So, anyway.

So, that's when I started.

I started learning in basic back in 1982 or 3.

And it really was helpful to me.

And I worked solo as a programmer for about 15 or so years, just writing software for myself in a business that I owned.

So, that's my programming start.

And then I decided to switch my career to just programming and went to work at places that, you know, I could work as a programmer.

But in the 1990s, the end of the 1990s, it was almost impossible to not get a job.

If you wanted to be a programmer, you just needed to know how to spell VB and you could get a job programming, right?

And so, if you could spell VB or ASP, there was so much work, they did not scrutinise whether you could actually do it or not.

And so, I started working, by the late 90s, I started working full time as a software developer.

And what I found was, as much as I loved software development, I hated working at places where they were doing software development.

So, this is an issue for probably a lot of people besides me, is that we like doing the thing that we like doing, but finding a way to make a living at it, working at a place, you know, it can be really bad.

I've actually worked at places that were horrific.

Now, I got a lot of experience being a boss myself.

I've owned a number of little companies.

And I don't think I was a very good boss.

But when I started working for other people, and I started learning how bad a boss could be, I started realising maybe I need to learn more about this.

So, that's where the topic of today is coming to.

The things that we would see, if you want to get to there yet, well, you know, I'm just free flowing here, you can guide me.

Okay, so the thing is, is I would work at these places.

And I was going, you know, I don't like this place.

I worked at one place I really liked.

And then it was a three month contract.

When that work was done, I went off to other places.

And so I would say this, that every place I worked had these symptoms of underlying problems.

And I didn't know yet that these were just symptoms.

I thought they were the problems themselves.

And so I start trying to figure out how to deal with that.

And one of the biggest problems I think that I had was, was to be put on a team.

But then we never worked as a team.

So in other words, why did you put me on a team?

Why do we call this group a team?

But we're all sitting, you know, we're sitting in separate cubicles wearing earphones to listen to radio or listen to music while we're working.

And we're never really doing anything like a team.

And I would think of a team, many of the things I did when I was younger, were very much teamwork.

Like I played, when I was really young, I played music in little rock and roll bands and later folk music bands.

And that, you know, you don't all get on the stage and then put on, earphones, listening to different music, and then play whatever it is you want to play.

You know, it's like, that's not going to be a performance.

That's just going to be a bunch of noise.

And noise could be a performance too, don't get me wrong.

But yeah, so this is the thing.

As I start working for other people, one of the things I noticed is we were often put on teams, but we never actually worked as a team.

So that's one of those, I would call this kind of a potential problem, but I think it's more of a symptom.

Like this is something I could notice.

If they put me on a team, then I could take that as a symptom.

Like there's some, there's going to be some underlying problems here.

Let's see if we can figure out what that is.

If we really truly working as a team, and I only got that a few times, well, somewhere around that time, I was also exposed to pair programming in 1998 or 1999.

And that was like real true teamwork.

Two people sitting together in front of the same computer, talking about the code they're writing, discussing what they're going to do and doing it.

And there's a lot of advantages to that.

So as I was identifying the problems that I felt I found in my work, I was also finding things that made my work easier.

And the two big ones, you know, people will recognise these if you're in this space, for me were pair programming and test-driven development.

If I got good, if I followed rigorously the ideas of test-driven development, my work would be easier to do and less problems in the code and so on.

So I started looking for places that were already bought into some of these ideas, and that never worked for me.

It was rare to find someplace.

So there are two sides to this, looking for a place to work that's really great.

And then wherever you're at, trying to help make things better.

So that's, I was not good at either of those things.

I couldn't find a great place to work.

And I found that I could not convince anybody that we should try to make things better.

Sounds like a lot of my stories, where I see that there are problems, I try to pinpoint them and identify.

The organisation ends up putting a huge band-aid over a gaping wound.

Yes.

And not solving the underlying problem at all, not even listening to any reason over what could be the actual problem, but just looking at the surface of things, right?

So that's a really, that's exactly what we're talking about here.

And I would take this maybe into this direction, that to believe that what I think the problem is, or I think the solution is, often it was not a good path.

In other words, it's not about what I think, it's about how can I help others start thinking about the problems?

So in other words, it's not about having a solution, it's about being able to experiment and being open-minded.

So how can I help this place I'm working?

I'm not a consultant or anything.

I'm what they would probably have called a contract programmer.

How can I help them see that, like we have too much queuing, or the people that can answer our questions aren't available to us right now, or that we are not doing test-driven development and therefore we've gotten to the point in our work where it's mostly about fixing bugs.

I've worked on projects that the first few months, it's mostly about writing new features, but after that it turns into a whole lot of work fixing bugs.

Now, I'm not saying that whatever we used to do is still worthwhile thinking about.

I really do believe that times will change and what used to work, there's a saying, what got us here won't get us there.

The old stuff like Deming would say, most managers are taught how to manage in a way that is no longer considered useful.

Whatever we are teaching in universities has already outdated itself, and so that's problematic.

To a very large extent.

I'm looking at this, for advertising the stream I quoted from Andrew Harmel-Law, the situation that was over his talk at DDD Europe this year.

Andrew delivered a splendid talk about the second hardest problem in software architecture being variability.

It was a really great talk.

It was a really great topic, very well outlined and explained and in a snackable way presented that it was not distracting for my brain, so I could actually follow it because it was storytelling.

What was very key in that particular talk, Andrew, and I think he did that also deliberately, wrote that this is a second hardest problem.

For the whole talk, he absolutely forgot to mention what's the first hardest problem.

The first question he got from the audience at the end of the session was, okay, Andrew, but you talked about the second hardest problem.

What's the first hardest problem in software architecture?

Andrew stopped for a second there and said, oh, you're right, I haven't said anything about that.

All of you!

Pointing to the audience.

Of course, that met with a roar of laughter over the whole auditorium, but it is a very true statement that I heard oh so many times over oh so many topics, even on the stream.

Technology is never the problem.

It's us humans that are the problem, in essence.

This is, of course, a very drastic simplification and generalisation, but what that means is that the root of all problems is just human nature.

I'll buy that.

You'll buy that.

Good.

All right.

Another thing that I read recently in this, because I'm reading this lovely book, Domain-Driven Refactoring, by Alessandro Colla and Alberto, and I'm going to butcher this name, probably Acerbis, given that it's Italian.

I suppose that's the right pronunciation.

Not entirely sure.

Sorry, Alberto.

I shared this quote with you earlier over LinkedIn.

I think this is a very true statement for all engineers, all developers, that we have this tendency to find solutions and fix things as quickly as possible, because it's extremely uncomfortable to stay in the problem space where the problem is unsolved and just look at the problem from all perspectives and look what it actually is.

I think this is very much the essence of what we're talking about today.

Okay.

Let's get into that.

We're solving symptoms, not problems then, right?

Yeah.

If we think we have gotten into the problem space, then I would say, normally, we're in the symptom space.

We think we've gotten into the problem space, but we haven't.

This is an issue.

Symptoms mask problems.

There's a famous systems thinker, his name's Russell Ackoff, and he used to talk about these four different ways of addressing a problem.

The first one, he says, they all have solve and absolve, resolve, solve, and dissolve.

He has his own descriptions for this.

I think that the absolve is merely just ignoring things and hoping they'll go away.

Sometimes, they do.

I was once contacted, I was working in a company, and we would help this other company in getting their code into better shape.

I'm talking about in the late 90s.

They sent us over a batch of code that was about one method that was something like 5,000 lines long.

They said, oh, we're getting this bug in here.

We started analysing it.

Then about a day later, they sent a note to us saying, oh, wait, stop.

We solved it.

We said, well, what did you do?

Well, we don't know.

It just started working again.

It's like, okay.

You didn't solve anything.

You're just ignoring that underneath there, there's a problem.

This is not an uncommon thing.

If we get a problem, but it's not very frequent, we don't pay much attention to it.

If you get a little bit of a toothache, and then the next day you feel fine, you don't think you've got a problem.

Anyways, the resolve is kind of like you resolve it.

You take enough action to make it feel like the problem's been solved.

I believe that's dealing with the symptoms.

I think that's what he brings up.

Solving it is you actually get to the root problem, and you fix it, whatever that is.

We could give many examples, but we do a root cause analysis.

We find the problem, and we fix whatever's causing that problem.

Then the question is, what is desolve then?

Desolve is taking it to a system level.

What in our system is allowing problems like this to occur?

You adjust the system instead of just solving the problem, because problems will recur.

I believe we can match this up a little bit to the Cynefin.

If your listeners are familiar with Cynefin, if they're not, they can be looking that up.

We could put it on that mural board or somewhere.

The idea here is you've got four main domains, and one, all fifth domain is considered, he puts in the centre of his diagram.

You've got the clear domain, the complicated domain, the complex domain, and chaos domain, or chaotic.

Or confusion, right?

The middle one.

I think the middle one's sort of confusion.

We don't know what our problem is, or we don't know what kind of a problem we have.

It's very obvious.

When we're in the clear space, to me, that's a space where A plus B is the problem, and the solution is always C, and we don't need to even think about it.

I like to use an example.

If you walk into a store to buy some milk, you just go to where the, in the US anyways, you go to where the milk is, you pick it up, put it in your cart, and when you get to the place to pay for it, you pay for it.

There's no unknowns here.

That's a very clear space.

A complicated space is where you need to do some analysis.

I would say, in a lot of ways, you have a checklist of things that you need to do to determine.

For example, putting a new roof on an old house, you can't just call them up and ask for the, how much will a new roof cost?

Well, they have to know what's the size of the roof, what's the condition of the existing roof, what materials do you want to use for this new roof, and do you want the 10-year guarantee or the 25-year guarantee?

There's a lot of things, but once they've filled in all the blanks and they've taken all the measurements, they can calculate a pretty accurate price.

Now still, they might, there's Kenevan, they might come up, so that's got confusion in the middle, and each time I look at these charts, they change something on them, but the complicated space is really about relatively well-known domains with a number of variables.

So I can give a real good example from my past.

I used to own a shop where we made signage and advertising graphics, and one of the things we did was screen printing.

So in screen printing, you have a fabric stretched across a wooden frame, use a squeegee to essentially draw ink across it, and this leaves an image.

So this is, everybody knows about silk screening or screen printing, and we'd identify 37 variables.

So if there is a problem with our image, like it's a little smeared or it's the layer of ink is almost transparent, it's not thick enough, we could look at those and then we could go to our chart and see, well, what are the variables that could cause this problem?

So I could document all the variables and therefore make it the troubleshooting mechanism really fast.

And in the end, that's a complicated domain.

You need to have expertise, you need to have knowledge, you need to be able to do some simple experiments maybe, but most of it's, you just need to fill in the blank, you answer the questions.

So in that space, we don't know that A plus B is the problem.

We need to discover the problem and then we can solve for it.

So for those who actually work with software and read the manuals of whatever technologies they're buying, I remember back in the day when we were working with Tibco BusinessWorks 5, Tibco had very standardised error codes everywhere.

So if anything in the framework went wrong, which was a standard problem, standard error, it was a named code with the description and you could look it up in the documentation and see what's the resolution for that, where potentially can you find, what potentially you can do to solve it quickly, right?

So this would be that space.

So if you would have identified a list of variables, and in that sense, your list of variables is done down to error codes or known error codes, you already have a kind of procedural approach to solving your problem because you know where to look, you have the knowledge, you have the PDF booklet or whatever in front of you with the manual, done.

Pretty much 90% of the times, yes.

Yeah.

So you have the expertise.

So you yourself know how to identify these things and know where to go for the answer and stuff like that.

Now, when we move into complex space, which is where I really put software development, because what you're really talking about there was using software, but in the creating of that software, we're moving into the complex space.

In the complex space, we don't really know, you know, sometimes they talk about wicked problems as being a problem where we won't start discovering the problem until we start trying to solve it.

So that's one definition of a wicked problem.

And so this is kind of the space of software development.

If we are in software development, if we are not having these kinds of problems to solve, I don't think we're really doing development.

So this is the issue.

We can say, to me, if we're doing software development, we need to discover things that we don't yet know, and the process of discovering exposes what's missing for us.

So in this space, we operate with theories, and then we do experiments.

And even if we know exactly what we want to write in our code, we end up discovering we were wrong.

And once we start trying to use the thing, oh, wait, that's not going to work kind of thing we'll hear.

So anyways, that's the complex space.

So this is where the iterative approach comes into play.

This is where Agile comes to play with iterations, scrum as value that we discover as we go.

This is where we jump into domain-driven design, right?

We can constantly upgrade our model of understanding of the problem domain or some sort of business domain.

That's right.

So a lot of times, so this goes like planning of what software we want in the first place.

My experience with this has been whatever we thought we wanted up front, we were going to find out we were wrong later.

So why do we spend so much time figuring out what we want?

I think I would say it this way.

It's in the writing of the code and creating the software that we discover what we want, and that if we attempt to do it beforehand, we're doing it in a crippled fashion.

This is really kind of, in a way, the scientific process.

We need to have theories and do experiments and discover.

And I have often found, so I would almost put it this drastically, that if we document, so let's give the example of creating the architecture.

So we can't really create the architecture until we know everything we want this software to do and some of the mechanisms we want it to use.

And we start designing, like in the old days, we're going to do a client server or an end tier.

And nowadays, we have all the cloud stuff and all these other things.

The architecture allows us to make the big up front decisions, or we believe we need to make the big up front decisions that are going to be very difficult to change later on.

And what's going to end up happening is we're crippling ourselves because every programmer who works on this code, after we start working on it, is going to be complaining about the architecture that isn't flexible enough to handle the problems that we're trying to solve.

So we should take, that as a symptom, and we should get down to the root of that and try to figure out what we should do instead.

And that's why I really believe the iterative pattern of working is so useful.

Back in the 80s, which I never really worked outside of my own little envelope, own little environment of writing software.

But back in the 80s, they were discovering that on bigger projects, they needed a way to try to figure out everything they need up front.

So the heavy duty documentation and heavy duty planning really became a solid thing in a lot of companies.

In the 90s, they started discovering, hey, this isn't working.

And Standish Group or whoever that did the chaos report was discovering, sharing data about this. So

And this also, just to pitch in here, this also stopped working because also the velocity at which the environment changes, this just sped up drastically over the years.

And now the, let's say again, variability is way, way higher than in the 80s.

So obviously if our water drift goes faster, then obviously having very long iterations, waterfall-like approaches where we plan up front for a year and then execute for the next four, these will never run out because this will just not relate to any reality.

Yes.

Well, that often grinds to a halt after a while because we kind of, like the old saying, paint yourself into a corner.

It's like you're painting the floor.

This is like the old example.

You painted from the door over this corner instead of from the corner over to the door, no way out.

And I've seen projects that get two or three years into them and everybody's saying, we're dead in the water now.

This is never going to get us anywhere.

So this is, I'm sure everybody's experienced something like that.

My overall experience in software development has been that the things that we discover along the way, we're not really allowed to use them because we're trying to finish the thing that we promised we would finish.

And a lot of software happens this way.

So back to the symptoms.

So in the clear space, the symptoms aren't much, everything's clear.

It's a well-known space.

In the complicated space, that's where the symptoms are often indicators to us of something we need to be paying attention to.

That is accentuated in the complex space.

Now in the chaotic space, we could give an example.

For example, the smoke alarm is going off in the kitchen.

And I can say, oh man, I got to go take the battery out of that thing because that's just so annoying.

Well, we're dealing with the symptom.

I'm annoyed by the buzzing sound instead of the symptom.

You have the pot on the stove, the water has all been boiled out of it and stuff's getting hot enough to start burning.

And pretty soon we're going to have a fire.

And if we're not paying attention to the actual problem, just one of the symptoms such as I'm annoyed by the buzzing, we got it.

In the chaotic space, we act on what we know what's in front of us and we take action immediately.

And in the case of a fire, I don't know if you've ever been at a place where they actually had a fire.

But everybody gets out of the building and only people who know how to safely deal with the fire are allowed to do anything beyond that.

So I worked for seven years or six years with a fire department on the board of directors.

And a big chunk of what we focused on was having our firefighters extremely well trained so that they're not going to get killed when they're going into a building by making foolish decisions.

There are lots of symptoms in that space that are hiding problems that could kill you.

So you got to be really careful.

So that's a good example.

I didn't think of using here, but I'm glad it came up.

And then lastly, if we're in the confusion space, we just don't know anything yet and we need to do discovery about what the hell's going on, what we know, what we don't know and what we know.

We will not discover what we don't know, we don't know, but basically at least.

But there are a lot of people that I've worked with in managing these things.

And like I gave my example, when I first started working, looking for a place that I would have enjoyed working at, I had a lot of trouble finding that.

And then when you're inside a place where you're working, a lot of the people don't do it.

I don't think Cynefin came out as a public thing you could learn about until 2007, 2010, somewhere in there.

So in the earlier years, I didn't know that.

Matter of fact, this really helped me understand how to explain this stuff.

There was a thing before this called the Stacey model, which is very much the same thing, uses the same kind of similar terminology.

So I was starting to learn that stuff back then, but I didn't have a complete understanding of it.

But to get to the point, I think most managers want to work with things as if they're in the complicated or clear space.

And they actually make decisions based on that.

And that really means we're often dealing with the symptom rather than the problem.

If you ever had a manager or some of you, I always warn people, I usually end up insulting managers somewhere along the way.

But I've been a manager much of my life in different ways, in companies I've owned, in companies I've worked in.

So I have some right to make fun of myself.

But what I noticed a lot of times a manager will say something similar to this, don't bring me problems, bring me solutions.

Oh my, I just literally saw a graphic with this quote on LinkedIn just before the stream.

Oh really?

So that's a good point because it's still around.

So I'm not completely out of date.

But the issue here is that we cannot, solutions are not the space that, I'm going to be really bold about this.

So being in the solution space of trying to solve a problem usually means we are trying to solve symptoms.

So this is very problematic to me.

So to give a good example, in software development, I have an exercise that I do.

So if I'm called into a company to do a consulting, I'll do often do this exercise.

But even in some of my trainings, I do a lot of workshops on mob programming or software teaming or workshops on something I call beyond estimates, which is mostly about why I think estimates aren't helpful to us in software development.

Anyways, I do an exercise that kind of goes like this.

What are the things that are making it difficult for you to be effective in your work right now?

What are the things that are making it difficult for you to be effective?

And I will get a list and I will, I'm going to go ahead and open up something so I can, go ahead.

For all those watching, you can answer Woody's question in the comments on YouTube and LinkedIn.

We'll see if this matches anything that Woody has prepared.

Let's do that exercise.

Let's do that.

Let's do that.

Restating the question, what things get in the way of you getting your work done effectively?

That's right.

Right now, currently.

I always like to put that on.

It's not, what are the things that will make it difficult or can make it difficult, or that maybe you've seen, but what are the things you're currently experiencing that are making it difficult for you to be effective in your work?

Now we can just let people, are we seeing things coming in?

Well, we do have a slight delay between the studio and the actual stream on LinkedIn and YouTube.

So this may take a moment for people to actually get there.

But the question is in on the screen visible, not yet visible on YouTube nor LinkedIn.

So we'll give them a moment.

In the meantime, let's, let's dig into this.

So maybe I'll shoot some, well, I cannot really say that I can answer this question for the position of my current employment, because I actually finally managed to find a good employer.

And I'm happy about my place right now.

The only thing that really gets in the way of doing my getting my work done effectively is the lack of time.

Oh, yeah, there you go.

So that's a, that's a really good example.

No.

Yeah, let me elaborate.

Because I want to do so many things and get into so many initiatives, that I need to decline certain aspects, not to do them and delegate them elsewhere.

Because there's not enough time in the day for me to cover all the topics I would want to cover.

Yes.

So this is a, this is something that I've read about.

For a long time now, a lot of psychologists will identify this, this issue.

And part of it can be, fear of missing out.

Part of it can be, I'm interested in a lot of things.

Now, personally, I'm interested in a lot of things.

And I'm usually allowing whatever seems most interesting at the moment, to be the thing I'm going to focus on.

And I have owned about 20 businesses in my life.

And usually what would happen is, I would either start up or buy a small business.

And it's something I'm really interested in.

And in about a year, I get bored with it.

And so now I've start looking at the next thing that I might get interested in and get bored at.

And I want to get rid of the thing I'm already in, you know, was interested in.

But now I know enough about it, I'm no longer interested in it.

Woody, you do realise that you sound right now like a typical person with ADHD.

Yeah, now, I've got a book here somewhere that is called Oh, I don't remember that.

I'll look it up later.

But when I first heard of ADD, that was probably in the 80s.

So I got this book on the topic.

And it had a test of like 100 qualities, but symptoms of someone who might have ADD.

And dang, I hit like 96 of them or something.

Sounds all right.

So I'm, I'm at best self diagnosed with ADD or ADHD, because I believe there's a superpower that comes with it.

And that's the ability to hyper focus.

So you know, I would find I could get really focused on something to the distraction of everything else, and be hyper focused on something.

So I'm not saying it's good or bad.

I'm just pointing something out.

Yeah, so I might have, but that's, so I've done this, I've owned a number of different kinds of businesses.

And so, but this is part of the issue.

We don't have enough time.

So see, my not enough time is exactly stemming from that ADHD part, because I do have ADHD.

But me declining to work on certain topics and just delegating certain topics away from me is part of my autistic part, which my ADHD is pure chaos.

And then my autism just puts a structure on top of that and forces that into a submission.

So although I have no advice about this, whatever.

One thing that I've noticed, whenever I started a business, by the time I get to about 10 employees, I was spending more of my time delegating work to other people managing the other people than doing the thing I was interested in, in the first place.

So that's just an observation about myself.

That often would be the point.

If I had six or eight or 10 employees, it was getting to the point where I'm not interested in this part of this thing.

Let me do something else.

And that's a part of why I got into software development.

Matter of fact, we got something coming in.

Yes, we have something from Carolina.

So too often, everything has to be done quickly.

So the deadline was tomorrow.

That's one of the things, yes.

Supervisors aren't interested in solving the problem.

Typical managerial issue, right?

But rather in putting out the fire as fast as possible, and then waiting for the next fire to happen, basically.

In consulting, there was a colleague in the CRM space that just told us one day, and that landed as a meme on our desktops, as our actual background of the desktop, that we are all consultants.

We all love a good dumpster fire.

Yes.

So that's basically a dumpster fire situation there.

This is really, there's a quote that is often attributed to Peter Drucker, and I'm going to paraphrase it.

He says, much of what we consider to be management is simply making it hard for people to work.

And that's a big part of this right here.

Now, I don't know if he actually said that.

I've never found an original source for that quote, but I have found the earliest version of it.

I found, and he's supposedly quoting Peter Drucker, but he doesn't say where he gets it from.

So I don't know if it's really from Peter Drucker, but I love that quote.

The issue is as managers, our job is to make it look like we're managing things.

So we need to, we want charts.

We want things to measure.

Well, there's another good quote I'll share from, I think it's from Russell Ackoff, which I usually paraphrase a little bit, but I'm going to try and do it exactly as he says, when a manager can't measure what they want, they start wanting what they can measure.

This is really problematic.

So this is a big part of the issue right here.

We're using proxy measurements that make it look like we're doing something, but are actually meaningless to be doing.

And we're not just, are they proxy measurements?

They're usually some kind of a lagging indicator, which means the usefulness of them has passed by the time we get the information that we need.

An example of that, that I often see in software is people measuring a cycle time, which I would say cycle time is meaningful only when you have highly repetitive processes, like in manufacturing.

And we don't get that when we're working.

Oh, you got a quote to do.

Managers who don't know how to measure what they want.

Yes.

This is from Russell Ackoff.

And I said it pretty much hit it.

Yeah.

That's a great book.

So that's this little book right here.

A little book of F-laws.

Yes.

And it's actually easily findable online if somebody wants to read it.

This is quite an interesting read.

It's not that hard to find.

And he's got a bigger version of that book too.

Yes.

But that's a perfect, that's a, so I've been using that for years and I got to, you know, let's make fun of myself, you know, as a manager through the years, I found myself having to do those things.

And this is why when I started doing software development, I would, the highest I would allow myself to work was at a team lead level.

I kept turning down becoming, you know, a development manager or whatever manager, because when you get into that space, you have to use these pretend proxy measurements to show that you're doing your work.

And I'm not willing to do those things.

I have ended up managing projects and managing large groups of people.

I think the most ever was maybe 80 or so people, but yeah, dang it.

So let's get back to symptoms if you don't mind.

Do we have anybody else sharing?

Yes.

We have Maksim here sharing on YouTube, not knowing expectations.

Yes.

Expectations and then follow up or if they change without one, knowing it, which is something I find very often in IT, the expectations change or requirements change without any notice, notification to the team, to the project programme whatsoever.

So I can relate to, so I can be very narcissistic or whatever here and relate to my own experiences, every one of these things.

I worked on a project once where there was a team that was supposed to be creating the requirements for some work, which I think is a harmful process, but they never really got anything.

So we, as the developers had to start creating this software without having any requirements whatsoever.

We only knew the bigger umbrella, which I'd rather just know the bigger umbrella rather than a well-written requirements document.

Everybody's had this.

I've worked with requirements documents that maybe have descriptions for 60, 70, 80 features or parts of features.

And then we get into them and we start finding out we can't write it from this list of requirements.

We need to go talk with the people who are asking for these things.

And so the work that was done to create the documents was done before the knowledge was full enough to do a good job with writing that.

That's something that I see happen over and over again.

Yeah, because there are different levels of abstractions of requirements, right?

You have a very high level requirements.

Well, I would say business expectations, which not necessarily mean business needs, where needs are at the actual something that is actually translatable to requirements, not expectations.

And then those need to be translated to something that an architect can understand, and then later translated to something that developer can understand, etcétera, etcétera.

So there are levels of abstractions.

It's very rare that companies can pierce through those levels and build a shared understanding.

So you just hit the key phrase of shared understanding.

And I believe that is very difficult to have unless we are working very closely together.

So yeah, welcome to the big enterprise IT and relatively small enterprise IT.

I mean, I worked in one of my early contracts in 2001, I think, or 2000.

Yeah, 2001, maybe.

I worked at a place that really only had two or three developers, and yet they had all these things where they had the complex requirements documents.

They had designed their architecture and their architectures was intended to be N tier, which was really popular at that time.

But what they were really writing was a client server application, which is a different version of starting to have layers.

And so you couldn't even tell the boss that, hey, this isn't N tier, this is a client server app.

And they didn't want to hear that.

So anyways, and there are ways to do that in almost every language.

And whether they were good or not, I don't know.

For those kinds of apps in those days, it was probably good.

Okay.

But let's dig into those symptoms, maybe

Let's get back to the...

Go ahead.

Let's have your list, and then also get back to Karolina here, and let's try to dismantle this as symptoms and ponder a little bit here.

So the list...

So I have an example that I give that is a list out...

I did this as an exercise with 20 people.

And I've done this over and over with groups, because that's about the size I like to do my workshops.

I asked them exactly this question.

They came up with 50 items.

Some of them are pretty similar to each other.

But let me share a few.

The most common one I will see has the word meetings in it.

And in this group, they had one which was needless meetings.

Needless meetings.

Okay.

Brilliant.

Anything.

So they will say frequent meetings or poorly run meetings.

But I would just say meetings are a potential symptom.

So meetings themselves are not the problem.

So if we say, well, our meetings aren't helping us like we would like them to, so we need to get better at having meetings.

Well, we're dealing with the symptom.

That's a way of resolving the problem instead of actually solving it.

And again, I don't agree with the idea that solving it is where we need to be.

I think either dissolving or an idea that I use, which I call pre-solving, which means let's stop worrying about our problems, and let's just work on the stuff that's actually...

Let's make the things that are working well, even working better for us.

So that's one of my typical approaches.

Rather than focus on...

Rather than saying, let's get to the root cause of this problem, let's figure out how to make everything that's already working work better.

We can talk about that later if we have the time.

I'm going to read off a couple of these things.

Here's four that really go together.

Context switching, distractions, multitasking, and workflow interruptions.

Those things go closely together.

Question

Yes.

Were those people from IT?

These are all software developers.

All software developers.

Probably at this particular workshop, it was all software developers.

Sometimes I have managers, and sometimes I will have people from finance or people from HR or whatever in my workshops, or only managers or whatever.

So yeah.

Okay.

So that grouping right there, those are things that I think of as symptoms, and I would like to have a signal.

If we see we are multitasking, I want that to be an alert.

There's something we need to deal with.

Let me go to some that really introduces to me what's the big problem, and it is the symptoms of it.

Dependency on other teams, waiting on a dependency, external dependencies, which means outside of our team or outside of our company.

And related to this is unclear expectations, which I think somebody here already noted, unrealistic expectations.

So this is a priority.

Stop working on that.

Work on this priority.

Two days later, while you're in the middle of working on that new priority, they come in, wait, wait, we have an emergency fire to put out, and we're going to work on this.

And we have a stack of unfinished work.

This is introduced.

These are related.

Go ahead.

Or even worse, somebody sets the priority, start working on that new priority, and then has problem with you not finishing the previous task because the priority was switched, but they still expected you to finish that task in the same period of time.

So this is often a problem that is put on the person doing the work, but it's really on the part of the person.

But let me say it differently.

It's not even on the part of the person who's telling people to get the work done.

I think this is a system problem.

This is a system level problem.

This is not those individuals.

The managers are just doing what's expected of a manager.

So a manager, in a lot of ways, they're kind of squeezed in the middle between the actually getting the work done and those unrealistic expectations.

And they'll lose their job.

They have a chance, depending on what country you're in, they have a chance of losing their job if they don't live up to the expectations.

So often what will happen in those kinds of situations is we get good at putting the blame on someone else.

That's one problem that we can see from it.

Another one is we have this, what I would consider massaging the numbers.

We can prove we got it done on time, but it's because we cut some things that we didn't actually, or we didn't, well, I'm going to tell an awful story.

I was working in a place that had a bunch of code that needed to be delivered for the new version of this thing.

It had millions, more than a million lines of code in it.

And they had an agreement that it would be with the customers, that there would be no major bugs or no critical bugs, no more than five major bugs, no more than, you know, they had these different level of bugs.

They just moved each bug category down one level to meet their requirement of not having so many critical bugs.

Critical bugs became major bugs.

The major bugs, which switched into being, you know, level three bugs and then so on, or level one bugs and so on.

So they just recategorised the bugs and they were able to meet their deadline.

This is fake.

Go ahead.

In Poland, we would call this painting the grass green, which is something that actually happened in Poland in terms when we had still communism or well, at least the Europeanised version of communism, because that wasn't that communism as defined.

When a delegate from the party was arriving at a certain city and the grass wasn't green enough, they really went on the grass and painted it green to make it green enough.

These were literally things that happened, right?

This is a system thing.

And in a related thing for this, for me is I worked in televised sporting events for a while, making advertising and graphics and signage for them.

But I would attend them sometimes.

And sometimes to make something look good on television, they spray the grass to make it look green.

So it already is kind of green, but now it looks green.

This is something we need to understand.

In the idea of television, what a natural colour looks like is not the same as what the televised colour will look like.

So they may need to modify the colour so that it looks appropriate on a TV screen or whatever, a broadcast screen.

And in real life, it looks kind of funky.

So anyways, this is exactly an example of that.

I'm going to give you a couple more.

So waiting on clarification is just the outside dependency, lack of knowledge, lack of skills, communication barriers, poor working conditions.

I've worked at places where we are so cramped that developers really had, you know, you can't be so cramped with other people that all you're hearing is the noise of the salespeople doing sales calls all day long and you can't get your focus.

So I see having to wear and listen to music to cut out the rest of the noise, that's a symptom of something.

Okay, I'll give a couple more here.

Onboarding, something that makes it difficult for me to be effective is I'm spending a lot of time onboarding other people.

Let's give a couple more.

Technical debt, that's a very big one in a lot of places.

Let's see, not everyone being on the same page.

I think somebody kind of brought that up.

We don't know what the priority is right now, so we're working on something that's not the priority.

Obviously.

So I often hear some of them, here's one, not taking enough time the first time.

So part of that one is it's not necessarily taking enough time doing the analysis.

I would say it's not taking enough time doing the experiments that we need to be doing, but we think we need to do it right the first time.

And so what we do is we work on our current understanding.

So these are all symptoms.

I believe these are all symptoms, and I have a list of 50 of them in front of me, but I have collected about 200 of these symptoms.

Yes, go ahead.

To sum it up with a decent, more of a generic phrase, how would you define a symptom?

So, yeah, let me get it.

So to me, a symptom is a noticeable outward manifestation of a problem, a potential problem.

So let me go ahead, if you don't mind, I'm going to get, I have in front of me a slight description that will make it easier for me to state this.

Okay.

So a symptom is an outward indication that something is wrong.

It is what we can see or feel, even if we don't yet know the cause.

So this is the way I usually give an example of it.

If I'm sneezing, congested, have a sore throat and a headache, those are symptoms.

And they may suggest that I have a cold or a virus of some kind.

The symptoms are pointing to the underlying problem, but being uncomfortable because of these things is what we're going to try to deal with.

And so instead of dealing with the problem, we might deal with the symptoms.

We take a decongestant, a pain reducer, a cough suppressant, maybe we'll take something to reduce our temperature if we have a fever.

So we're dealing with the symptoms.

And in medical terms, some of these things are signals or signs, and some of them are symptoms.

A sign is something that can be measured like taking someone's temperature.

And a symptom is something I can feel like I've got a sore throat.

So these symptoms are what we often deal with.

Is there a medication you can take that eliminates a cold?

Maybe not.

I've seen people claim that there are things they can do, but we just need to rest, drink plenty of fluids.

But the problem comes in is if we deal with the symptoms, we might feel better.

So if I feel better today, I no longer have my headache, I'm not congested, I'm not sneezing all the time, I don't have a sore throat, then I might think, well, it's okay if I go to work.

Now I go to work, I'm still contagious, and I'm spreading the disease to everyone else.

So I haven't dealt with the problem, I dealt with the symptoms.

So this started for me a long time ago.

I believe that often we're dealing with the symptoms and not the underlying problem.

And I sort of learned over the years that the, that we can't necessarily solve the underlying problem.

And when we try to do that, it's sort of like we're just moving the problem to a different space.

So often when we solve a problem, that solution becomes tomorrow's problem.

So even when we know, so this is kind of the connevant thing.

In the clear space and probably the complicated space, I think we can easily be solving problems.

You know, example for me, I can, I worked at a place once when I was kind of young, and it was raining too much.

And it started washing out some of their roads and some of their fields.

And we needed to go and dig some ditches to divert the water that was being destructive.

Well, yeah, that's pretty easy to solve.

Once we got those ditches dug, the problem went away.

Maybe it caused other problems, but you're getting the picture here.

In some spaces it's obvious and you take care of it.

But in the space, in the complex space, and I will make this argument, all software development, real true software development, if that's a usable term, that's in the complex space.

We're going to find out what our problems are as we try to solve them.

When a customer comes to you and says, this is what we need, they may not know it.

There may be a solution that they haven't even considered yet.

And the one that they, the solution they think they have may not solve their actual problem.

So we need to do this iterative discovery type thing of development.

But well, I like this.

Let's be honest.

Sometimes it takes treating the symptom before everyone is ready to think about the underlying cause.

Exactly.

You should just be here giving this.

We should be interviewing Maksim Kogan because this is the point.

Sometimes the discovery process includes attempting to solve a symptom, but we have to do this with a spirit, I think, of open-mindedness and discovery, which means we have to set up a theory for ourselves.

It's kind of taking a scientific approach.

Set up a theory, act on the theory, and then be willing to see that we failed.

Of course, sometimes we need to treat the symptom first, because if it's causing us harm, problems, it's painful, whatever the problematic result of that symptom is, because there's causality.

There's the root cause, the problem.

It has symptoms, and the symptoms also are causes for us to whatever, right?

Suffer.

And that would mean that, of course, we will need to treat the symptoms first at times to be able to get to the root cause.

But also, sometimes, without getting to the root cause, we'll not be able to treat the symptoms.

So, for example, a very common symptom I find in my line of work as an integration architect is that a lot of people state that, oh, integration platforms are useless.

They're only bottlenecks.

They're centralised bottlenecks and only problems.

And I say, well, no, that's not a problem.

That's a symptom.

Because if you stuff that system with people who are, for example, former DBAs, and I literally saw that kind of thing, where they're not trained to be integration experts, but to persist everything, they'll build so much complexity in that system that it will not be operable, because then they will be shifting most of their workload toward operations, not developing new integrations, right?

And this is, again, a systemic problem, not a problem that is of their own volition, so to speak.

But you know what?

All this kind of brought me to Tesler's law.

You know Tesler's law?

No, no.

Tell me.

Tesler's law is the law of conversion of complexity.

It's very common in user experience, and it's, well, it's from the 80s, so it's quite old already.

And it's from Larry Tesler.

And the most basic form of Tesler's law is that every application must have an inherent amount of irreducible complexity.

The only question is, who will have to deal with it?

And what we're talking right now about problem solving and symptoms and moving the problems somewhere else is, I would say, the dark side of Tesler's law, because we're moving that complexity, which is the problem space, away from us, somewhere else, for it to burn somebody else.

But basically, what would happen?

So this is, you know the book by Donald Norman, I think it's now called The Design of Everyday Things?

Yes, a very good book.

So I think originally it was The Psychology of Everyday Things, although I may have that, I may be wrong.

I might be confusing that.

So to get to the point though, that, you know, the user, the complexity should be, or whatever we're going to call it, should be shifted from the user.

So the user should not need to be trained to use something.

And this is something I learned quite a bit about in wayfinding.

So wayfinding is something I was involved in a long time ago.

That's like, if you go to the hospital, and you need to get to the emergency room, you want to go directly to the emergency area.

You don't want to have to figure out and talk to people and, you know, you want to get right there immediately.

So this is wayfinding in a hospital.

You know, that's a complex problem because they have little departments spread out all over the place.

If you need to get somebody to, you know, the place where they can start stitching them up, you don't want to be wasting seconds.

Yeah, you don't want the bleeding all over the place to get to that.

Yeah, yeah.

We have a cleanup problem.

Okay.

That's a lot of problems.

Not to make too light of it, but you get the picture.

So here's the thing though, is that often when we do the Russell Acuff thing, where he says the resolve, which I think is solving for the symptom, we end up hiding the problem and not really revealing the problem.

So I think that we need to be very careful in that space.

So this is where my theme for today, symptoms and signals is, not every symptom warrants having a signal.

So an example that I came up with is, you know, I once had a truck and the temperature gauge wasn't working well on it.

And so I didn't know it was overheating.

And the only symptom I could notice is, do you smell something like hot, you know?

And by the time I pulled my truck over, the engine had enough damage that I needed to...

So I needed to refill the radiator.

So something was leaking and be able to get it to a repair shop and it had a warped head on it.

So now I had to get the head remachined, where as if I had caught this earlier, I wouldn't have had this problem.

So the point is the symptom was not being revealed to me through the temperature gauge, which was broken.

Okay.

So that's been put...

I'm sure they didn't have those in the first cars.

The first people who drove cars, if the engine was overheating, they were paying attention.

They could see steam coming out of the radiator because they could see the radiator.

It probably wasn't even under a hood if it had a radiator.

Anyways, the point I'm making is that these were very sophisticated, mechanically minded people.

And most people driving cars nowadays, you know, maybe they know how to change a tyre.

Much of the stuff that's in the car, we don't work on ourselves anymore.

To get to the point, I want an indicator.

So the indicator in most cars is like a little gauge and sometimes there's a flashing red light.

But those are indicators you need to look at.

What if you could have also an audible indicator?

And these are available.

You can buy them from companies.

I looked it up online.

You can buy a thing, you attach it to your system.

If the car is starting to get out of the range that you feel is appropriate, it will start making a loud buzzing sound.

That's a signal.

So all I'm saying is all these things we talked about so far that are symptoms, I'd like to kind of evaluate, would I like to have a signal that alerts me to this?

That I have a problem I better investigate.

It doesn't mean I have something to solve.

Like smelling, going, boy, that smells hot.

It may just be as a symptom of a car.

It may just be that, just an example, a bird started building a nest inside your engine compartment and they're long gone.

And now the nest is starting to heat up and smell.

So yeah, okay, I can go out there, dig it out.

The car isn't being damaged.

I actually had that happen once.

So the car isn't being damaged and we've gotten rid of the problem.

I would never, if it was a live bird in there, I'd be really concerned.

But anyways, you get the point.

So I would kind of say that we need to be able to differentiate which of these symptoms are something that's necessary for us to pay attention to right now.

And one of those things that I started taking as symptoms years ago is what Kent Beck and maybe Martin Fowler had talked about in their refactoring book or one of those books about code smells.

So I take code smells as a symptom.

If you don't know what a code smell is, a code smell is something we can look at our code and see an indication that we might have a problem.

An example of a code smell is a long method.

Another example of a code smell is, let me think of a really easy one, is a lot of ifs in the code.

So convoluted, deeply nested loops and if statements and so on.

So if we have nested ifs, that's a code smell.

Now, some people will take it to extreme, which I happen to do that.

And if we have more than one or two ifs in a method, we're probably trying to do too much work.

So what is it a smell of?

It's a smell that maybe we're not paying attention to the single responsibility principle or having our code nicely divided up.

There's lots of ways we could.

This might be an indication of a problem and it might not be.

So code smells.

And then I would say now we also could think of process smells.

So a lot of these things that we have here could be process smells.

For example, if we find we're context switching quite a bit, what's the underlying problem that's causing?

I'm really looking to go into the underlying problems here right now.

I'm just saying, well, if we're getting a lot of context switching throughout the day, how can we make that a signal?

If we see that as being underlying, there might be a problem to this that we want to be alerted to.

I did a study once at a company where we were noticing what we came to call in the industry thrashing.

So thrashing on a hard drive that's fragmented, you can hear the hard drive moving a lot.

Nobody has hard drives anymore.

But you hear that hard drive that moved.

What's that?

Not that kind of drives.

Yeah.

So a hard drive that had a little physical head that would move across a disc, if it was thrashing, it meant it was trying to get the information it needs because it'd been fragmented all across this hard drive.

So we would want to get rid of that fragment, defrag our hard drive.

And so this thing we were using in the industry for people as well.

So if we notice that people are working on five different things and they're switching between them, they're multitasking, they're getting context switching.

The context switching often happens when another teammate comes over and says, hey, I was assigned to work on this.

I don't know anything about it.

Can you help me?

Well, now I can't get my work done because I've got to help you get your work done.

And now that's causing a conflict in a way because I know I'm going to be, my performance going to be judged.

Did I get my work done today?

And so we are, it's kind of distracting us from doing teamwork.

But the point I'm making is if we believe that the multitasking and the context switching are indications of a problem, I want to be alerted to that.

So if we have a system, let's just say daily, we have a meeting like in Scrum, they used to have a daily meeting.

And one of the questions maybe the manager or the Scrum Master would ask is, is anybody blocked on anything?

Well, that's an indication that we're not paying attention to stuff in real time.

So I would say that's a smell or that's a process smell or a symptom of an underlying problem.

The underlying problem is probably has to do with communication on all of these things.

So when I see these things, I want to get an alert.

So what I used to do as a consultant, I still do this, is if I hear a word more than a few times come up in the conversations I'm having in the meetings or gatherings I'm having with the people I'm supposed to be helping, I will make a note of it and start keeping tick marks to notice how often does that word come up.

So if it comes up five times, maybe it's not important.

If it comes up 10 times, maybe it's getting important.

If I see it a hundred times during the day in my different conversations, I want that to really be a bold indication.

So if I've got my little piece of paper and I've got these words and a couple of them have a hundred tick marks, that's telling me I want to, that's an alert.

That's a signal.

That's what I'm looking for here.

So that's why I call this symptoms and signals.

Some of these symptoms, maybe there's an underlying problem, but it's not critical.

But boy, if we have, if I hear meetings, I have one place that I did this and I had a couple of hundred software developers that were involved in the whole thing we were doing and I heard meetings come up over and over.

So then we had a bit of a retrospective to talk about meetings and it turned out most of the developers and some of these were highly trained, very highly paid, you know, PhD level people that owned patents and stuff.

You know, these aren't people that are just, you know, like my level, just writing code all day long.

They're inventing important things.

Some of them were in meetings up to six hours a day, four to six hours was typical.

And so my question is going to be, when do you get time to actually write code?

If that's what your job is and they just say, well, yeah, that's a big problem.

So the issue here isn't how good the meetings are.

The issue is why are we having the meetings?

What is the use?

So we need to know the purpose of the meetings.

And it really, in this case, a lot of times these people were needed in meetings because the people who were needing to make decisions didn't have the knowledge that was needed to make those decisions.

So they would call, there was actually one guy on one team that his direct manager and the vice president above him would come in throughout the day and say, oh, we just need to borrow him for a few minutes.

Well, a few minutes usually meant one or two hours.

And by the time they come back, here's another symptom.

The person that I need to ask a question to isn't available.

So that's the dependency.

So when we're waiting for dependency, that's a symptom that we don't have a communication method that allows us to not have to have that waiting.

So this is all this is really about.

It started for me when I was trying to write a guideline for myself on how to make it clear to some management folks, and this was just in the last year, that some management folks that the things they are seeing are things we need to be dealing with.

And they're trying to solve for the symptoms instead of underlying problems.

And I was using chat GPT to look through all the materials I've been collecting.

And it came up with, it's about queuing.

It said, well, the waiting is a signal.

The waiting is a signal that we need to deal with whatever it was.

I thought, oh, that's the terminology I want.

I don't want just to have the waiting.

And then we deal with, instead of dealing with the, one of the symptoms of waiting.

And one of those is, I can't work on this because I'm waiting to get an answer back from someone else.

So what do I do in the meantime?

That's a symptom.

Money managers will say, always have some other less important thing to work on.

So when you're waiting, you work on that.

This is, we introduce inventory to deal with the waiting, the busy, the queuing, because we're not busy enough.

So we've dealt with the symptom rather than the problem.

The problem is we're not getting answers to questions in a timely manner.

Now that could go with other things than waiting with questions.

It could be, I finished my work and now I, you know, I put in a pull request, right?

And so now I'm waiting for someone to review the code before I can either send it to the testers or work on it more myself.

Well, these are symptoms.

I think any company that's using PRs is that's a symptom I automatically will look for.

Why do we think you, why do we think PRs are useful?

And usually because managers believe that dividing the work up and having people work solo is useful.

Why do they believe that?

I don't know why they believe that, but that's an extremely common belief that we need to separate the people doing the work so they can get their work done.

I would suggest there's, this is a systemic problem.

It's a system problem.

Anyways, I've been rambling on forever.

I hope that my, our listeners aren't getting too bored, but so this is really the topic.

I'm not talking about what are the solutions.

I'm talking about, are we, do we have a way to really alert ourselves that we have a problem instead of just, you know, that the symptoms are not the problem and that we need to pay attention.

When we see the combination of symptoms, such as I brought up the first one, context switching, workflow interruptions, distractions and multitasking, those kind of group together.

And when we see those coming up in these kinds of exercises, I'm going, yeah, we, this should be a signal to us that we have a serious problem.

And then those people that experienced those symptoms get in trouble because they're not delivering.

That's right.

Even though they're raising that these things happen and nobody's digging into the problem and they, the problem is not resolved.

So this, in our space, I've seen advertisements, we need a developer who's good at multitasking.

So we're actually advertising to have somebody to fulfil the role of working in the most ineffective way possible that we can multitask.

We cannot multitask.

This is a, there's enough research.

I said that pretty boldly, but, you know, read Kahneman and all these people, you can find references to research that shows, no, we can't actually multitask.

So there's a Zeigarnik effect and other things like this.

Our brains work on stuff in a way different than we wish it would.

We are single threaded.

We are single threaded.

So if a boss comes in and says, here's a priority, got to stop working on that and get this other thing done first.

We can set that thing aside, but our brain won't stop working on it.

We're now increasing the cognitive load that we have individually.

And this is back to that supposed Drucker quote.

Much of what we consider to be management is just making it hard for people to work.

And so I know for myself, my dad used to say this and he was an engineer and he was quite good troubleshooter and he worked in the phone company in the US, you know, in those days that a lot of brilliant people, you know, were in that space.

That's where a lot of things came from in our world, like the C programming language and stuff.

So he wasn't a programmer.

He was an electronics and electrical engineer, but he would say something effective.

Let me see if I can form the way he would say it.

First of all, there's a thousand right ways to do anything.

That's one of the things he would say.

That's true.

And so if you could bring me back to our topic and maybe the exact quote I wanted to use was there.

When we're multitasking, we are overloading our brain.

And my father would say this sometimes.

So we're deep in something, we're not coming up with the solution.

He would say, we need to sleep on this.

And that's an observation that probably goes back way, you know, probably goes back thousands of years, is that tomorrow the solution will come to us.

Today, we're done.

So, you know, our brain is not going to come up with a solution.

There's too much overloading us.

And I've watched teams try to come up with a solution for hours when we go take a break, take a walk, maybe go get lunch.

We come back and somebody goes, wait, I know what to do.

So there was a guy who wrote a book called The Art of Thought a 100 years ago.

I think it was almost exactly 100 years ago.

The guy's name was Graham Wallace.

Graham Wallace, W-A-L-L-A-C-E.

And he said there's like four phases to thinking.

One is the first phase is, I think it's investigation.

I might get these wrong.

You've got the investigation.

You get deep in the problem space and you start thinking about it.

You do some research.

You look some things up.

The next one is incubation.

You leave it alone.

And you let your, you go to the opera.

It's one of the, I think the examples he gave, but who goes to the opera anymore.

But, you know, you go and do something else.

I know one person.

Okay, there you go.

And I love going to, I haven't been to an opera in years, but when I was a kid, you know, in school and stuff, I'm not putting it down.

I think it's great stuff, but you don't see as much of this anymore.

Anyways, so you have incubation.

We leave it alone and go do something else.

I like to go walking.

I like to go walking.

And the most common thing I hear is take a shower.

Your best ideas come to you in a shower.

And another one that I often hear is as I'm falling asleep, my brain activates.

It goes, oh, wait a second.

I know what.

And I've had it for myself, both that and I wake up in the middle of the night and go, oh, I know what to do.

And now I got to where I would keep a notepad by my bed.

And nowadays I just keep my phone and I could speak into it.

Oh, wait, I think this might be the solution.

And the next morning I kind of find out maybe I was in a dream state and it was wrong.

But that's another time.

So those are common things.

You know, these are common switches to switch the context we're in so that we can reroute our way of thinking.

And I had that conversation, oh, so long ago with Mark Richards over exactly this topic of just not being able to solve a problem.

And there's just switching your context.

So it comes to you.

I remember Mark saying that at times he doesn't take a shower in the morning just to take it later in the day when he stumbles into a problem, just to switch that context for himself for a minute, go to a shower.

And then it comes to him to figure out, oh, this is how it's supposed to be done.

Because we're taking a break from that focus.

That's right.

And in terms of multitasking, I know that my wife would say I'm often multitasking.

And she obviously knows that this is not true.

But what I do with my ADHD is that I often play games and watch a series, TV series at the same time.

Yes, yes.

That's not multitasking.

That's my brain just going numb.

Well, so you bring up a really good point here, though.

Now, there's techniques for staying awake during a meeting.

So I have to learn some of these techniques because, you know, I'm getting bored to death and I'm thinking about other stuff.

And one common one is to be doodling, doodling while you're doing.

I had my own mechanism.

I had long lists of things I was trying to memorise.

And I would write them out and I would just copy them out during the meeting.

OK, it looked like I was participating by taking notes or something.

But in reality, I was just trying to keep myself alert.

And there are other ways to do this, too.

One of mine is, for example, just playing a game on the phone, literally.

To stay awake during the meeting where I had to be, let's say, attentive, not exactly paying that attention to because the topic right now is not the topic I'm supposed to be even thinking about because it doesn't relate to me anyhow.

But I need to pay attention enough to be able to switch to the meeting when there's that topic that I'm interested in and participate in it.

So I'm basically to keep still sharp.

I'm literally playing games on my phone quite often.

And that happens a lot in different meetings.

In consulting, that's a regular thing that those meetings I get invited to, they span for two hours and I'm literally needed for 15 minutes.

So we can keep our our brains can be kept active in dialogue.

This is maybe another topic for another day.

I was reading a book from David Graeber called The Dawn of Everything.

And there was one little chunk in there where he talks about the window of consciousness.

And he's saying the window of consciousness is seven seconds.

I'm going, how do we know that?

And so then he says, and this means the time we were aware of ourselves and focussing on something at the same time.

I think that's sort of what it is aware, but I'd have to look it up.

OK, so the window of consciousness, but it can be extended in dialogue.

It can be extended in conversation for even more than several hours.

Well, I wanted to find the research on that.

And I've actually tracked some of that research down.

I can quickly try to let me let me quickly try to find that just so I can mention those things, because I believe that if we look down here, I think is useful maybe for people.

So I'm opening up a different screen here and let's see.

Give me just a moment.

Window of consciousness.

Yeah.

So I've got some notes that I took on this.

So the essential thing that he says is something to the order of this.

He states the following when we are capable of self-awareness, it's usually for very brief periods of time.

The window of consciousness during which we can hold a thought or work on a problem.

It tends to be on average open on average for roughly seven seconds.

Well, man, is there research that shows us that?

That's what I wanted to know.

So what neuroscientists and it must be said, most contemporary philosophers almost never noticed, however, is that the great exception to this is when we're talking to someone else in conversation.

We can hold thoughts and reflect on problems sometimes for hours on end.

Now, I do not know if that's true.

All I know with these kinds of things, these kinds of facts.

So I actually looked into find research for this and I found at least three or four different researchers that support this.

And so that's I'm just stating that to get to the point.

I use these kinds of things to ask myself questions like this.

What if that's true?

So this went down.

This caused me to go down a path where I've now read three or four books.

One is called that I read in 2022.

One that I read is called Dialogue and the Art of Thinking Together.

Well, that was a really powerful connection.

I knew I'd read the book.

And so as I read this other book from David Graeber, it was like, oh, wait a second.

That reminds me of this other book I read.

And now I'm doing a deep dive into this book on dialogue.

Connected with that is also the idea of dialogue mapping, which comes from a guy named Jeff Conkle, I think, that I learned like 20 years ago.

How do we capture these things?

And another thing is from Nancy Kline, who has a book called something like this.

The Most Important Promise I Will Not Interrupt.

And so what she seems to think is that we can help people think better by being really good listeners.

Oh, that's very true.

She gave me an exercise I started doing.

I think I learned about this 20 years ago from her first book called Time to Think.

And in that book, I think she suggests practise listening to someone else as if the very next thing they say will be the most important thing you'll ever hear.

Well, that takes a lot of effort.

It does.

But on the other side of this coin.

Is the rubber ducky.

Sure.

The rubber ducky debugging method.

Brilliant.

Because this is exactly the art of listening or objectifying, anthropomorphising the duck as your listener.

And you're just thinking.

So you could play the role of the rubber ducky.

Yeah.

But in a slightly more helpful way, the rubber ducky itself doesn't give us anything back.

Now, in the book, The Most Important Promise I Will Not Interrupt.

She says we shouldn't be spending our time thinking about what we're going to say when we're listening.

So she gives an example here.

Well, in the book, The Dialogue, The Art of Thinking Together, he quotes someone else saying, we're not listening.

We're reloading.

And I thought, well, that's a pretty good.

That's because we want to defend our position and we want to counter their position.

And the book that I'm talking about here, he's basically saying there's got to be this time where we're free to share ideas without count people countering them and shared it be open minded enough to hear every idea.

So in Nancy Kline's book, she's saying you can eventually you can ask a question like this.

What more do you want to say about this?

Or is there anything more you'd like to cover?

That's that's very coaching like.

That's probably very coaching like.

And I think her background is maybe I think she might be a Quaker.

So in the Quaker religion, you have this thing where each person gets to have their say.

And I'm not real.

You know, I don't have a lot of knowledge about this.

I could be getting it wrong.

Please, those of you out there know better maybe can let us know in the comments.

But the basic idea is we're willing to hear what each person say.

And what this comes down to is most ideas cannot be shared in a matter of a sentence.

But what I've noticed in a lot of conversations, the sentence gets when when we finish the sentence, someone else pops in and wants to talk when I just I have another sentence to give into the conversation.

I could I remember being on a panel once one of these, you know, discussion panels at a conference.

And I proposed a what I would call a rhetorical question.

And somebody else wanted to answer someone else.

And I said, wait, wait, no, I'm saying this is something to contemplate.

I'm not asking this to get an answer.

I want us to contemplate this.

So I do have someone I think is like a genius level person that will call me up sometimes.

And they will say this.

I have something I want to talk to you about, but you don't need to listen.

And so I'm being their human rubber ducky.

That's exactly right.

And so I do listen, but I take it as my job is to keep making it easy for them to open the doors they're trying to open in their own path.

I do the same with people and then enable other people to do exactly the same with me so that they come and treat me as a rubber ducky.

And I just go, yeah, OK, and what more, etcétera.

And it is like, whew, that's really valuable in that sense, because that's just like really going to the root of the problem at times through that kind of, let's say, active listening.

But before we jump in, since you mentioned dialogue and the art of thinking.

Yes.

Boom.

Yeah, yeah.

There's a workshop tomorrow.

Tomorrow on this.

That's right.

Now, I better check how many people.

I have only opened it up to 50 people.

There's seven spots left or eight.

I will open it out to more spots right now.

No, there's still a few spots left.

Don't worry, Woody.

I do have a waiting list on it.

So if you get onto the waiting list, I'll open up more spots for you.

So I'm going to argue this.

These sessions are not for me to teach other people stuff.

These sessions are for me to learn myself.

And if others learn something out of it, too, that's great.

So my goal is...

And a little bit of a teaching from the back of the room.

Yeah, I'm here to learn.

I'm not here to teach.

And, you know, if I take, you know, Feynman, Richard Feynman used to say, if you can't explain it to a five-year-old, it's not exactly what you say to a beginner.

You probably don't understand the thing yourself.

And so that's just part of it with what we're talking about here today.

I'm still in infancy in this space, the symptoms and signals.

I think the signals are something I want to get better mechanisms.

One mechanism I mentioned was I would take the tick notes and write down, write down, you know, how many times I hear a word.

And meetings was a good example for that.

But I want other ways.

And one way that I've been using lately is I have a short list of things that I'm going to be looking for.

So if I'm consulting with a team and they have a backlog, I want to know how many items are in the backlog.

And then if we have more than a few items, I want to have their tool they're using, put up an alert for anything that's been on the backlog for more than a week or two.

I want to see the ageing.

So that we can actually see an alert then come up in some systems.

Like here's an alert that this has been this has been here for, you know, two weeks or three weeks or four weeks.

I've worked with teams with backlogs of 150 items.

I would say, you know, 95% of those items have been on there more than two weeks.

And some of them have been there for a year or more.

This is very problematic.

So those of you who take offence to these things, I'm sorry about that.

Backlogs are generally not a good thing.

We need to limit our WIP to one item.

So our work in progress limits.

Within bridging the gap, we try to use backlogs and try to use Kanban for the purposes of the project and start outlining these things.

This just didn't work.

At this point, there's five of us.

We were trying to set up tasks and assign them and try executing them.

First of all, nobody could update the board sufficiently enough.

Second of all, some of those tasks were just pushed back for weeks.

And we ended up, no, we just do what we do best.

And everybody has a space that they are doing.

And they're just doing their job instead of like, oh, we should assign this to this one and this to this.

It doesn't really go anywhere in that sense.

But you know what?

Another sign that this is what I learned from body doubling, which is a method for people with ADHD to get focus and some sort of a psychological pressure on accountability of completion of tasks, is when they try to declare for a two-hour-long body doubling session, what they're going to be doing over the next two hours.

So it's not an estimation over like a workload estimation spanning over days, etcétera, it's the next two hours, right?

People either do it very unrealistic.

So they have unrealistic expectations and they get confronted with that by the end of the body doubling session where you do a checkout.

And then they learn to estimate better because they learn how well they work in a specific state of mind, etcétera, because part of the check-in is how are you feeling today and what's on your mind.

Or they start declaring tasks that are too vague, right?

And if I see these kinds of tasks on a backlog that are very vaguely described or these kinds of tasks that somebody declaring on the body doubling session that I'm facilitating, that's for me an instant signal that I need to react to and actually prompt and ask, hey, hey, hey, hold on, not specific enough.

I know we're doing body doubling, everybody's going from a different department.

I have no idea what you guys do professionally.

That's perfectly fine.

But this sounds very vague and very general, which means you can just swirl around and declare you did it, but you didn't do it, but you did it, but it wasn't sufficient, etcétera.

So the outcome is far not deterministic.

And that's another kind of like a symptom that I personally pick up on.

So the symptom, if we relate it back to that, the symptom here is what?

The symptom is...

The symptom here would be that, well, going back to the quote, if you cannot explain it to a five-year-old, so that you declare that you're going to do something and you don't even understand what you're going to be doing because you cannot even express it properly.

So that means maybe you should not be doing this.

Maybe you should be first focussing a little bit on what is the actual scope of work that you need to be doing.

Because for example, you didn't do your planning and you don't know what are you supposed to do.

You're just grabbing at random stuff because you're just joining the body doubling session and you forgot to prepare, like really think through what you need to do.

So you're making me think of an experience I had many, many years ago, probably up to 20 years ago.

I was hired to work for a company that had this well-known, extremely capable programmer who needed someone to sit with him.

And my main job was to say things like that.

That's a really good idea.

Let's finish this other one first and then we'll take a look at that.

That was my main job.

So that sounds like an early version of what you're talking about here.

Not exactly.

But my job was to help them stay because they would do the yak shaving kind of a model or that kind of a thing where they would go down a rabbit hole that would lead to another rabbit hole that would lead to, oh, and we got to change these foreign keys.

And then we got to, it's like all these other things come to mind.

This is a problem in a way with a large backlog is we think that that's where we can put all these things that we should be doing otherwise, but they will come up naturally anyway.

So we usually don't need to do that.

Well, I can go on and on on these things.

I'm not sure how much time we have.

Plenty, Woody, plenty.

We can go on and on.

Okay, but all right.

So we got symptoms covered.

We know that problems are problems.

Problems are not that really hard to define.

They're problems, right?

Should we define what the problem is though then?

So what I see is that with something like meetings ties into dependencies on other people, ties into the queuing.

So most meetings, the purpose of most meetings is to discuss something so that we can plan or schedule or document and so on.

We're not actually doing the work.

We are doing the work around the work.

And so this is like in lean terms, we might be doing non-value added work.

That's still necessary.

In lean terms, you have necessary non-value added work and unnecessary non-value added work.

Like in software architecture, you have functional requirements and non-functional requirements.

So in most of the work that we do, there is going to be some amount of non-value added, but necessary things to do.

Value added means adding value to the end product that we're creating.

So a good example would be if we're writing software, our discovery process is part of the value added work.

The person who's scheduling people is not part of that value added work.

But that's necessary in a lot of organisations.

I believe that stuff that we don't, that people can self-organise.

We can self-form teams, self-organise, self-direct, self-manage.

There's four or five of these or more self things that we could be doing that eliminates a lot of what managers do for people.

So how do we get to the problems?

I want to skip to a slightly different point here.

When we started learning to work well as a team and adopted what we then were calling mob programming, which came from some people that worked at ThoughtWorks and had written a paper about it 10 years earlier.

The idea that everybody's sitting at the same computer discussing what we're doing and doing it together.

We're actually doing the work together.

When we started working that way, which kind of happened accidentally, what we found was that a lot of those symptoms disappeared.

For example, the queuing that happens

when we're waiting on dependency,

that's where we're being put into a queue,

stopped happening for us

as long as the people on our team

could answer their own questions,

which elevated the problem to a different level

because it was the external dependencies,

the people we were dependent on

that were on other teams or in other departments,

that it really became obvious quickly

that was a huge bottleneck.

But when the local bottleneck is the way we normally deal with this when we are working alone, we just pick up other work to do.

And I've had bosses say, well, while you're waiting for that thing, do this.

So the pain of the waiting isn't made apparent.

So the symptom is masking the problem.

The problem is not that we aren't busy.

The problem is that we are queuing, that we can't get answers to the questions immediately.

What we notice when we start working as a group that the big blockages outside of our team was product owners, which I think...

So roles are always a problem with this.

Roles are a symptom that we haven't found how to manage our work well.

And that'll offend most managers.

But anyways, the idea that product owners would not often get back to us when we had a question for them in a timely manner.

So if we have a question, they answer it right now, we could keep working on this thing.

But if we have to wait, we're now queuing and we're waiting for them to get back.

And it may take them an hour or two before they even respond and say, oh, you have a question?

I read it here, I don't understand it.

Well, now we're starting the real process of the communication.

But if we try to explain it to them through an email, there's more queuing and more queuing.

So because they weren't on our team, we were just building the queues.

Another one was the testers.

We finished something, it needs to get tested before it can be pushed to production.

So it's gotta get through that.

We were not doing pull requests, but that could have been one there.

This was 15 years ago.

Another thing was the database people.

They were working in a different department.

So if we had database work to do, we need to put in a request for that work.

And the last one was what you might now call the DevOps people, but this would be the people who would do our deployments.

Almost all the work that we had had to be deployed by somebody else.

So we noticed those four areas would cause deep queuing problems.

If we measure queuing well, and I have lots of slides on this, we will see that we spend most of our time waiting.

And Reinertsen with another book, I can turn around and pull off my shelf.

This is not a picture of a bookshelf.

That's a real bookshelf.

So the principles of product development flow, he talks about queuing in this book.

And what he says is queues are the root cause of the majority of waste in product development.

And what we do is product development for developing software.

Mostly we could think of it as product development.

Is that true?

Well, I don't need to know whether it's true or not, but I can ask myself the question.

What if that is true?

I have talked to many executives now, and I have a pretty good sense that this is true.

So I've talked to executives and companies, and when we get to the root cause of a lot of problems, it's the queuing.

So if I cannot talk to a product manager, and I have this at one company, except every Monday during a specific meeting, then that's a queue of a week.

If I have a question for them after that meeting, I'm in a queue for a week before I can get an answer.

And you can see that's going to drag out our work.

At that particular place, I used a value stream map, a very rudimentary value stream map showing time actually working and time of non-value added, which would be like queuing.

And what we found in his six-month project, we only really worked on the code about three weeks.

Three weeks of total time actually working on the code.

So what do we do in the meantime?

Well, my boss had told me, and I was kind of a team lead of this effort.

And then above me was a boss, and that boss said, we'll just find something else to work on.

And I said, well, what do you mean?

Well, just save up your questions.

What do you mean?

Because we can't continue working on this till we get that question answered.

So there's nothing to save up.

And so what we ended up doing was we actually scouted, we walked out into the company, it was a huge financial firm, and we just asked other people, is there anything you need help with?

And that's what we did to fill our time.

And my boss actually said, that's okay.

This product expert, their time is very valuable.

So we only get access to a couple hours a week.

All right, if they want this work done in three weeks, we could do it in three weeks, but we need to get our answers immediately.

If you want your work done whenever it gets done, then we can keep working this way.

And that's what we did.

And I actually learned a great deal on that about queuing.

That's where I really first started, and that would have been 2001 or so.

Well, what I'm sharing right now is not the original comic because that was instead of chat GPT, that was compiling.

Yes.

That was one of the queuing people just fighting swords on chairs and whatnot.

It's a very old XKCD issue.

And it's that old?

How old is it?

303, let's have a look.

XKCD, probably.

I started messing with chat GPT about three years ago, but.

Yeah, but XKCD is now, what, 3000 something.

So that was issue 303.

I don't know if these are dated, probably not dated.

No, they're not dated, unfortunately, anywhere.

But if the current number is 3168, then this is 303.

Well, the chat GPT here, it says the initial release date was 2022.

Yeah, but that was the comic I found this one here.

Oh, it's Mark, it's pirated.

It's pirated, it's a redo.

Okay, I'm sorry, I misunderstood.

I misunderstood.

The original was compiling, right?

Get back to work, my code is compiling.

Sorry, I can't, queuing.

This is a really good point.

So I worked at a place where to do the build took three days.

So this is because of circular references and stuff like that.

So what do you do during this build period just before a release?

And so what the team did was automate that process.

And it turned out eventually they got it down to 45 minutes, which I think nowadays would be considered a monstrously long time.

But no individual could run a build in their debugging process.

So they could only work really with very refined small parts, tiny batches, tiny iterations, and are tiny bits of work and try to work only with having to rebuild your own component.

So this is a great topic.

So, okay, so that was a modification of one from decades ago.

Yeah, quite a long time ago.

Seeing that guy speaking at a conference that had to be like 2015.

He was already extremely famous by then.

So that 303 would be, yeah, compiling.

But so this goes with, that's queuing.

That's called queuing, that waiting is queuing.

So what we mostly do is we find other things to do, which could be, and actually I'm doing a session next week, one of my public sessions on mob programming or ensemble programming and AI.

How are we going to deal?

And this is one of the big problems is the queuing.

I would argue that what we normally do to deal with queuing is dealing with the symptom, that we have to have something to do while we're waiting.

In my earliest days of programming, I had no compiling because it was written in an interpreted language.

So you didn't ever have that compiling problem.

That didn't happen for me until much later.

I think I wrote all my first five or six years of programming was done in BASIC.

And somewhere along the way, I learned C, which is a different thing altogether.

And then I learned, and then things like, you know, in the nineties, a Visual BASIC came out and other tools.

But yeah, when you're in a non-compiled language, you don't have that exact same thing.

Yeah, but you know, anyways, I love this topic.

Yeah, go ahead.

Just to top the topic off.

Yes, let's do that.

How can we dig into what is the problem?

Other than realising that we deal with symptoms, not the problems, other than finding signals.

But if we already found the signal, right?

We have a signal.

That means we have a problem somewhere.

That's basically, I'm basically asking how to do RCA.

So when we get to the, what's RCA?

What is that?

Root cause analysis.

Okay, yeah.

Root cause analysis is an area that's really problematic.

Is we believe we need to get to the root of the problem before we can start trying to solve it.

And I think that this does misdirect us.

So the pre-solve idea that I've been working with, that I kind of mentioned was, a lot of those symptoms went away for us.

So the queuing problem, we never worked on the queuing problem.

We never worked on the dependency problem.

We never worked on the multitasking problem.

Rather than trying to find out what was the underlying problem, we were merely trying to work on turning up the good on a few things, which I already knew from my experience are useful.

And one of those things is getting better at collaboration.

So we were studying and practising getting better at collaboration.

And what happens when you do that?

In my opinion, when we work on getting better at collaboration, we are not focussing on the problem.

We are focussing on turning up the good on something that's already, we know is good for us.

Making things visible is another one.

So one of the problems of not having things, not knowing what's been prioritised and or the priorities constantly changing is finding a way to make all work visible.

And my initial way of doing that was to use something like a Kanban.

But it's just a big workboard where if you're working on something and it's not represented on the board, your one main job is to get it up on the board just so we can start seeing the load that we're under.

Because a lot of the work being done at that particular job was that we were working on stuff that nobody else was aware of.

Things were hidden.

We need to make everything apparent.

Now, it's one thing on a construction site.

I had a contractor's licence for a while.

On a construction site, you can see everything that's being done even better than most factories.

If a guy's carrying wood from here to over there and you know that's not the right place to do it, you can see the thing happening and you know what's happening.

In a factory, I can walk into any factory and I've been asked to come into some factories and look for the problems they might have.

A symptom that we're not, what we have figured out flow is we've got boxes of parts.

If a machine has boxes of parts before the machine and boxes of parts after the machine, after their operation, that's an indication that we have not paid attention to flow.

Because the minute something goes into a box, it's entering a queue.

So we can measure queuing by just measuring the number of boxes.

We don't need to measure cycle time to see that.

It's an instant indicator.

This is an issue with a lot of things we use.

So if we're trying to identify problems, we can start educating ourselves.

In software development, I have literally asked dozens, maybe hundreds of companies, how much inventory do you have?

And only two or three companies said, oh yeah, I can show you that.

And only one I think was doing a good job with it.

Most of them asked this question back, what do you mean inventory?

So that we don't even understand that we have inventory and that inventory described as anything we've worked on that a customer isn't using yet, that's inventory.

So if I've worked on this feature and others have worked on it, and over the last six months, we've been working on it, but it's not deployed to someone actually using it, that means it has to be more than just behind a feature flag.

It has to mean people are actually using it.

We have inventory.

So just knowing these kinds of things is useful.

So how do we get to solving problems?

I think in the clear and complicated space, it's pretty straightforward.

So in the clear space, we automatically solve it.

Right now, if I nicked my finger and got a little bit of bleeding going, I can go wash it, put some antiseptic on it, put a Band-Aid on it, done.

That's the clear space.

But if I feel like I got a pain in my stomach, then I can't put a Band-Aid on that.

And so that might be in the complicated space.

That could easily turn into the complex space.

So there are no easy answers to these things.

I would say usually root cause analysis is going to lead us to solving a problem that will become our...

The solution of that problem will become our next problem.

We just don't realise that we're merely rearranging our problems most of the time.

99 bugs in the code.

99 bugs in the code.

I take one down, fix it around.

Now I have 128 bugs in the code.

There was a study I once read, I wish I could find it again from IBM, that said that 70% of one-line code changes introduced a bug.

One-line code.

So somebody has got to have a lot of documentation, a lot of repositories.

This was something I read 20 years ago.

If that was true, that's really problematic.

And this is what they call failure demand.

Somebody's going to need to work on that eventually because we failed to catch that we had a problem.

Yeah, so to put a cap on it, I'm not sure that actually...

So this was back to Ackoffs thing.

It's not necessarily the solve.

It's going to be the dissolve.

So that means we got to go to the systems level.

The system level.

This means several layers up above where the work is done.

Often the solutions that are down where the work is done are working on symptoms.

If we move up slightly above that, maybe in a system like with bug fixes where we actually do identify the bug and fix it.

That's the complicated space.

I don't think that's really the complex space.

We're talking about people.

We're talking about working with each other.

We're talking...

My big solution really is we have to recognise that most of what we think we believe is wrong and stop believing in that.

Go to some kind of the Deming thinking that we need a constancy of purpose.

And that means 5 years commitment, 10 years commitment.

Not we're going to try something for a little bit.

I've had people who'd say to me like, oh yeah, we tried TDD.

That didn't work.

Oh, show me what you did.

Yeah, we tried it for two days.

And it just was slowing us down.

Okay, you have to get good at something before you can make that decision.

You can't make a decision that TDD, test-driven development won't work for us in a matter of moments.

Everything is slowing you down when you just begin with it.

Because you introduce a lot of cognitive load to actually be able to cope with it.

So basically anytime you're beginning in something completely new, you will be very slow at it.

It's just normal.

When you use proficiency, you get speed.

But you need to get that proficiency somehow first.

Yeah, this is back to my childhood days of playing music.

I learned some piano lessons and stuff as a kid.

And my brothers had a rock and roll band, a little rock and roll band.

And their bass player quit, which is the kind of thing that happens in rock and roll bands.

And somebody just, ah, I'm getting out of here.

And so they came into the room and said, hey, you're our bass player now.

And they just taught me thump, thump, thump, thump, thump, thump, thump, thump, thump, thump.

You know, it's like, that's what you got to do.

Do this over and over.

You know, so the issue, I guess the point I'm making is we can take a step forward.

I didn't become a musician by doing that.

I became a musician by now practising that.

And as a matter of fact, I would argue that I used to teach music lessons, you know, when I was a teenager and into my early 20s and stuff.

And the students that would practise a half hour a day, within a few weeks, they're starting to get good.

And they're getting more and more excited about it.

And they're willing to, you know, extend it.

Let's practise 45 minutes a day.

The ones who go to practising an hour a day on their own, yeah, I've gone, yeah, they're probably going to turn into musicians.

The ones who come in the next week and didn't practise, they're never going to learn it.

This is true.

Maybe we need some kind of a way to get the skills we need that we don't yet have.

And that often has to be by working on examples.

You don't learn to become a concert violinist by playing concerts, right?

That comes later.

We need to get the skills earlier on.

I was watching a video the other day about Fosbury.

The guy who did the Fosbury flop, which is a way of jumping over in the high jump.

Jumping over the bar backwards.

They used to do a thing called the roll.

And other things was a scissor.

These were the ways of jumping over a bar.

He studied the physics of it, I guess.

And he came up with this thing where we leap over backwards.

And now probably every, I think every world-class high jumper uses his method called the Fosbury flop.

Well, we don't solve these problems by getting better at the way we used to do things.

It takes some new ways of thinking.

I learned to do that when I was in high school.

Very uncomfortable for me to leap backwards over something.

Yeah, so anyways, you get the picture.

I did learn that maybe this was a closing thought to share.

When I was about 45 years old and started working with other people in software development, I had already learned that if I say that won't work, somebody's gonna prove I'm wrong.

So I stopped, by that time in my life, I stopped saying that won't work.

So when I heard about pair programming, I didn't say that won't work.

I said, I'd like to learn how to do that.

Same thing with test-driven development and so many other things.

Because it's a lot about patterns and anti-patterns.

And I'm always debating.

We had the debate with Mark some time ago about what is the pattern?

What's an anti-pattern?

Yes.

And this debate was interesting in a sense that basically we established that there is no such thing as anti-pattern.

It's just a pattern that was used in the wrong context.

Well, that's powerful.

I'd never thought of that, but I like that.

So I have found this for myself, yeah.

Yeah, we basically discussed this problem because I was trying to establish what is the definition of an anti-pattern and I couldn't find the proper definition of said anti-pattern in the literature anywhere.

It was very difficult.

There were some attempts, but they were not definitive enough for me to work.

Oh, I seem to have connection problems.

Yeah.

You did freeze up for a moment, but you're still there.

I'm still here.

I'm seeing that my browser is also crashing.

The screen behind me just crashed also a little bit with connection loss.

Well, that's what you get.

So in that sense, we were looking at patterns and anti-patterns, and there is no such thing as an anti-pattern.

If you call something an anti-pattern, first of all, you probably don't understand it well enough and you probably used it in the wrong context.

So you basically did some sort of a cognitive bias, for example, like jumping on the bandwagon.

And this is just it.

And there are certain patterns that are very much usable in a very specific niche scenario, in a very specific context.

And outside that context, they will not be usable at all, and they will be more damaging than helpful.

And understanding that context and building that context for yourself, so building that knowledge is crucial.

So this brings up a really important point, and that is that we need to stay open-minded.

So I heard that described as maintaining curiosity.

So I can be very, you know, I could say, no, this is the way we're going to do it.

And as a boss, I often used to do that.

But somewhere in the 90s, we had gotten, probably in the 80s, we'd gotten in the business that I owned, that we would say, here's the way we are currently doing it.

You will probably come upon a better idea.

Please share that with us and we'll experiment with it.

So where in my earlier years, I would say, look, this is how we do things.

I'd learned, you know, in my 30s, I suppose, that other people have better ideas than me.

I got to take advantage of that.

And instead of, you know, insisting this way is working for us, taking the attitude that there is no best practise, because there are always better practises.

That's related to this.

It's not exactly the same thing, but that's related.

And then to flip it a little bit to the problem space, when I was a bit more junior in my role as an architect, I had answers for everything.

So I basically was in the Dunning-Kruger effect peak of stupidity at times.

Sure, sure.

I'm sure I had that too.

Everybody goes through the peaks of stupidity.

And it's a shameful process, especially if you go to the valley of despair and start actually understanding the things that went wrong.

So probably in different areas of life and my expertise, I had that several times over different areas that I worked on.

But basically what that humbling experience of being on the peak of stupidity and falling into the valley of despair teaches is that you need to dive into the problem space.

You cannot reside in the solution space.

So, oh, I see a symptom.

I'm going to solution the hell out of it and go my way.

No, it doesn't work that way.

That is really the point of this whole session.

Yeah.

So the point is, which is also taught through domain-driven design or very much learning domain-driven design at this point very actively, is to remain in the problem space and analyse the problem space, acquire knowledge about the problem space.

And then you're able to approximate what the problem is that you're actually solutioning for.

And that's why you can then deliver a solution to the problem, not to the symptoms of said problem.

So this...

That's difficult.

Go ahead.

Go ahead.

Yeah.

This to me is critical.

Yeah.

And we will never leave that.

That's why, you know, Alan Kelly used to talk about, we shouldn't be doing projects.

We're working on products.

When we think that we're on a project, we're envisioning an end.

And he made the argument that the end comes when nobody wants to use your software anymore.

And that will come sooner if you think you've finished your project.

You have to...

It has to continuously be improving and answering the need of the users.

They will discover what they really want to use.

That's like the idea of measuring how good a platform is.

If they start doing things with it you never intended, you probably have a good platform.

Yeah.

Because...

And if they don't, you know, then maybe it's too constraining.

Whether that's the truth.

I'm not sharing any of these things as truths.

They're just good things to think about.

Yeah, that's true.

And then touching on the different types of problems.

Okay.

Knowledge problems, one thing.

You need to learn the problem space.

You need to learn the problem domain.

But you said collaboration.

And it like...

Especially that we talked a lot about queuing today.

It already went into my brain.

EDA, EDA, EDA.

Even Driven Architecture.

And if I look at it from the perspective of communication, time to collaboration as well.

If I'm using queues, yeah, that's always going to be a bit of a problem bottleneck.

This serves as a load balancer at times in system design.

Perfect.

But if I'm using a topic, I'm actually doing a broadcast, right?

So I'm actually telling everybody, hey, this happened.

This is something I'm doing.

This is something I'm working on.

This is something...

So it's actually creating that visibility of things that are happening.

And so this also works on that level of architecture, software design, ecosystem architecture, or system architecture.

If we're shifting our communication patterns towards real time, we can really solve a lot of problems.

But because that creates that collaborative aspect.

Yes.

It brings other problems, but that's a completely different story.

There was a kind of scale that was called the richness of...

I think it was the richness of communication by Alistair Coburn.

And this scale showed...

I'm going to see if I can find it here.

The scale showed the value of collaborating.

So if we have a richer communication, we have a higher level of effectiveness.

And I liked what I learned from that.

And I believe that...

Was that by chance effectiveness of communication?

It could be effectiveness of communication.

I'm going to see if I can find the diagram.

I've got some of it.

So the effectiveness versus the richness of communication.

So I think it was on the richness of communication.

And so this was...

I can find a link or something.

But that's it there.

So what did he call this?

Yeah.

This is somebody else.

But that's Alistair's.

This is a remade by somebody else.

That's based on Alistair's thing.

So he's kind of showing the first level there, the lower level is written documents, recordings, diagrams, and so on, which are all very good.

But the next batch is bringing us all the way up to face-to-face communication or at a whiteboard.

So I think either Alistair or a few others at that time used to say the power of two developers standing at a whiteboard.

Well, I would take this a bit further now.

I believe, first of all, that this is much more of an exponential kind of a chart.

It can be shown as an exponential...

You know, where at the low end, it doesn't just move up kind of...

This is sort of linear the way it's shown.

It moves up like when we get past where we're cooperating with each other, then it really starts going up.

Before that, we're coordinating.

We coexist.

Then we have communication.

We have coordination.

Those are all ways of working together, but they're very low richness.

When we start working into cooperation, that means we're helping each other.

We can go up further than that into true collaboration and eventually at a space I would call co-creation.

And I believe the book Dialogue and the Art of Thinking Together also addresses these things.

So this is...

It's not unique to me, but it's a gathering of all the things I've learned over time.

The idea that if we are sitting together, then we are in a space where all of these things come together.

So it means in some ways our work is easier.

We don't feel as pressured.

So there is this psychological thing that happens to us.

If we're not under pressure and feeling really busy, we feel like we're not being effective.

We're not being productive.

This is something that happens to humans.

It's an actual thing.

And so when we're sitting and really working well with each other, we may not be contributing very much individually, but it's the old saying, I think from maybe Russell Acuff, where he said that the...

And it may have been somebody else who said that the value of a system is not the sum of its parts.

It's the product of the interactions.

So whoever said that, and it could have been Russell Acuff.

You can easily look that up.

It's not...

And I'm sure that that probably came in Roman times or Greek days.

Somebody thought that up.

We just massage it over time.

But it sounds like the kind of thing that Russell Acuff might've said.

But this ties very much into...

I never know the Alistair Cockburn's richness of communication, but this very much ties into my experiences as a trainer.

And because I learned better when I'm designing trainings and teaching people.

Yes.

Because that classroom interaction, where we are in one room and we start to dialogue.

And most of my trainings are designed in a way that, of course, I convey some knowledge through slides, presentation.

But a lot of elements there are interactive elements where we spark into discussion and ask...

I ask questions and I want to hear different opinions, not even answers to those questions, because there are no correct answers to the set of questions.

Just any answers, really.

Yes.

And this brings a lot more learning to the table than anything else.

So that richness is through that dialogue, through that shared work, shared understanding, shared collaboration there.

And for me, that became the default way of learning.

And the default way of learning in the sense that this is why we're having this stream as well, because this is my opportunity to learn through conversation.

And this is why I also last year started just reaching out to people over LinkedIn and asking, hey, do you want to do an architectural sparring and just chat about architecture?

And the majority of people just said, yeah, sure.

Let's do that.

That's great.

And these were so many great conversations over architecture and just looking at different viewpoints on architecture that I could have never stumbled into by just doing the work.

So the strength of this, I think, is probably based in how humans operate.

We would not exist if this wasn't something we were already good at.

So that means our ancestors, if evolution is a thing, which I kind of guess it is, our ancestors had to get good at this so that we could exist today.

There was a point in time, probably, where our long-ago ancestors, pre-human things, didn't need a group to survive.

Maybe they were just like amoeba-sized things that could split up in cells and they could just keep going.

And they never helped each other do anything.

At some point, we started getting four legs and they started using some of our legs to hang into trees.

So that's why they think, some anthropologists, that our hands are the way they are because we lived in trees and we need to be able to grab onto things.

And there are some animals that...

So all I'm saying is, eventually, we got to the point where children are born needing care for an extended period of time.

They need somebody to take care of them until they're old enough to take care of themselves.

Usually happens around age 30.

But anyways, or something like that.

Anyways, to get to the point here is that to be able to do this working well together stuff, and this was stuff we needed to learn how to do.

I'm pretty sure we have common ancestors, that their main thing to communicate to another group of people was we're pretty good at defending ourselves, so don't even try to fight us.

Stuff like that, right?

So that once we could communicate that, then we could say, okay, well, let's get together.

Maybe we can trade some stuff.

Because there's plenty of evidence that shows that there were people living deep in the interior of countries, of continents, that had artefacts you could only get at the ocean.

Or people at the ocean who only got stuff that you could get from this one region.

They didn't walk to that region and get that stuff and bring it back.

We learned how to interact with each other.

And although I don't think we've ever become perfect at it, we're actually right now, I think as a whole across the world, we're learning how to be less good at that in a lot of ways.

And so this is a de-evolution maybe.

But to some degree, we have to learn how to work well with others.

And that's my argument most of the time is mob programming or software teaming isn't about necessarily eliminating solo work.

It's just about getting better at working collaboratively.

So we have that choice.

And something happened in our industry.

This is what I noticed early on when I started working for a living is that we thought this work had to be done alone.

And we would only have meetings and documents to communicate.

And I think that learning to be more effective here includes learning how to work to actually do the work together, rather just talk about the work.

I have found this for myself.

If I'm going to do something, like I was putting on a conference for a few years, if we did the work rather than having a team talk about what needs to get done, and then people say, well, I'll do that and I'll do that.

We just sat and did the work together.

We got a lot more done.

It was better done.

It was better thought through.

It's in the doing of the work that we actually discover what we need to do.

And if we do that well, as a group, we speed through the work.

We no longer have the queuing and other problems that happen when we divide the work up.

We've naturally started dividing work.

And I think there's a lot of reasons.

Maybe we could do another session sometime.

Why is it that we think working this way?

I go into companies and they have a testing department and a coding department and a deployment department and a database department, or at least managers in those areas.

Why did we let that happen?

Well, it makes it harder for us to work together in an environment where I have to put in a request to get someone else to work on something.

And then we're going to decide what it is in a meeting instead of decide it together working on the thing.

These are ways to make things harder.

Back to Drucker's quote.

I'm afraid we're getting to where I need to go.

So I have another meeting.

I have another meeting coming up.

All right, Woody.

Thank you for the wonderful conversation.

It's been splendid.

I'll probably see you tomorrow then on the other session in that sense.

Because I might have enough time to join the dialogue in Art of Thinking.

Yes.

And if anybody is still with us, I encourage you to also join that because these are always interesting workshops, interesting exploratory topics to just go through and figure out maybe there's something of value.

And exploring is always of value, whether or not the outcome is actually useful.

But just the act of exploration journey is always extremely useful.

So I implore everybody to hop onto that tomorrow and see what comes out of it.

And before we go away, in two weeks time, because next week we don't have a live session, but in two weeks time, we're actually talking about neurotypicality in IT.

And joining me for that session will be Joanna Gruszczyńska, a job and ADHD coach.

And Joanna works with a lot of people from IT.

As she told me, 9 out of 10 of her clients are actually IT people.

So that might be quite an interesting conversation to see how the way our brain works actually influences the way we work.

So tying it in also to our conversation here of symptoms and problems, this might be an exploration of a very specific type of a problem.

I love it.

That we'll be having.

So that said, Woody, thank you again for joining us today.

Thank you.

And everybody have a lovely, whatever that is, morning, afternoon, evening, or night.

That's right.