Loosely Coupled Special Edition: Architects Navigating the Human Condition

Hello, everyone, and welcome to loosely coupled by bridging the gap.

My name is Mark Richards and I'll be your host today.

And in this episode, Mark, who gave you admin access?

Hold on.

What a hell.

What?

What are you doing here?

Wait, wait, where are you?

That's not your usual background.

Hold on.

What?

What's going on here?

Hold on a minute.

Travelling.

I'm going to fall down the stairs.

Give me a second.

What?

Hey, what are you doing here?

What am I doing here?

Yeah, what are you doing here?

Sorry, hold on.

Hello, wait.

Hey.

Hello.

Is this your house?

Yes.

What a surprise seeing you here.

Yeah, well, that happens.

So, yes.

Hello.

I think that one of the...

Yeah, this device is still...

Oh, here I was going to start your whole podcast.

I mean, start your own podcast.

You know what I just realised?

We forgot beverages.

Let me go back to the second one.

Okay.

Before we begin, beverage.

Yes, while you're doing that, that might have been a little bit of a surprise for some of you that all of a sudden said, oh, you're in the same place.

And in fact, we are.

So, I'm travelling here in Netherlands, and so we figured we'd stage a little thing like that for all of you.

Just for the fun of it.

Just for the fun of it.

Yeah, so today we're actually going to talk about the human elements, the human condition, that human condition, and I love this kind of topic, and I think those are the better with the beverage.

No alcohol for those.

We're not going to drink alcohol on air.

It's zero percent.

It is zero percent.

It's not a crystal.

All right.

Perfect.

Well, here's to the human condition.

All right.

Where to even begin?

I kind of...

You know what would be a good place to begin is why we think this whole topic is actually so important.

We continue to talk about the human elements of IT and human elements of being an architect and even a technologist.

It's kind of interesting because I just realised myself, Carol, I talk about this topic a lot and I rarely say why it's so important.

That's probably a good place to start.

Given that why is one of the roles in software architecture?

The second one, that is absolutely correct.

That's very relevant for us to actually dive into the why.

You know what?

I'll actually start because I have a really good and wide reason here.

Everybody listening, whether they're live or watching the recording, we might consider they're really good technologists.

As a matter of fact, I would say that they're probably experts in what they do, mainly because they're listening to your podcast.

That's possible.

We all start gaining a level of expertise in our field, our speciality industry.

You may be an expert at a certain approach, technology, but so are 100,000 of your other colleagues.

It's kind of interesting that how do you then differentiate yourself in this industry?

We've got to be good technically.

Otherwise, we just won't make it in this industry.

That is one of the ways I can think of to differentiate yourself.

It's having those really sharp, soft skills, the people skills.

That, for me at least, especially what I'm doing here, is one of the big differentiators.

I think that's one reason why.

One reason why.

We seem to have small audio technical difficulties.

Maybe my microphone isn't as great as I find it today.

Let me see if I...

Ah!

So we were on over here.

Let me just check because the microphone is actually captured from a different laptop.

Just let me see if that's the right microphone in there.

Oh, of course it's not.

That's why you don't hear us that well.

Right.

Microphone.

There we go.

Excellent.

Please, dear YouTube could be live.

Please confirm that you hear us now better because it was I'm very sorry it was gathering from the camera microphone.

So this should be a lot better.

It should be a lot better.

Hopefully it's better.

Just to put this in context, we really have technical difficulties setting this up because I've never done this kind of thing ever.

I don't have the proper equipment to do so.

So we're actually streaming on a webcam that is hooked up to a laptop on a USB.

This microphone is hooked up to a laptop which is basically two metres away.

We just tried to make the laptop go on the Ethernet cable and the Ethernet cable didn't want to connect to the router just like two minutes before the stream.

I'm stressed.

Well, I'll tell you what, if those of you that are actually watching this recording or live, if you saw the setup here that we have, we call it, at least in the States, we call it a MacGyver.

Oh yeah.

You're not MacGyver?

Of course I know MacGyver.

I watched MacGyver as a kid.

That was one of my favourite shows as well as Stargate.

I'm a fan of Stargate.

But for people wondering, I'm just going to take a photo of the setup here with Mark.

Hopefully I'll catch Mark in there we go.

So for memory reference, I'll just put it in linked in comment.

There you go.

That's insightful.

Yes, our MacGyver setup.

Our MacGyver setup.

We definitely MacGyver the hell out of this to just make it happen live here.

Now, going back to the differentiator, so the why.

So just to repeat so it's a little clearer on the new mic now that we have is just because we're all experts in something in our field.

Whether you're an architect developer or any sort of technologist.

And this this whole human condition piece, the SOC skills, is what I see as one of the big differentiators to be able to differentiate yourself from all of your colleagues who are just probably as good as you technology-wise.

So that is one of the differentiators I see.

Differentiators.

Okay, I would have a different why.

Ah, okay.

Coming from a perspective of a person who's neuroatypical and I do have autistic traits combined with ADHD, my why for these skills is because without them my life is just horrendously hard as an expert because I come across as too stubborn, too direct, or any other strong descriptor.

just understanding that sometimes I do come across like that.

First of all, that takes self-awareness, which is something everybody should have.

It doesn't happen always.

It's a trained skill.

Also, with having that self-awareness, how to work around those situations that are problematic, it's a skill in itself.

To have those skillset needed to navigate those.

That's why we are the architects navigating the human condition in that sense because we talked about it earlier in the day, the talk from Andrew Harmel Law from BPD Europe 2025.

Andrew named his talk Variability, the second hardest problem in software design or software architecture.

He delivered a splendid talk.

It was an absolutely amazing quality of the talk.

But then the QA came and the first question that went from the audience was Andrew, you told us about the second hardest problem of software architecture.

What's the first one?

You didn't say anything about the first hardest problem.

I was holding the mic and I stood for a second on the stage and was like, oh, yeah, you're right.

You are.

All of you.

All of you are the problem.

As a human, it's not a problem in the software architecture.

So, having those soft skills and navigating the human condition is actually solving the biggest problem in software architecture.

And this is also, why is this a problem in software architecture?

Because software, at least in my opinion, software architecture and just designing and building software without a purpose, in our case, most of the times a business purpose, because obviously some people build it for fun or for home improvement, whatever.

But that's also a purpose in that sense.

So, building software without a purpose basically means that it's just art for the art of it.

It doesn't an art form, and in all the context that we are architects, developers, niche specialists, whatever that may be, we're always building the software with a purpose of facilitating some sort of a business.

Yeah, that's a good point.

And without the skill to navigate the complexities of human interactions, all business is basically human interactions and we're basically yeah, yeah.

Well, you know what?

You remind me with your why question of another one, but it's another quote.

And it's from Gerald Weinberg.

And he quoted way a long time ago.

I think it was late 60s or late 60s I believe.

He said, quote, no matter what the problem is, it's a people problem.

And so that's another good why piece because he was right.

He was right.

And so that would I would add as a third kind of why is this topic so important and critical?

We might not recognise this as a people problem.

We often mistake that as a technical problem and try to probe technology in the face of the problem or the challenge or however from a consulting perspective we want to name it.

But it's not going to solve the problem.

It may patch put a bandaid on a gaping wound and solve things temporarily.

that's it.

Nothing else.

So that's the why I think.

That's the very crucial thing to begin with is the why why do we even want to navigate because I remember my juniors the difference between our experiences is quite a long one because we have 42 years of experience in IT.

Indeed.

That's nice.

And 31 as an architect.

Well actually about 10 of those.

So 32 years as an architect.

32.

Wow, it's been a long time.

You're basically a dinosaur.

It ruined our first day of it.

Given that my time span in IT is nearly 15 years.

Whereas about 10 of those as an architect and also with a specific niche feud from the beginning of it.

So that's again a different perspective.

But when I was a junior developer the thing I heard very very often from my colleagues at least some of them is I didn't go into IT to work with people.

So they were still in this kind of notion of an IT specialist, a developer, help the specialist sitting in the basement without windows just closed off from the world and doing their thing.

Now that sounds like Nirvana sometimes to me.

Before I learn to gain some appreciation for the new world of IT and the human side of what we do that was just a perfect environment.

We're problem solvers.

Let's put it that way.

We love as IT professionals to solve problems and one of those ways we deal with it is just to have people go away walk yourself up in a room and just focus on the problem and solve it.

And so I really agree with you.

I think a lot of times we say but that's why I went into IT because I don't like dealing with people.

But you love puzzles, you love problem solving, you love figuring out things.

Exactly.

So yeah, that's quite an interesting observation.

But you know what I find very amazing.

We think about all the hard stuff that we do.

I find it amazing that what we're talking about here, this human condition, this human side commonly is referred to as people skills or commonly soft skills as opposed to the hardest.

But it amazes me that we call them soft skills but at least in my experience and those of people I've talked to they're the hardest skills to acquire.

And so we've got this play on words where we've got soft skills that are hard to acquire.

I always get a kick out of that.

That's very true because it's a huge gaping gap in education in general because if you look at curriculums at school, if you look at curriculums at universities, the focus is mostly on acquiring technical knowledge.

Or domain specific knowledge if we look at other sciences or humanities or whatever.

And we're not taught, we don't even have the opportunity to practise and there's my cat coming in, he escaped again.

I've tried to close the door and keep him upstairs but he persists on going here.

So let's give him a room on my lap and let's leave him there.

So there's, we rarely even get to work on group projects in university.

So we rarely have the opportunity to exercise our collaboration skills at all.

We don't have to navigate those if only we navigate them in purely egoistic manner as in, oh, are you going to get notes for me?

Or some people would go like, oh, maybe do my homework.

This kind of thing.

This is completely different because these are manipulative and egotistic.

Meaning that this is extremely difficult to practise in that sense because we're not wired by these environments to be collaborative.

Even if there are collaborative projects, how many times do you hear the story that there was a group of four and one person did all the work?

Yeah, that does well, and interesting when we talk about those groups, I'm just going in my mind to a lot of the workshops that I teach in conferences and masterclasses and we typically break up into groups to do those exercises and this stands over several days, but that's why I like to have those groups in an odd number.

So that

if you've got two people

saying, I think we should do

solution A, and two people saying, I think we

should do solution B,

that's

a struggle, especially with timed

exercises, and so having

that odd person is sometimes a good

tiebreaker to keep things moving

along, but I will have to

say,

I think we're

might not be fair to

everyone in the

industry, because certainly

I do think that I can

cite hundreds of

examples of

professionals I've worked with

that have little or

no people skills.

None of the human side of IT or architecture or development.

And boy, it's a miserable, miserable experience.

But I will say, one of the things

that impresses me a lot

is when I'm teaching a masterclass

or whether it be a public or private

class, and I break people up into

groups to do the exercise,

it makes me so

happy, because

I'm kind of walking around the room

as kind of the quote product owner in case

people have questions, but

the beauty of it is, everyone

is so involved and

so collaborative in forming

these solutions, and it just

makes me smile every single

time I do this, because I see

people do actually know how to

collaborate, and a lot

of people I work with, like I said, I could cite

hundreds of examples of

I don't want to work with that person

again, but I could equally

cite hundreds of examples

where there have been

architects, developers,

any kind of IT professional, any

technologist I would work with

again in a heartbeat.

It's not because they're really good at the tech.

That's not the reason why.

It's because they have embraced and understand that human side.

But I'm going to call you on your classes part there.

Isn't that a little bit biassed in that sense, because if you think about people upskilling in the industry, it happens two ways.

One, they want to upskill and they find the right training, or they're forced to upskill and they just go to the training because they have to.

I don't think the second group lands at your trainings, because that would have to require a component to actually be able to be aware that they might benefit from that training, which means that somebody would have to have more knowledge than they usually have about making decisions about these kind of trainings.

100% agree.

I would agree that that's probably a biassed statistic.

To all fairness.

But I agree with you that there are, of course, there are people I definitely, I have a list of people in my head that I would definitely not want to work ever again.

I'm very certain I'm on such a list for some people.

Just to be fair, I'm not perfect, never will be, especially with my ADHD and autistic traits, I can be very annoying, stubborn, and not cooperative for certain types of people.

But yeah, it's a lottery at times.

Basically, I remember this YouTube clip called Everyone's an Arsehole and you're basically looking, this one is an arsehole, this one and this one and this one.

But do you know who's the most special arsehole of all of them?

You are!

Yes, of course, because we're in certain contexts, we are.

And you know what?

That brings up a really good point.

Kind of ties back to my one that says soft skills are the hardest skills to learn.

But also, they're the hardest skills sometimes to practise as well.

Let's talk about reality because I at work have had what I call, and also my team calls, oh boy, he's having a mark moment, is what they call it.

And it's embarrassing to say, but there will be times, a mark moment, where all of us, even me at work, you lose your cool over something.

You get stressed or things aren't working well and just one thing happens and so I was just thinking of those kind of moments where, you know, we try to practise all these soft skills.

We try to embrace the human side.

But sometimes it's not easy to do so.

And you know what?

The point is this.

Even though I've had my share of mark moments, I'm certainly not proud of them.

I get a little embarrassed afterwards and there's sometimes some repair work to do.

But I don't beat myself up over it.

I kind of use them as learning experiences to say, alright, so what triggered me to have that blow up just now?

And so I'll try to reflect and learn from those mistakes.

And you know, I think this is one key point I want to say about this whole topic.

And that is the only way, at least I have learned those soft skills, those people skills, the human side, is to practise it.

Is to actually do it.

You know, there's a lot of good books.

There's great podcasts.

One I've heard from loosely coupled about this as well.

The one we're on.

Which one you will refer to?

I got you on that one.

But you know, you can learn some techniques.

You just gotta go out and try it.

And to make mistakes and just learn from them as opposed to beat yourself up.

As human beings, I think it's part of the human condition to learn from mistakes.

There's pretty much no way around that in that sense.

Right.

Exactly.

Yeah.

Oh, there's just a question here.

That's a very nice one.

If you have a team of people who all want to develop their skills and be the best, how do you ensure that they deliver?

And that's a difficult one because this is, again, the context is king.

If they want to be the best, the best at what?

Right.

That's another thing.

They want to be technically the best or the best specialist or the best consultant.

And this is a moment of looking at having a bit of a recognition.

What skill sets you want to train versus what skill sets you actually need to put the job you're doing.

Well, you know what?

I've got a beautiful answer to this because you're right.

And you know what?

Regardless of that context, there was a I'm from the state since Boston.

And Boston's very close to New York City.

And there's this very famous joke.

So this guy's running all around and running around and he stops somebody on the street and says, please, please help me.

How do you get a big rush?

And the guy looks at him off from the street, looks him square in the eye, says, practise, my dear sir.

Practise.

And it's just, it was great because he's obviously asking directions.

Probably showing up at some concert or something or a show.

But just the, that joke I love because it helps answer this question that was posed here is, how do you ensure they deliver regards to the skill?

It's practise.

It's practise.

I mean, how do you become the best developer in the world?

It's not from reading books.

That's architect.

Yeah, exactly.

It's practise.

It's making mistakes and learning from them.

Yeah.

So I think that's how to ensure delivery of any kind of skills that we try to become an expert in.

Soft skills or technical skills.

We have to practise those.

Yeah, but then if everybody wants to be the best and they'll be looking at the best of what they think the best is.

So I think the thing that comes before that would be to have an honest conversation on what it is to be the best in their opinion and what it is the best what actually would be beneficial for the job they're doing.

Interesting.

Yeah.

Yeah.

That's actually a really good point because when we say be the best at something, it's very subjective.

It is.

Yeah.

Oh, yeah.

It will always be subjective because who's going to tell us that we're the best or we're going to tell ourselves that's going to be extremely subjective.

Yeah.

Somebody tells us we win a competition that's still going to be subjective because we're going to be judged by some judges on the competition.

So that's, again, subjective.

Do we want to be the best?

Okay.

Fantastic.

The best of what?

even more so the best.

Why?

Because I think that's a key one there.

Yeah.

Yeah.

I agree.

There's even more.

I like that.

Gaurav coming in with questions.

Gaurav we know from from Friday Foundation forums.

Yeah.

Well now it's the software architecture book club podcast.

Book club podcast.

Yeah.

That's awesome.

We're gathering all these from all over now.

It seems so neat.

What a great question here.

I'll counter that with how do you motivate people to improve when they don't feel the need to back to that point of open having people who are already of the right mindset in your workshops.

Those are likely the ones who won't be there.

Very true.

That's very very true.

Wow.

That's a great question.

Oh wow.

You know I actually have a situational kind of anecdote for that.

Some time ago I landed with a company.

I would say the management was poor in terms of choosing the right people for the job and people were highly unmotivated.

Basically because I'm an integrator I work with all sorts of integration platforms and teams that are supposed to do interoperability in the company.

The setup of that team was a shock to me because basically these were former DBAs and database administrators.

So from any perspective of an integrator that's a completely opposite mindset to what was supposed to be in that team.

Completely opposite.

Persist everything where I say persist nothing or as little as possible because that's the integration part.

We don't have to keep data.

We don't want to keep data because we don't want to deal with anything safe.

And of course they delivered something that wasn't an integration platform.

They delivered an MDM solution with input and output pipelines done over Azure functions.

Okay.

It worked to distribute the data.

There was data movement but that wasn't application integration because these weren't integration services per se.

the problem is if they're already unmotivated, they're doing something they don't want to do, they don't like, we're basically treading on the problem of psychological safety.

And I talked about this with Fran Mendes in the first edition of Loosely Couple that we did, what was that June?

We talked about adoption of even driven architectures within organisations for any purposes.

So moving from the point to point to actual even driven, which is a very personal organisation, that's a huge step in mindset of these, because that's difficult to start thinking in advance, all of the sudden when you request to buy a transaction all the time.

Boy, do I have stories about that.

Let's not get into that because that's not the topic today because we could just go down the rabbit hole.

After the podcast after we could talk about those stories, but basically if those people are already unmotivated and they're struggling at what they do they're not appreciated for what they do even though they're trying.

They're trying their best.

And they don't receive proper training for the job.

Any context of training or anything.

And then they're also blamed for problems that they're not of their own making because they didn't make those problems.

They were assigned to this completely at a managerial whim instead of thinking about the skill sets that are needed for this.

Now we're at a problem of psychological safety.

If we look at psychological safety and trying to propose any change anybody who's in a state of fight or flight will not adopt.

They will fight it.

They will want to keep the status quo.

Because everything then is treated as danger.

And it's very hard to get from that point to a point of healthy relationship within team, within the organisation to actually be able to grow.

Because if you're in a sense of danger you're not going to be growing.

You're switching to survival mode.

And your brain is in survival mode.

You might not even realise that because you're still working.

You're still contributing.

The challenges pile up.

The production problems pile up.

Incidents pile up.

But you're doing your best.

I'm working and they're praying me.

So it is an illusion of psychological safety.

But in sense those people are not in a position of psychological safety.

So they will not go into being motivated to upskill themselves because they're just trying to survive.

So that team actually at a certain point had to deal with more operational tasks than any new development.

So continuously the percentage of operational tasks grew over so much that the throughput for that team and new features was 10% maybe.

Which was parentheses so.

So they became a bottleneck of the organisation and that's just the end of the team basically.

Well so I kind of want to pick this question apart because there's something about the question that is somehow in the back of my mind really bothering me thinking about my prior experiences.

And I'm also thinking about techniques that I've used to try to motivate people.

But the reason I want to kind of pick this apart and dive a little deeper, the thing I think that's bothering me is in the industry we have now where it's well at least in my circles it's not easy to find a job.

True.

And you know there are I definitely think fewer openings than there are people looking for work.

Also you kind of come out as a new grad and you know we can think of all these examples.

So it boggles my mind to think that there would actually be people on a team that just didn't care.

I mean I know that it's really hard to fire people.

That I completely accept.

But that you would have to work on saying how do I motivate this person?

It kind of saddens me in a way.

You know what I mean?

It's that and this is what I mean about that differentiator.

If I'm building a team, I've got to have great technologists.

To people that have experience in the technology.

But Carol that's only about 10% of what I look for when I'm building a team.

Or when I'm doing interviewing.

I look for situations of how would you react to this scenario?

Create conflict.

Or a conflict resolution.

You've got three people who all disagree.

What would you do?

To help that dynamics.

I like to see by talking to the person I'll just randomly fire off a question.

I'm listening to the answer but what I'm more listening to is how do you present yourself?

Are you exhibiting any of this kind of human side?

And that to me is a much more valuable person on the team.

At least for me in my opinion.

Yeah, I think there were a few examples on the web if you find it.

For example from Simon Sinek explaining how Navy Seals work.

In terms of how they recruit Navy Seals they avoid low trust high performers.

They don't really measure only performance indicators.

They measure trust indicators as well.

And this what you're saying about the part of the human condition part of human soft skills is that the capability to build trust.

You don't have to be a very high performer while you can build trust because performance is something you can teach.

Building trust is a lot harder to develop.

It's a lot harder to develop and it's a lot easier to wreck it.

Exactly.

That is so true.

This is the description I find a while.

I'm sorry.

Absolutely.

In corporate environment it's even crazier at that because I've seen people in corporate environments 20 years in the same company.

Oh yeah.

From my perspective that's crazy.

That's like why?

Those people have no idea what the reality of the jump market is at all.

They have no idea what the value of their skills is.

It depends how diverse you are within that company.

I would concur in the rare circumstance that you've been in a company 20 years and you're working on the exact same system maintaining that exact same platform day after day.

Agreed.

I've also seen a lot of people move around and stretch their comfort zones.

This is what I tend to encourage actually is we all get and to your point why I think this happens we don't get very comfortable with the technology that we know and love.

I think we get comfortable with the people that we work with.

That's our comfort zone.

We like that.

To stretch that comfort zone I think is one of those techniques to get away from that 90% of corporate debt.

You're absolutely right because I've seen people in a singular company that hopped between different jobs and different scopes between the years and the company.

That was fine and they actually grew but then I also seen people who stayed around pretty much the same area and only the Peter principle rise to the level of their incompetence.

Constantly within the same silo of the skill set that they were doing.

Never experienced anything else.

They went in that particular technology, into that particular business area and they just remained there for years.

And I would say that's a different definition of crazy.

The definition of crazy is repetition, expecting different results.

That's pretty much very close next to it.

That would be a segue from Stone Crow from that.

these you will not be able to motivate and upskill also.

That will be problematic.

I agree.

You know what might be fun?

So we're both sitting on this podcast talking about the human side and we've had lots of experiences with that.

You know what would be fun is for each of us to talk about when was our epiphany and in other words, when did we realise at what point did we you and I embrace the human side of things that really started to say you know, Gerald Weinberg was right.

It is a people problem and I need to work with people.

I think that might be interesting.

You know, I think the audience might be kind of interested to hear some experiences.

All right.

You want me to go first?

Yeah, sure.

Your idea, go first.

My epiphany about the importance of saw skills, of people skills and what really just completely changed my direction and my career was when I first became a software architect.

Now, I had been working for about 10 to 12 years as a developer and then tech lead and stuff and I was on a very, very, very complex migration and I was the architect on it and I had a whole team of people and I was so focused on the technology.

I was so focused on making sure this project came in right on time, below budget, hopefully, that I was super abrasive to everybody on my team.

I would have junior developers come up to me asking questions and I would answer some of them but then I would have senior developers coming up to me and I'd say you should know that.

Stop wasting my time.

Can you believe it?

I mean...

The person that I know you from the last few years, no, I wouldn't believe it but I find it quite feasible.

And this is what turned me around.

Many of the people on that project ended up leaving not only the project but also the company because of me.

Because of my actions and being so abrasive to people.

That was my epiphany.

That was my wake up call.

Because what I'd say was that project successful?

Well, from the budget and timeframe yeah, we did the conversion, everything 100%.

But I would not consider that, from my perspective, personally, a very successful effort because of the people part.

That's what opened up my mind and my eyes to say, you know, I got to do better.

I can't just be the best technologist.

I have to be better at this.

That was my turning point.

As a matter of fact, it was my turning point through epiphany in terms of understanding the importance of the soft skills.

But it was also my turning point in my career.

Because of that, it made that much of a difference.

Yeah, that was really my inflexion point.

Okay.

So that was, you know, it's so funny because when I just reflected on, hey, we should tell each other our anecdotes about people skills and when we learned them and the importance, it didn't dawn on me until I just gave that anecdote that yeah, these are probably not things you like to talk about.

These are our most embarrassing moments.

Why would you talk about that?

But, you know, I don't like to talk about it.

But, you know, it meant that much to me to turn those things around, turn those skills around.

Well, this is a bit more complex for me because this is a staged thing in several stages for me if I could look back at what I did as a specialist or just as a person.

Okay.

I'm stubborn.

I mean, my ADHD and my autistic traits do not help me to be a pleasant person at times.

Especially if I'm overstimulated, tired, hungry.

You don't want to be near me when I'm in all of these, right?

Okay, I'll give you a hungry because I get the same way.

We'll call it hangry, yes.

Hangry.

Yeah.

There are stages to that.

First kind of stage pushing me towards being constantly better.

No, actually there was literally no one.

So the actual

first stage that was pushing me towards

getting my

me as

a person better and

more approachable

whatever that may be

was when I was actually

suffering from

severe anxiety

and panic attacks

that forced me into therapy

because I basically had

a psychosomatic paralysis

which meant that if I had

a panic attack, I was

basically

for about two hours and I could

only blink, for example

for most of the part.

So I was like, if I was with somebody then I was communicating like, one blink for yes, two blinks for no.

That's it.

I had meds for that, anti-anxiety meds, I could have been better but basically then going to therapy because meds do not resolve these things, therapy does.

Going to therapy already turned me into the right direction to be more open to other perspectives, other other things.

So that's one turning point.

Second turning point, I think a very crucial one was meeting my wife.

I'm still joking to this day when we're talking about topics of mental health or understanding people or soft skills in general, is that my emotional intelligence is sitting three metres that way in a different room and that's my emotional intelligence and yeah, sometimes I'm just not aware of what the problems are.

By the way, if you see us looking down here, we have a monitor down here just to monitor the questions.

Marco also has a laptop in but we're zooming down there to see what your guys were writing on LinkedIn and YouTube.

So that's the second turning point and we touched about that today, the conversations with my wife as well.

The relationships there were sometimes really tense between different family members and me and whatnot.

So that was it was just first difficult but that also led to understanding people from a different perspective because my wife as a special needs educator does have a very nice talent to explain things in a different perspective in a different way also in a language that kind of tracks better in a different language to adjust the language to my specific language so I can understand.

So that's the second turning

point

and then

the next

point kind of correlates

with us meeting, correlates

in time

because it's actually observing

how if you

go to the right place which is a toxic environment

how

it's all about

working with people to solve

problems rather than

solve them by

technology because

the environment I was at

they

threw technology at problems

and blamed people

for that technology not solving the problems

but they didn't

talk about the problems.

They didn't acknowledge that the problems are actually organisational problems or human problems not technical problems because these weren't technical problems at all.

There was problems in bad processes bad management poor accountability blaming culture and a lot of quite a few other nasty things.

That correlated

with us meeting because at the time I was

using my time because I couldn't break the

brick wall of

management and people because

I didn't even know how to

break through those politics

not a good

politician myself

I sometimes try to but I

absolutely refrain from

going into politics

so I was

like okay no

I'm done

and that was a turning point where I started looking at this

okay as an architect

and at that time I worked as an enterprise

architect which requires

a lot of God and talking boardroom

presentations instead of actually solving

you know

problems from that engineering perspective

how can

I make it that I

actually am able to

solve problems starting with

the problems of

organisations and humans

instead of

solving the technical problems

because if I cannot

make a change in the impact on an organisation

no amount of

architecture or technology will solve that problem

because it's first about explaining

what the actual problem is, not the problem

that they see which is a symptom

but the problem that

is

Woody

I think he recently started

touching upon the subject and

his own ponderings

that we often approach

problem solving in organisations

symptomatically rather than actually

finding the root cause

I think

I'm going to be chatting with Woody on that topic

somewhere in November

over a loosely coupled as well

we're yet to schedule that

we have a preliminary day

this is one of the

things that happened

symptomatic

and

this is exactly, throwing tech at problems

instead of sitting down and having a conversation

that's the difficult part

and we avoid the difficult part

because we don't feel comfortable

with difficult parts

you're right and a lot of times

we're not comfortable with conflict

I mean

many of us including myself

very uncomfortable with conflict

and I've learned at work

how to address some

conflict situations

but still nevertheless

it does sometimes

make you just very uncomfortable

you know

it's interesting, I want to come back

to, oh here was a

question for you here

from which I mentioned

politics

is the one we were talking about

should be able to deal with the

politics of one organisation as an introvert

how does one motivate business

and especially

operation folks

adopt new technologies or

processes

so

how does one motivate businesses

and especially operation folks

adopting new technologies or

processes and as an introvert

and as an introvert

well you are right, I did say that

it is an expectation

or an architect is expected

to

be able to navigate politics to understand

a political climate of the organisation

rest of recently, reviewing

again the

architectural thinking chapter

but also to

continually analyse

the current environment and

continuously recommend solutions for improvement

so one

technique

especially as an introvert

doing this

I caution myself

whenever I think about

trying to urge or

evangelise or

try to adopt new technologies

new processes

because I stop and say

is this because

I'm excited about it

is this because

I'm doing RDD which is called

resume driven development

which is something that I see a

lot because you wanted on your resume

I want to adopt

lean

lean is missing from my resume

that's why I think we should do lean

from a process standpoint

or I think we should adopt ADR

why?

Because I want

the movement of resume

but

what I do is I first of all

I look

at the why piece

it comes back to that why question

in other words

what benefit

is the business going to gain from this

what business problem

is this solving and what

business value

are we getting from this

there was a project

I had about 12

oh no this goes back maybe even

16 years

ago 15

it was when Scala was all

the craze and I was

fully I loved Scala

but I was on a particular

Java project and

we had this

one person on the project

who just

loved Scala

absolutely loved Scala

it was obsessed with Scala it wasn't me

just to be clear

just to be clear

and every time

we would try to brainstorm on

a solution for a particularly hard

problem

this person would say

I'm tapping out because if we did Scala

it would be easy to solve but

you're still insisting on Java for this

so I don't know but in Scala

this is how we'd solve it and this just

became so

disruptive

I had two very

this just goes on and on and on

about this obsession with

I don't see why we can't use Scala

we're using Scala we'd be done now and

anyway so we actually started to call this person

Mr. Scala

anyway so I had two people

two key team members and

the lead architect on this particular effort

two key members who approached

me and said

look Mark just wanted to give you a

heads up

we're looking around

we're going to leave to try to find something else

in the company but we're off this team

I said what's going on

this is too toxic we can't get any

work done just because of the disruption

with everything having to be Scala

you know I can't see why we can't use Scala

there was no solutioning ever happening

no collaboration so I said

I said can you

give me a couple of days

and they said sure

so I approached

this person who wanted

to do Scala and I said look I understand

you want to use Scala

that was the joke part

of it but

here's what I told them

I said if you can

provide me with a

business justification

where the business value

is in adopting Scala

I said I'll back you

I said I need that

business justification this is going to increase our cost

and we have to probably derail

some of our processes

we're going to have to redo some stuff but I said I'll

back you if you can tell me the business

justification

immediate high five he's like man you're the best

the next

day

comes in and he says

can we chat and

I said sure so we grabbed the conference

room and he said I got so excited

he said I was

so pumped that you gave me this

opportunity and he said I sat down

I could come up with

a whole bunch of technical reasons

but I could not come up with

one single business

reason of why

to adopt this technology

why to adopt this new process in this case

and anyways he looked at me and he said

thank you

he said

just thank you and

here's the moral of the story

he became one of our

top collaborators

started embracing collaboration

he was working with people again

isn't that interesting

so I want to come back to this question because

that's where it relates to

you know we

look at

talking to operations talking to business

folks talking to our boss our product

owner and saying we should really

embrace these processes we should really

have this new technology in place

why because everybody else is doing it

that's not a good justification

and so that's the

bandwagon that's right

yeah exactly so the very

long answer to the short question

was basically

seek

the business value this ties back

also to the political

climate understand the agendas

of other decision

makers what's important

to them

what's critical

on their mind because if

I can turn my desire to

embrace a new process or

embrace a new technology if

I can turn that into

business jargon

business needs goals

and also value that's

the way to do that

and then looking at operations teams

if you want to motivate the operations

teams to get

the new technology first of all ask

yourself why would they do that

right that's that's what's the reason

why you want them to

hop on a new technology

second of all

why would be that

benefit to them and it's not

only about that technical benefit but

it's all on the day to day so

if we're talking operations they need

to have a problem that that technology actually

solves to adopt it

that needs to be

they need to see it as a value they need to see

the why why would that be something

that they absolutely need to

hop onto otherwise it's

just hopping on a bandwagon and that's

not healthy that's right that's not

going to contribute to anything that's going to be a problem

we see that all the time in integration

for example

oh yes yes we need to do we need to do

Kafka

I'm like sitting there listening to this

oh if I had a

nickel for every time somebody said that

I would be a millionaire

yes

ok

what problem are you solving with Kafka

are you a streaming

service?

no you want to do EDA?

Kafka is not great for EDA

Kafka is great for streaming

or repetition of certain

pieces of data

but that's not EDA

operational EDA

is definitely not

a good idea to implement Kafka

but no we're going to go with Kafka

and then they try it

they completely fail everything is completely

reckless

and then all of the sudden

the CEO of a company

and all the CEO hey we're actually doing Kafka

and the other one is actually

knows a little bit more about Kafka

oh how you are tackling the performance

issue so how are you tackling the adoption

within different businesses?

sure

oops

you know what

this is amazing something

that you just said

triggered a memory

in my mind which

is one of the other answers

for how to motivate people

I completely forgot about this

this is when you were talking about operations

and here it is there's a

book by Richard Hunter

and George Westman and it's called The Real

Business Value of IT

the real business value of IT

now

it's a real business value

with a real value of IT

it's the real business value

of IT I believe anyways this

is a fascinating read first

of all their writing is great

their speaking is great full of anecdotes

and all this but it's a story about

a CIO

who is called into a board

meeting to kind of describe

what he's doing why all these

cost overruns and what

he was working on and why did he

reprioritize things this way

and he starts to go on the explanation

and they're like no no no

and the bottom line of

this book now this is

a book kind of written for CIOs

but I

urge my development

teams my developers to read this

book and here's why

because I love asking

this question for those of you

listening for example I know it's Saturday

but what are you going to do especially

if you're a developer let's focus on developers

you're a developer what are you

going to do when you go to work Monday morning

and you might say generate a bunch

of prompts to generate code no

you know usually

the answer is well I'm going to

programme I'm going to write some code

no

you know what the answer is

on Monday

I'm going to generate some business value

that's what this book

is about it's understanding

the why we're doing

something what

does it motivate somebody okay

I know you've probably

been through this I've been through this a lot

that most of our listeners

have been through this how many

times you sat down the code

a new feature and you're like

this is dumb no one

is ever going to use this

what's your motivation level

if you feel like why am I

doing this you know I'm sitting

here banging out cold grey apps

for 30 euros an hour this is

not a fun life your motivation

is so low you know why

a lot of the time

you don't know why you're doing that

today oh yeah that is

a great motivator that's why this

book is so valuable that's why I hope

developers read it this is also

the underlying

value of domain driven design

if we bring in

developers to the room alongside

business and we start discussing

building a common understanding

of the problem domain

and discussing how

we're going to solve it and building the

understanding of what we're doing and why we're doing it

this is the motivator because

they actually know what they're doing and why

they're doing it's not just

pushing code

after code into a repository based

on spec this spec doesn't tell you

why it tells you how to do your

job in that sense

we don't get motivated

it's hard to be motivated unless

you see what that code actually

does and what value it breaks

it's like

this is

from my perspective with my time in T-Mobile

because I spent with T-Mobile and I spent

about 80 years total

partially as a consultant

from an external consulting company and

partially as an architect in T-Mobile

it's

the understanding

and going into those meetings with

business as a developer

and understanding why I'm coding this

and sitting in war rooms with

those people and understanding the problems

what they're tackling

that kept me

motivating to the extent

that I remember I made a

very severe mistake as

a junior developer that

went live in production

it didn't impact production in terms of

operations or

it actually working

but it impacted the future

extensibility of that code

what I did was a very simple mistake

basically we were wondering about switching

internal integration

platform from XML

over JSON to

SOAP over JSON

which means that we would have to do

web services on every single layer

of the integration platform

so we started changing the way

we did specifications

and by pure mistake

I externalised

to the consumer

of the platform the internal

namespaces

so that basically made the code

very stiff and changes because

any change in the internal libraries

of the data models

trickled instantly, broke the

interfaces

and

you know, newing the value

of these things, what value

I'm bringing with those integrations

the sheer fact that a

few years later I managed to push

that into the requirements of

the project to finally fix that with a few

other teams that were consuming those

interfaces to change

the namespaces, there was

such a motivating and

satisfying thing to do

I was so god damn happy

that I could finally fix that

mistake of me being still a junior developer

now as an architect already

it was like

wow, that kept me going

that kept me really motivated that I

could actually have that influence and go to

business and say, hey can we add this

to the scope of this release because this is

important from our technical perspective to

lower the technical depth

it was like, yeah sure

we have space to add, we're actually going to be testing

all of those interfaces because they are

part of the project

so perfectly we're going to be able to

re-test that instantly without

extending the scope of tests

awesome, let's do that

well

you know, okay, so

bear with me here

we'll take a minute or so

but not anecdote but this

thing, so

what we're talking about is so

critical in kind of

motivating somebody in terms

of understanding that why, but there's

a caveat here

let me tell you what it is

so consider the typical

roles

that go all the way from the bottom to the top

in any sort of company, you've got

operations down at the bottom, you've got developers

right above that, you've got

architects right above the developers on the

third floor, the fourth floor, you've

got all the business stakeholders, and finally

on the fifth floor is the executive suites

the CIOs and CTOs

I love the segue to Gregor Hoch's book

yes, yes, so

here's the thing, operations

who many times

as you correctly pointed out are

kind of in the dark

in many ways

say, you know, why in the

world are we moving operations to the cloud

this is just silly, I have no

idea, I'm not motivated, this I don't care

so they ask the developers

and so the developers say

silly, we're creating cloud native applications

now, all of our systems are moving

to cloud native, so therefore it

needs to be in the cloud, and operations

goes, ah,

that makes sense, thank you, we're

motivated, but then the

developers say

why are

we starting to migrate all of our

systems to cloud native

and then they ask the architects, level

above them, and the architects say

well, because we're

basically moving all of our systems

to micro services, and micro services

are cloud native, oh, that's right

that makes sense, so since we're moving to

micro services, those are cloud

native which work better in the cloud, okay

great, and so now the developers are happy

and the architect says, why

wait a minute, why are we moving

all of our new systems and

migrating our systems to micro services

so now they're not sure, so they ask

the business, and the business says

well, because we're providing new

and better features for our customers, and we

need those fast, all right

micro services has super

high levels of agility and scalability

and all these kind of things, okay

we're happy, the business says

wait, why are we developing new and

better features, and they finally go

up to the executive level, and the reason

because we are

striving right now to be the number one

company in our

industry in this

country, number

one online retailer, we're

striving to be the number one insurance company

oh,

that's the reason

you see, why is there nested, they're levelled

yeah, but that reason will

completely not land with

the operations team, that would

be gibberish, no, well that's

my point here, is that when we

go to seek the why,

we don't go just one more level up

to understand our part in this

we actually go to seek

what is the ultimate reason

we're doing this, that's

the moral of this, is

that there's an ultimate

reason why we're doing all this

kind of stuff, why I'm adding this

new feature, and that's

what I'm urging

developers, any technologist, architect

to fully

understand that very top

level reason, sure there's sub

reasons, but it's the ultimate goal

will give us that motivation

but then you would have to

not only learn that

top reason, but actually learn

how that translates to smaller reasons

which will be those that I've actually

tracked with that person

because just understanding that reason

if I would go and just understand that reason

without chaining them together

I would be like, eh

alright, you know what helps with this?

The Zachman framework

the Zachman enterprise framework

because it asks all the major questions

who, what, when, where, why, and that's true

the why model

spans across

every one of those perspectives

that's why

and then you have a nice pyramid of

you've got your technical perspective which is operations

you've got your application perspective

your architect perspective, business

and executive perspective

and across those rows

you've got the why column

that is one of my favourite

models, because

that's where not only we

strive to understand why we're doing

something, but we can

document it as well

and you know what's amazing by doing this?

A lot of times we uncover

I'm not sure why

we're actually doing this

and it stops a certain

level up there and saying

I have no idea who requested

this, but I don't remember

We hopped on the bandwagon

Well maybe that's what it is

You know there was

one particular

use of the ZACMA framework

percolated up to

use of a particular tool

that I won't mention

that seemed rather silly

and so I did this whole

go up the chain

you know what it was?

The CTO

had made a

wrong purchase of a major

product

and this was

when I'm saying major purchase

we're talking millions of dollars

and unfortunately

just got really

sucked in by the salesmanship

of all this and anyways we

made a contract purchase

this product and

because he had to justify that purchase it

was used for every single

system You've

got to use product X It's

like this doesn't

make any sense.

You've got to integrate it with somehow and anyways that was so sometimes you uncover these weird why's and then what do you do?

Because it's like yeah the only reason we have to incorporate this is because the CTO needs to justify their purchase or possibly get fired so yeah that becomes talk about people skills What do you do with that?

In the meantime

we had an influx of comments

and because

we weren't scrolled down to the

last one we saw was from Barcelona

but

basically

it's quite a few of them

Let's take a look

Oh

here I like this one

saw skills are the hardest skills

saw skills are the hardest skills to acquire

even so it's common

to see people spending hours

studying technical topics, frameworks, tools,

certifications but it's rare

to see that same level of dedication

when it comes to learning about communication

emotional intelligence or

relationship building.

Oh yeah

Touche 100%

and ironically to even recognise

the need to study saw skills you already have

to have some self

awareness, humility

and the ability to reflect those are

saw skills too absolutely

and you are

so correct

that's very very true

you can really see people focussing

on a lot of these

This brings me

a memory of a manager that

we dubbed

give him a nickname

Mr. Dunning Krueger

not without a reason

the psychological Dunning Krueger effect

No

It's a nice curve

that Mr. Dunning and Mr. Krueger

developed in terms of

your confidence over a topic

versus your actual experience

in the topic and your understanding of the topic

so basically if you're at zero

you're basically going up

you're at the peak of

stupidity

so this is where you're

very confident about a topic

but you don't really grasp it that well yet

and then you go down

to the valley of despair

where you start actually learning

what the topic entails

and it's about every topic

it's not about IT

but just gaining

knowledge

so you start to develop

you know what you

don't know

so your breadth of the topic

not only the depth

and then you start to gain expertise

and your confidence rises but it never goes

as far as the peak of stupidity

so

that's the Dunning Krueger effect

that's amazing

it's an actual

psychological effect

that happens to people

and some people and I don't mean in every area of their life

they're stuck

on the peak of stupidity

probably in other areas of their life

they're way further as an expert

in other areas they're just climbing the peak of stupidity

still

but basically

it's a matter of

the self-awareness in that specific

aspect

from my perspective I'm looking at

also for the pyramids that you have

in fundamentals of software architecture

as well as

I had a different method for that

so basically I used

to draw circles

so it's a small circle

things I know that I know

then there is a bigger circle

around that which is exactly

the things I know that I

don't know and the rest of it

is just ignorance

because I don't even know that I don't know them

from my perspective

it's always pushing the

borders of ignorance

so beyond

that what I don't know

that I

that I know that I don't know

that's just ignorance and I'm constantly

pushing the borders of ignorance

and the board, it's not

exactly a circle, it's going to be some sort of

amoeba-like shape

because

we're going to be pushing in a specific

direction because we're learning something

but in another area of life

we're just going to be closer to the

centre of it because we completely were

ignoring it and this trickles down

to the ignorance of

soft skills which is exactly what the question is about

so to actually

have that awareness

and humility

and to gain the

ability to reflect, you actually have to

gain some experience

in that area

to gain that experience in that area

especially in soft skills, usually this

unfortunately for most people

is because they got

burned on the topic severely

that's exactly it

because of their soft skills

they damaged their

reputation, they damaged their

situation, they lost the job

something that

humbles them

that brings that humility

well that's a great way

of developing humidity

humility

there's plenty of humidity outside, thank you

because

if you continue to have a bunch of

successes, you're

going to boost your ego, you're going to say

I know how to do this, this is

what I do, just step aside

I already got the solution here

and especially in architecture

everything

is different, there's different

contexts, chances are

good chances are that

the solution you're trying to come up with

architecturally has never ever been

devised yet on planet earth

because of the number of

variables in the context

so my point is, what I've

learned, based on humility

is saying, oh yeah

I've seen this before

and all of a sudden, boom

it doesn't work, because this environment

isn't that solution

it doesn't even have to be very

different, look at all the time

so I would agree with you

I think experience and having

those lessons learned is a great

way to develop some of that humility

humility

and I see that quite often

for example in architectural colours

that's a great tool

oh there it goes, okay

we lost video in audio for a

second there, some sort of

misclick or something

hopefully

sorry for that

so looking at

architectural

katas for that matter

this is a great tool

to surface bias and to

even build that

humility at times

because

what you're expected to do in

architectural kata is build an architecture

but a lot of people

do not differentiate solutioning from

architecture

or solutioning is the process of

contextualising architecture to a

specific technology or

setup that is available

to us, and I'm always having

fun with that, if I'm running an

architectural kata and I see with one of the

teams that there for example

instead of drawing literally

boxes and lines and naming them

they start dropping

symbols from let's say Azure

or AWS

and just specific products

oh there we go

that's my favourite part, that's where it's

going to go, oh that's going to be

so fun to dismantle

gentlemen, is this architecture?

is this what is this?

what is this?

that's our solution is that an architecture though?

what do you mean?

is this which draw here an architecture?

is this marker services?

what is the architecture?

what are the modules supposed to do?

well this is the Azure software this is the event grid, this is okay but what is their architectural function in this which you're drafting?

I don't know

you know a lot of that though Carol

is just having experience

and exposure to different environments

or maybe because that's

the only environment I work in

that's how I'm going to form every solution

I mean those are perfect, perfect examples

of the golden hammer anti-pattern

you know

just because I work in Azure

means that every solution is going to be Azure

and it's going to be in that platform

and it's always going to use these services

and it may not be the right one but

but you see this is the bias

that also we talked about today

about darker reports

it said they're survey people

and the only requirement to be in the survey

is to work with a specific technology

from the quadrants for a year

what if that person has no frame of reference

because they work only with that technology

that's right

golden hammer

exactly, yeah

that's introducing bias

into the mix

so it's introducing a lot of problems into the mix

not exactly

yeah

having that humility to

step back and reflect having that skill

that skill

is difficult

I think that's one of the

the ability to have humility

awareness to reflect

these are the hardest to learn

because we don't learn them by

doing anything

we need to get a little bit

burnt and be forced

into that reflection to build

that awareness of things that

oh this might be better

you know, interesting question

for you, do you think

that sometimes

you have to have one of those

epiphany moments

a moment of just

oh I really messed up

like really bad to

make that happen or do you think you can

actually just slowly

grow into some of these skills

given my

lovely

list of screw ups

that I did over the years

epiphany moments are quite crucial

but that's

they're crucial

but that's probably precisely

because of my

neurotypicality

that I'm just

blunt to certain aspects and I need to

make that a conscious exercise

to build that awareness

but I think

it's quite possible to do the same

which is by observation

by observing somebody else's

mistakes

that's a great point

because of course we learn best

from making our own mistakes but

we do as human beings

have the capacity to learn from somebody

else's mistakes

what a great tip

that's true

but that again requires a different

skill which is also a very

hard one to go to

and build which is the skill of being

aware and observe

because only to look at things and

see things is not observing them

because you're not dissecting them, not analysing them

if you're not making

an observation, that's also trickling back

to making a reflection

and we're back to the card

skill again

it's probably possible

if you have

a decent dose of empathy

and you see how these situations

hurt other people when they

screw it up

then probably you'll be able to learn

from this as well, that's my educated

guess

but not everybody is

born with, well none of us are

basically, well all of us are basically

born with a decent level of empathy but

our environments may

trample it or

let it grow

so we're not really

as human beings in control

of how our empathy develops

over the year because it's very dependent

on our parents, bringing

our culture, our environment

and so on and so forth

to the moment that we land as adults

to the lottery

how privileged

we were as people

it's an outcome of privilege

basically

well you know it's also kind of interesting

from that observational piece

not only

and I'm going to flip this around

not only to

observe

people's mistakes

and say boy, I hope that person

learns from that because I saw something

here but also the reverse

and that is what makes

this person so approachable

what makes this person

the kind of person I want to go to for

questions and

you know that also

that observational piece

about the positives of somebody

is also really powerful too

yes

but I think as far as I remember

and again I'm not a psychologist

I'm an integration architect

as far as I remember

from psychology

negative

emotions leave

a stronger imprint

on memory

of course any strong emotion

basically leaves a

imprint in memory

because we associate better

memory with something that was highly

emotional but the

emotion of why we're going to somebody

for help

because that person

in observing that

is going to be probably more subtle

and not as

vivid and strong than

ooh that hurt

that guy

screwed up

that probably would be a lot

stronger emotionally which means

it will probably burn better into the memory

and that's why these moments

probably teach us better

because

to recognise that

oh that person is so good

and observe what that person is doing

that requires

a lot

more self-awareness

and that's more advanced

skill in that set already

so I think everybody

will start if they don't have

empathy built and that

awareness built they'll start with

those painful mistakes

and trying to learn from those painful

mistakes and then when they

build up awareness and self-awareness

they probably go to those

oh this person is actually great at that

how do they do that?

why is that a differentiator?

and for me that took years

I do this now

but if you'd asked me like five years

ago I probably wouldn't say I would be

able to do that

no

that's a skill I developed

you know there's

speaking of some of the skills

one of the real

simple other techniques

that I use

and also teach is

I call it the four C's

of architecture the four C's of being

an architect but I would

translate this to any kind

of technologist

it's not just architects but that's what I

usually focus this on

and it's the four C's are

communication, collaboration

clarity

and being concise

those are the four C's

and it's tying

all of those things together

understanding the differences

and focussing on the differences between

communication and collaboration

because a lot of times we're told

you should collaborate with those people

yeah okay and we go over

there and say I want you

three to work on this and you two to work on that

there

it's not collaboration that's communication

yeah communication is

telling somebody about something

whereas collaboration

is having a conversation about it

and it's such an easy tip

so let's say we're

brainstorming and I

say to the group oh

this is silly

what you need to do is add a cue right there

as a back pressure point

and you know what the immediate

response is?

No don't tell me what to do because it's just human nature a lot of this stuff so collaboration is looking at the problem and going it's adding that humility from that question and saying what about adding a cue here?

What do you think?

What do you mean?

Well if we put a cue there could we might handle that back pressure point the bottleneck?

Yeah we didn't think about that tell me more.

Now we're in a conversation you know it's posing it into a question really instead of a statement is one great way to start a collaboration.

Yeah because people usually in the Netherlands especially for example they don't like to be told what they must do or they shouldn't.

I don't know if

anybody does

but yeah especially here in the Netherlands

yeah it's very vivid in the Netherlands

but

that's something

that took me a long

time to have

become sort of automatic as opposed

to saying oh you need to

never mind when you start over

you know but

just asking somebody's

opinion or thoughts on what

or even just saying what about this

you know just that's

how you enter into that collaborative kind

of mode.

Now you're working together

on the solution but the other

two

before you jump to the opposite just to

jump on this one the collaboration one

it's also

it's also about

building that familiarity

and psychological safety because

if you want to collaborate the

other side of the

collaboration or the

other participants of the collaboration

they need to feel that you

care because

if they don't feel that you care

you're not collaborating you're still going to be

communicating only.

Yep that's right.

And it's hard

at times to figure out

how to make them see that you actually

care or do you actually care

because if you don't care

you can communicate it but probably you're not going to

be successful at all

but if you

find this

as a way to show that you

care find that

motivation

it's very

important it brings people

in and brings people closer

and makes them join

in on the endeavour

Yeah and you know what to your

point this is another good

technique for how to sometimes

motivate the unmotivated

start collaborating

A very interesting example for this

Yeah

As an

organiser as a host of

Utrecht meetups

or also in a company

in consulting at times

it's very hard to find for us

people to do knowledge sharing

to facilitate the sessions

usually as an organiser

of such an event you don't want

you yourself to drive these

all the goddamn time

you don't want to be the presenter

you want to be the facilitator

introduce a person and then somebody

else introduce the topic

because if you're doing it

every single time

people can have different misconceptions

this guy is an AO

because he's taking the spotlight

or whatever

you just don't have the speakers

because nobody wants to do that

but

the moment you

start showing value

that if you care about that person

and care why that person

particularly would be

showcasing that

yeah

suddenly you have buy-in

and I was like

I'm sitting now at work and we're working

with Solace

a very nice company with a very nice product

and we're supposed to

upskill people

and upskilling can be done in several forms

so we can send them to training and get them certified

PG, that's needed

but we still need to get

some buy-in with those so they can actually

want to train

and upskill, so that means we need to

organise actual knowledge sharing sessions

we'll create that

buy-in

but then we have a list of

sessions, fantastic, okay

what we can do, okay

I'll present this one, maybe somebody

from Solace will present this one, fantastic

it's going to be like

me, you, me, you, me

I'm going to be one person from this

unit just presenting that all the time

again, he's on the bandwagon

of that technology, he's just

like I said

resume-driven

development

I don't care, I don't want to, of course

I like the technology

and would love to work with it because I find

value in that technology, perfect

that's my internal motivation to do this

do I have the why

to justify that I would have

to push it into everything?

No

but I do need to

want to create the buy-in

with my devs and my architects

from my cluster to go

and join those sessions

and get certified

I'm like, okay

we need to schedule those, we have our

event calendar, so we have

somebody from our communication team to get in

chat to the guy

and he's like, okay I don't know much

about this, I'm just a new developer

oh perfect

perfect, you're a new developer

okay, we need to do a session also

using Solace with fuel salt

would you maybe

want to do that?

Because

you know what, as a developer as you

grow later into the tech lead

and then you possibly go into

either a being an SME in the technology

or are you going to

an architecture role

you need to practise your soft skills

hey, here's a great opportunity for you

to go in and practise

those soft skills, I care about you growing

as a specialist and growing those soft skills as well

I'm here to help you because I

don't want to do those sessions myself

because I have plenty of exposure already

where I present things

this is an opportunity to give you a stage

to present things and I'm here to

help you as a facilitator and also

as somebody who's done plenty of those

presentations

and help you build the deck

build the storyline

practise with me, whatever you need

to deliver that presentation, we can work on that together

I show, I care

and I do care, it's not just

for show because I wanted to just get