Architects shouldn't try to be the smartest people, but they should make everybody else smarter.

That's an amplifier.

You don't want to be a kind of Oracle where people come with the questions and look for magic answers.

The good architects are usually the ones where magically everything goes well and nobody knows exactly why.

Too many architects try to find answers when they don't have a question.

But here's the thing that answers all possible questions.

That would be nice.

That doesn't work anymore.

We've gotten so in love with complexity that if we actually cut through the complexity, we sometimes doubt ourselves.

Don't stumble on the finish line.

If you made sense out of this and suddenly it seems obvious, you've done a fantastic job.

Today I'm joined by Gregor Hope, retired from Big Tech, used to work in Silicon Valley in enterprise and even have vendors which gives them a unique perspective to talk about architecture.

We discuss how to go from software engineer to architect, what great behaviour looks like and how you can spot bad architects and what are some common traps.

You shouldn't fall into a software engineer, some of which you won't expect.

Fantastic takeaways in this one, so enjoy.

What have you seen in how architects execute that makes them really good architects for the people that actually go on that career path?

Yeah, I always say, I mean, first comment would be it's not a sort of binary choice or I don't think that being an architect is determined by what's on your business card.

So I think you can be a technical product person with a very architecture mindset, right for me.

Well, let me start the other way around.

The the bad architects are easier to spot.

The good architects are usually the ones where magically everything goes well and nobody knows exactly why the bad architects are easier to spot.

And it's like people who spew out a lot of buzzwords, you know, it's like, oh, everything must be cloud native or loosely coupled.

Now say I don't need an architect to tell me that.

I can just put a poster on the wall.

And then why, why do I need this?

This person or people who believe they should have all the decision power.

It's like, oh developers, I'm here to guide you.

You know, should make 3 components, right?

No more, no less, right?

Those I find the not so stellar architects.

The mantra that we have in the workshop and that I that I very much follow is that architects shouldn't try to be the smartest people, but they should make everybody else smarter.

All right, that's an amplifier.

You don't want to be a kind of Oracle when people come with the questions and look for magic answers, Oh, what should we do?

People come to me, right?

And I'm like, well, that's kind of charming, but how, how do I know it's your project?

It's your application, right?

How can I make all the decisions for you?

But what I can do is help you make a, a better decision.

And I think to me, that is one of the characteristics of a, of a great architect.

You can absorb the context, things that people explain to you, but you can uncover blind spots or maybe help people see different points of view, different angles, distilled trade-offs that they might be implicitly making, but they're not aware of those kind of examples.

I think that makes a great architect and it makes a nice architect if you wish, because you're not trying to be the the ivory tower big boss, but he actually an amplifier to the team.

Yeah, From my position, both in product and in software, I have seen architects that are very much, OK, it's my way or the highway and then they are a check stop that I need to actually pass.

So I have to convince an architect and actually have a conversation with them.

And from their position, there's a lot of power in that position.

In some organizations, especially in more traditional bigger enterprise organizations, bank for example, especially where risk is very much mitigated, people don't want to afford to take risks.

There's no need to afford to take risks because everything will just be operational.

I feel like that's where you have architects, which are kind of a stop gap between a lot of innovating and solutioning.

Yeah, I definitely see architects as folks who lower risk.

And I often tell people, you know, we actually done this exercise where we pictures like, hey, what's your value proposition?

And there's an architect.

Often I can say I actually lower your risk.

You might be fine without me.

You can just cobble together some application and maybe it works, maybe everything will be fine.

Maybe it scales, maybe it doesn't have security exploits, right.

But that would definitely be a risky proposition.

So I think in a, in a, in a good sense, architects actually anticipate risks and mitigate risks.

Like if scalability is a need that you have, right, If I call this an option that you want to have, then we can make the sure make we can make sure that the system has those characteristics.

So it's really a risk management function and we all know that we do risk.

It has value, right?

That's money in the bank.

I used to work for insurance.

So we know that risk equates the cost.

So lower risk is equals lower cost.

But it's probably in the different way than many traditional architects think.

So, right.

So for example, lowering risk doesn't just mean working to plan or doing everything upfront than having sort of 1 golden design or 1 golden reference architectures.

I think the banks sometimes conflate that.

Like basically they think if your plan is perfect, then the risk is low, but they focus purely on execution risk.

Like, do we build what we said we're going to build?

But software has very different risk.

Like, will the users like it, right?

Will it actually do its business function?

Does it actually move the needle, right?

Is it making revenue for us?

Is it going to make the customers happy?

Does it grow market share, right?

And I think that's a whole different, different set of risks.

And I see different organizations have very different point of views on what kind of risks they they focus on.

And that reflects on what the how the architects behave.

I'm wondering what your thought then is next to risk about complexity.

I I recently had a conversation with a senior software engineer, Bassem.

He's from GitHub.

He works on GitHub Actions, so massive scale, very cool what they do.

And his take, some people actually thought it was controversial, he says.

I like in the way we design systems, especially at GitHub to keep things simple, because simple becomes complex when you're talking about scale.

And then especially in this episode in the Commons, people that haven't operated at scale, they don't necessarily understand it.

They think complexity is a big, big part of the job and you should design for a rocket ship because you cannot afford necessarily to migrate or to evolve software.

And I'm curious how you see that?

Well, I don't see it as controversial at all.

I would say simplicity is one of the biggest strengths that a good design can have, right?

There's always, of course, there's a, there's an optimum in everything, right?

So, and this comes more of building platforms because I wrote a whole book about platform strategy and many domains have an inherent complexity.

Let's say you're building a cloud deployment like an internal developer platform.

Let's say you build distributed systems.

Distributed systems have an inherent complexity.

You need to deal with retries and timeouts and item potency, back pressure, retry storms, right?

This is just stuff, this loss of physics.

There's no way you can sort of cheat your way out of that.

So that complexity is inherent.

And we had a lot of debates when I worked at AWS for this where the product designers always said we need to make it simpler.

And like, well, we can only make it so simple because things have an inherent complexity because we build distributed serverless systems.

So that is the the one end of the spectrum.

To be careful, though, you should make it, well, as simple as possible, but no simplest.

The smart.

Yeah, it's sort of the smart version of it.

But I think it's good to understand what is the inherent complexity, especially for platform builders.

And then my guideline would be, don't try to make it simpler than that, but make it intuitive to deal with the inherent complexity.

Yeah, don't pretend the complexity doesn't exist, but make it easier for people to deal with it, make it intuitive.

And I think that is a good guideline, but you try to aim towards the minimum, just don't overshoot.

I think too much complexity is one of the biggest problems we invite into our technology lives and technology has become more complex.

Anyhow, I always say writing a monolith in Java and sticking that I want server was a lot simpler than the software I today.

The software I today of course has many nice characteristics, right?

Is auto scaling, self healing, integral created, distributed.

It has many attributes that we wish for, but it's not actually simpler, no.

So a good architect's job is really to conquer the complexity that is there, to break down the complexity, to abstract away the complexity, because otherwise we become the the limiting element.

If things are too complex, people will make mistakes.

Cognitive load is an important term these days, right?

If it's too complex, the cognitive load will go up, People will make mistakes, people will be slower or worst, people will be hesitant to make a change.

If something is too complex, what will happen is you make a change over here, something over there will break.

Nobody knows why.

You don't want to touch it exactly.

And then you don't want to touch it.

And that's the worst case in a, in a ever changing world, having a piece of software that you're afraid to touch, well, that's called legacy.

We have plenty of that.

So we don't really want to build more of that.

I'm wondering if you've ever been in a position where you were of a certain opinion and architects make other people smarter, but people don't necessarily have to agree with you.

So then you are kind of this person that people either listen to or they disagree with, but you still have to work.

I think a big part of it is working with either people or bigger aspects of teams.

Have you ever found yourself in a position where people disagree with what you say and then how do you help them?

Of course not, because I'm always right.

Yeah, that makes a lot of things easy.

That's why I became an architect, right?

I'm always right now, of course, right.

And actually, the workshop today even went into some of this, right, where we're saying is rather than just giving an answer, you frame the solution space, you try to expand the solution space.

I have so many stories where people talk left versus right.

We have a picture that we use.

You might remember it's the circle versus the triangle.

People look at a cylinder, but one is like sort of round, long cylinder and one person looks from the front and basically says The thing is a circle.

And the other person looks from the side and says, well, I have no idea what you're looking at, but that is a rectangle, right?

And they will never come to any conclusion.

And that's where people sort of start fighting.

It's like, oh, Jason is better than YAML and Copenandes is better than anything else.

And it must be in a container versus that, right?

People associate themselves with a certain technology choice without being clear on, well, what's really the solution space?

Like what are the dimensions?

What is sort of the map that we are discussing?

We might be discussing different paths, but at least in our mind, we should have the same map.

Yeah, because I see this a lot.

And this can have two flavors.

Either people never agree or they agree but they have a different map in the head so they think they agreed but they actually walk out thinking very different things.

So what I advise to people is have a common framing so at least you understand the solution space and that shouldn't be up for debate.

And then based on that framing, then you can have the discussions.

So let's take simple example.

People debate micro services.

The first thing I will do is break this down into, well, what does that actually mean?

That means modularity, but there's two kinds of modularity.

There's design time modularity and there's runtime modularity.

So you really have 4 choices.

You can have a monolithic design, little bit spaghetti, or you can have a modular design, you know, well structured, and you can deploy A monolith or you can deploy in more small pieces.

So now what you've achieved as an architect, you double the solution space.

It's no longer monolith versus micro service.

Now you have 4 quadrants.

This is for example where the model or monolith comes from.

Alright, so let's say we want software that's maintainable overtime and needs to deal with a complex domain.

We wanted to be well structured at design time because otherwise we can't represent that domain.

But maybe we don't have the scalability needs to make this like 20 different micro services, an independent auto healing, asynchronous, loosely coupled, event driven.

Maybe we don't actually have those needs.

And then now you have a solution for this, right?

And we call that modular monolith, but I call that mapping the map, like building the frame on which we discuss and then we can and discuss which quadrant is useful for us.

But making that a 2 step process makes for a much more constructive discussion because it's no longer sort of you versus me or my thing is better than your thing kind of thing, which some engineers like to do.

But it's more like, here's our world view and now let's discuss where in which quadrant we are and and why.

And that ends up being a lot easier thing.

So you disagree on some parts, but you have a common framing for your disagreement.

So the likelihood that you come to a solution is much higher.

Yeah, whenever I see a lot of people discussing this asynchronously, typically it's in Slack.

And whenever there's been a Slack message of a thread over a 40 messages, I'm like, people talk to each other and jump in a call.

But I know you're a big visual thinker.

How quickly do you actually say, OK, we need to park this and we need to Draw Something out visually so we can actually see if we're speaking the same language and talking about the same thing?

Yeah, I, as you, as you hinted me, I like pen and paper.

I like analogue visual kind of things, white boards, flip charts.

So the workshop is actually full of flip charts taped on the wall.

What I like to do is not use so much the standard notations.

They're useful in like 3-4 UML, etcetera.

They're useful for communicating what has been done.

But I like to use sort of one of visual models to tease out the nuances, right?

Is it like this or is it like that in words?

It's much easier to contradict yourself or be fuzzy.

Then in the diagram, yeah, you make like 2 boxes and either there's a line or there's no line, right?

And words, it's like these things have some relationship and they correlate it use like 1,000,000 words, right?

But you're not sure, is it two boxes?

Is it three?

Are they connected?

Are they not connected?

So a picture doesn't have that fuzziness.

So I'm a big fan of that.

The reason I think I jump so quickly to pictures is because I only come in at these points.

I only generally come in when people either sort of their debate has ground to a halt or there's a high profile decision to be made or people can come to an agreement.

So generally I arrive sort of a pen in hand kind of thing because if they come to a conclusion without me, then I don't need to do anything, which is also fine.

But usually what I find is people have different world views are not clear on the constraints or the trade-offs or what I call the coordinate system.

They don't know what their world map looks like.

And if you don't know what your world map looks like, it's very difficult to discuss a path because you don't even know which sort of planet or which coordinate system you're on.

And that's where the visual models tend to help a lot.

They, they look like simple sketches.

But in the end, what I find in my workshops is simple sketches have much more depth than people believe.

We we sometimes do the exercise of listing all the dimensions that you can put into a sketch.

So basically you can give things a size, a shape, a shading, you can label things in order 1234, you can put a legend on, you can nest things, you can position things next to each other, etcetera.

And we come to about 20 dimensions that you can express with just two colour pens and a piece of paper.

And that's the richness that you want because that way you tease out where the disconnect is or where the big system design trade-offs are.

So that's why I still like pen and paper a lot, because the tool doesn't get in your way.

Yeah, I've seen you do this.

And the first time I saw this, I was like, well, this is like very effortless.

And I feel like it's an incredibly valuable skill.

So then for me to acquire a similar skill or that exact skill would be to just do it to try and figure out which dimension fits with which situation and to actually get hands on practice and visualising things and then having a dialogue with people to see if it's accurate or not.

Is that also it from your perspective?

And I would say the most important thing is you don't need to be a gifted artist.

Well, ain't nobody was born an artist.

So I I took design sketching classes.

It doesn't.

That makes it easy it.

Doesn't it doesn't actually really show it was.

And the reason it doesn't show because it's all practice.

It's all muscle memory.

The people who draw the the beautiful things, It's just muscle memory.

It's just pure repetition because I'm busy slash lazy, depending on how you want to put it.

I don't do it enough.

So it's not about being a great artist.

I think what really helps in this is, well, the best way to learn it is to do it with somebody who does it right.

Pair up, gang up, have a mentor.

That's why I always recommend works so much better.

If you see somebody do it, somebody gives you feedback.

You learn so much faster than sitting in your quiet chamber kind of trying to read a book kind kind of thing.

So that is, is is the first part.

The second part I think that really helps in this is the pictures we draw the models, right?

They have meaning, They have semantics, right?

Multiplicity is one of those dimensions you throw, you draw three stack boxes.

Well, actually probably doesn't mean three, it means multiple.

Or if it actually supposed to mean three, you probably need to tell these people, right?

So there's strong semantics behind it.

So the diagrams, we draw a weird combination of left brain and right brain.

On one hand, they're artistic, they're scribbles, they're fun.

It's a very right brain kind of creative activity.

On the other hand, they're very structured because they're very logical models, right?

You draw an arrow.

Is that the data flow?

Is that the control flow?

Is the synchronous or asynchronous?

So being able to switch back and forth between this left brain and right brain, I call this the ping pong between left and right brain.

I think that's what makes this work.

So you use your structured engineering mind to get something down, but then you use your creative right brain mind to like, oh, is there missing dimension?

Is there another way to express this?

Is there something we're not seeing?

And then you iterate that.

It's taken me out so a long time to get to that inside.

But I still find that is the the best technique to flip between your structured logical thinking and you sort of creative kind of artistic kind of thinking.

And I think that's actually you don't need to be a genius at either one, but if you can flip back and forth, that makes a world of difference.

Yeah, and the best visualizations backed by the story are what people are going to remember.

I feel like especially with when the stakes are high and you have both in your pocket, you can land and make impact.

Right.

And the story is like the right brain, right brain, right, That's what people latch onto.

And we just did this in the workshop how we looked at and we did this like the different IT strategies for different business models, like very left brain, very architecture and we have a certain business strategy in mind.

And what is the matching IT strategy?

It's very classic, high level.

Architect kind of thing.

But then we make a matrix out of this.

Well, the matrix also pretty left brain, right?

It's a very structured way of looking at it.

But then we start looking at the matrix and we're looking for patterns and for shapes.

Now that is very right brain.

That's very sort of recognition.

Well, do we see something interesting and out of the there's something interesting.

The story comes out of that.

And then to me, that is the winning streak of what I call the architect elevator.

If you can go into a decision meeting or what we call like the penthouse, right?

The important people, right?

And you can go in there and you have a catchy story or a catchy visual, but you can back it up with your technical skill.

If somebody pokes and says, why is this?

Why do you have an X there?

Why is this linked to this?

You're like, well, because XYZ to me, that is the winning streak.

The catch a little bit is you must have both skills to do that.

Like I have found that you cannot split that into two parts.

You cannot say, oh, you do the technical work and then you give it to sort of a graphics person to make it prettier because they don't know the model underneath.

They don't know what can be changed or what can be adjusted.

They don't know the semantics.

So basically you need to get 2 parts in one head.

You need to be able to play that ping pong with yourself, right?

It's like, what pattern do I see?

What story do I have?

But is this defensible from the technical underlying perspective?

So you cannot split that into two heads.

You must get this into one head.

But once you do that, that is excessively valuable, all right, because it sticks.

It makes sense, it has a logical foundation.

It's now hand waving and buzzword dropping, right is real engineering, but it kind of doesn't look like engineering.

It's not some giant blueprint that nobody can understand, but it's actually a catchy storyline or a catchy visual or what we tried to do.

We actually give them a name.

So today we just named the DIT Strategy Ladder.

And it's a ladder because it has this shape.

So immediately it's sticky in people's heads.

And I think there's a little bit of I'm always shy with recipes because I always say like the recipe book and the really good cooking school are two very different things.

The recipe book is like, well, if you can't feed yourself and you need to make something, but follow the recipe.

But if you go to like cotton Bleu or somewhere like a real cooking school, it's not about recipes.

You learn how things work and how they function and how to make the recipes.

So that's why I always careful about recipes.

But coming back to our visualization, I think you're doing this kind of ping pong, right?

Seeing, do I have the foundation?

Can I visualize this OK?

Do I need more detail?

Can I visualize that?

That is probably the best kind of recipe that that I would suggest.

There might be a lot of people listening and they are in an icy role, so very much hands on responsible as software engineers and they could think this is really cool.

Like I want to experiment with this.

I feel like on a smaller scale within your team you can.

But when we're talking about being responsible for software architecture or system design, system architecture and then enterprise architect, what from your perspective are the skills that they need from the hard skill side?

Let's start with that and then eventually from the soft skill side as well.

Yeah, You think the hard skills side, you just got to understand your tech, you've got to be a good developer, understand the trade-offs.

And I would say the biggest mistake I see on the hard skills side is the people who used to be technical, you know, they have the hard skills, but from like five years ago or will be 10 years ago.

That is what makes our field exciting, but it's also what makes our field dangerous, right?

Because having had the hard skills might lead you to wrong assumptions because your decision or your trade off might have been a good one five years ago or 8 or 10 years ago, but it no longer is.

So the main thing is you need to keep your hard skills, your system design skills, understand trade-offs, operational aspects, observability, domain driven design, right?

These are all things you, you need to do.

Then you know the, the skills that you need to add and the mix.

And as I said, it's not just about adding more skills, it's about finding the intersection between the skills, right?

I call this the the multiplier.

You want the multiplier fact.

It's not just, oh, you're a good techie person and you're a good communicator.

You're a good technical communicator.

And it's the combination of both.

That's, to me, the mental model that you should have.

The good test is do people come to you to make them smarter?

Do they come to you with a problem and you know, not asking you to solve the problem for them, but they consider you a good sounding board like a rubber ducky.

We call this like the rubber ducking.

Are you a popular rubber duck where people explain the problem and you ask maybe a few questions, maybe give a few hints and people go back like, oh, that's an interesting way to think about it.

Or you make a little sketch and you say, hey, would this kind of help you?

And they're like, oh, and they walk off with your sketch and they go do something.

I think if you can pull that off, that people see you as a, as a source to kind of give them a little mental push or a little bit of a mental boost, then for me that is a fantastic positive feedback.

And it means you're you're actually on to something.

Yeah, I love that.

That's a fantastic signal, actually.

If people come to you and you give them perspective or you help them along the way, help them figure out what they already know based on how you how much you know about them.

I think that's incredibly powerful.

Yeah, and I have the in the book, I have the model of the phantom sketch artist, right?

It's one of the I like metaphors.

So it's one of the many metaphors, right.

But what the phantom sketch artist metaphor underliances that knowing something and being able to express something at two different skills.

And the story is based in the old days when we didn't have CC to camera.

Camera are like every two meters, right when the bank got dropped, somebody would come talk to the witnesses and say well, what did the perpetrator look like right?

And you would think, oh, you just give people a pen and a paper and they're going to draw a picture of the bank robber.

Well, you're going to get a stick figure of the guy with the money bag and a gun or something like ridiculous, right?

So people know they have seen what the person looks like, but they don't have the skill to express that versus the phantom sketch artist doesn't know what the person looks like, but they have the skill of like articulating and expressing and the combination.

That's what makes the the good, good sketch.

And often as an architect, I tend to be the phantom sketch artist.

I don't have any more knowledge than the other people.

They know everything.

It's their application.

They know what the bank robber looks like.

But I can help them express that, put that in a different format or different way.

We're like when people say, Oh yeah, just like this, right?

And to me, that is a really good collaboration because neither one is telling the other person what to do or try to be smarter than the other person, right.

The phantom sketch artist is a best, probably a better drawer than you are, but they can't do anything without your input, right.

So it's a nice example of you need the combination of the two skills.

And that is generally appreciated by people.

Like, I come to them and say, hey, tell me about your system, right.

And I start drawing something.

And my favorite comment is, oh, that's wrong.

Excellent.

Yeah.

Because, you know, you're getting more out of people.

It's like, oh, I drew a line here.

No, no, no, no.

This is not how it works.

I'm like, well, excellent.

Well, how does it look?

Right.

Once they see you draw back to what you understood, they can easily see things.

Oh, that's not what I meant.

Or there's something else.

And then you're in a constructive dialogue.

And that's exactly like the Phantom sketch artist, right?

Did they have a wider nose, a bigger eyebrows or different eyes or kind of the face of the, the shape of their face, Right.

You're in a dialogue mode.

And in the end, they come out with a thing where people say exactly like that, but they could have never made that themselves.

And I think if you do that, you will become this go to person, right?

People walk away with something that's valuable to them, but you didn't lecture them or like constrain them or tell them, oh, you have to do it.

Like this way is basically extracted knowledge they already had, but you played it back to them in a format that's easily consumed and everybody wins.

I learn a lot, right?

And they have a better understanding of the trade-offs or the the system design.

There's there's one in this metaphor.

I'd always like playing with these metaphors.

There's one more quality that makes this very much related to architecture, and that is in order to become a phantom sketch artist, kind of rare today, but when people wanted to become, you need to study human anatomy.

Yeah.

You're not a painter.

You're not a landscape painter, random person.

You draw faces.

And in order to draw a good depiction of a face, you need to understand the architecture of the body underneath, like people, posture, face structure, the bones and kind of things.

So the Phantom sketch art is in a way is a form of architect because they learn basically, yeah, the the human bone structures and anatomy because otherwise they cannot draw a good picture.

And that same is true for us.

It's not about drawing the most beautiful rectangle, but it's understanding the anatomy, understanding what people say about the relationship between the system components, and then you draw the rectangles that represent that.

But you got to understand the subject matter.

Yeah, I I was thinking when you were speaking about hard skills, how much of enterprise architecture or being an architect in essence has changed nowadays?

Because I feel like I get bombarded with tools.

There's a lot more possible, specifically with large language models, but in essence, like the Phantom Sketch artist, everything underneath kind of still holds true.

From your perspective.

Does architecture evolve quickly?

Because I feel like tooling does at a more rapid pace.

Definitely the environment in which you operate has changed.

So there's a couple of assumptions that architects used to be able to make to make their lives easier that no longer hold right.

And the one is like snapshotting, like the world is moving too fast to be able to pretend.

It's like, OK, let's just assume nothing changes.

Well, that turns out to be a very poor assumption in today's environment.

So that, for example, means exercises like trying to draw a giant ID landscape, you know, or cataloguing all the applications you have and putting that into some tools.

Taking a few months for that.

Yeah.

And then a few months, by the time you're done, this has already changed.

So for me, the assumption of being able to snapshot and being, I call this the cartographer, being the person who makes all the great landscapes, that is very useful, but it's no longer practical because stuff changes too quickly.

So one of the metaphors I use which captures the change in role for Enterprise Architects is rather than trying to be the cartographer who walks around with a giant map of all the pieces, you need to be much more like a scout.

You have a objective in mind.

You want to cross the river or beat the enemy or like move somewhere or like whatever, right?

You have some objective, you send some scouts, right?

They're gonna go look at things.

They figure out what works, what won't work, right?

And they come back to you with a very simple map, but a very timely and very expressive map, right.

So you want to cross the earth like, oh, here's the mountain, here's the enemy, the bridge is gone, but here's not so deep we can cross there, we can go around whatever it is, right But they have a very situational they have a sort of purpose driven map The map is not trying to be like the perfect map of all the exact landscape.

They only depict what's it's relevant to your move.

And I think that is becoming a more viable metaphor of what enterprise architects should do.

It's no longer plausible to like maintain this giant map where everything is on and everything is up to date.

Rather, you need to have a purpose.

You need to have a direction in mind.

Like LLMS Gen.

EI is a great example, right?

OK.

De enterprise architects, what's our strategy for this?

Where should we find the best first use cases?

How do we integrate this with the rest of our systems?

We know LMS have super high rate of evolution, right?

So how do we keep that change out of other systems, right?

What are we doing with with Agents and Agentec, right?

Is that just another form of workflow integration or is that something novel, right?

Give me a point of view.

But it's very purpose driven.

And as you will quickly see, you can only do that if you understand the subject matter, right?

You can't sort of arm wave your way through that, right?

You need to have, you know, the hard tech skills as well.

But for me, it's very purpose driven.

What should we do?

Do we have a point of view, right?

Do we have a question in mind?

Too many architects try to find answers when they don't have a question.

So it's like, oh, here's the thing, that answers all possible questions.

I'm like, that would be nice.

Wouldn't that be, wouldn't that be easy?

That doesn't work anymore.

You got to start with a question in your mind.

And then like the scout, I was like, whatever, can we cross the river?

I was OK, come back with the answer to this.

It's got to be situational and timely.

Otherwise it becomes hard work.

And we might like our hard work, but I always say we're not a museum.

We're the IT.

You can't be a historian, Yeah.

Exactly.

We can't be a historian.

We're not collecting modern art, right?

Our diagrams serve a purpose, right?

They help us make better decisions, get a better decision, Transparency and discipline.

So a the decision is, is clearer and everybody's on the same page to what the decision was actually what drove the decision.

What trade-offs are we willing to make?

That's what adding the value and that the picture just has to be a means to that end.

If that end isn't there, the picture is also worthless.

Then it just becomes modern arts and boxes and triangles and kind of kind of things one.

Of the things you mentioned was also how it can be incredibly dangerous to have had experience 10 years ago but then be 10 years kind of hands off and still rely fully on that experience.

And then I look at modern day, current age where things are evolving quite quickly.

So then I don't know even from your perspective, how do you keep up to date with things that are evolving?

How do you keep on top of things with regards to your own skill set to then educate others as well?

And the danger is particularly pronounced because you might be well meaning and you have a technical foundation.

You make rational and good decisions, but based on outdated constraints.

That is a very easy trap to to fall into.

I had a classic example I always give us.

Like we were told, everything must scale out.

But the reality is Moore's Law grows faster than most businesses do.

So in reality, a lot of modern business applications could run in a single server in memory.

You get a couple terabytes of RAM, no problem.

Yeah, your customer data, your things.

I mean, maybe not all your logs from all history, but all the current data will fit in a couple terabytes of RAM.

Like what kind of business?

I mean, if you're not Netflix or eBay, right?

If it's like a normal kind of transport insurance kind of thing, right, you'll probably be fine, right?

So that's the what's that's the danger there.

So the main thing that architects need to do is you need to revalidate your heuristics because everybody is using your heuristics.

The example I always give, let's say you a chief architect or some important architect, somebody comes and they're like, they've all these little boxes in the middle is like a big barrel.

It's a database.

Everything talks to this database, right?

Your first heuristic is oh, performance bottleneck, right?

Everything talks to database.

Bad news, right?

Then you find out, oh, or you like, or it could also be brittle integration, right?

Because the schema becomes difficult to maintain, yadda, yadda.

And then you find out, oh, this is actually a no secret cloud database.

It scales more than you can afford probably, right?

It will scale and you have soft schema or it's different documents.

So it turns out to be actually no problem, right?

This is where your heuristics are outdated.

So how do you compensate that?

Well, the the easy answer, but the easy, not easy answer is well, you should spend more hands on time, but how are you going to spend hands on time with all possible technologies.

So what I do quite a bit is hang out with people who do this right, have a network.

I don't think it's something that you can expect to manage yourself just too much going on like Jenny I is a great example.

I decided to miss the first sort of 12 to 18 months of the madness because I was like, I'm busy and it was madness.

Yeah, Yeah.

No time for this.

But then like, oh, I need to catch up quickly.

So what do I do?

Well, I chat with my buddies, Right.

What do you guys build?

Like Rod Johnson, old friend of mine, he can buy.

Well, actually, it happened to live in the South of France.

So he stopped by.

He stayed with me for two days and in two days I got the full download.

Fantastic.

Fantastic.

Great deal, right.

It's like, Yep.

So he stayed with me and then, yeah, I got the whole download, what he's working on.

He showed me all the code he's writing and then it becomes super high bandwidth.

And I highly recommend that you need some framework and you need to not waste people's time, right?

You need to be able to absorb at the high rate.

So the reprocess your assumption, update your, validate your heuristics.

But don't think you can do this all on your own.

And unfortunately, I think social media has become a not so great source for catching up on technologies and trade-offs because everybody's peddling something on or, or other.

So you got to have some trusted sources that you can go buy them a beer or coffee or something and hang out with them.

It's like, hey, that framework, what do you actually think?

Is that thing for real?

You know, what are you working on?

You know, basically be the social geek.

You know, talk to people.

Talking to people can be a great strategy for being a good architect, right?

Don't lock yourself up in the chamber.

Go hang out with people, benefit from the experience, learn from what they're doing.

I think that's the only way.

Yeah, I think it's also, even if you don't have a professional network yet, there are a lot of meet ups, There are a lot of conferences, some are completely free to attend.

You can be a social person to actually talk to people and see what they're working on and gain knowledge that way, even if you haven't built up your, let's say, enterprise network yet.

And then once you actually have a role, find mentors, people that will coach you on the job and off the job.

I think it's actually very achievable to grow quite quickly through that.

As well.

Yeah.

And I think for an architect that's absolutely required.

I mean, I even, I don't buy quite into even like the senior engineer who sits in the quiet chamber and never like talks to anybody and never looks anybody in the eye and just kind of Mumbles to themselves even.

I doubt that.

But as an architect I would go as far as say like completely impossible.

Impossible.

You can't be setting up in your little chamber and people put requirements in and you spit architectures out or something.

It's like, I don't think, I think that's how it works, right?

It's inherently, well, a from the impact that you're making, right?

If you want to make other people smarter, how are you going to do that without talking to them?

And vice versa?

For you to stay up to date, you need to have a network.

You need to be able to get feedback.

You need to learn maybe even your own decisions, right?

You need to learn what worked and what maybe didn't work as well.

Yeah, maybe you thought it was a great architecture and people come back.

It's like, you know, didn't really do what we needed or too expensive or too cumbersome, right?

You want to be the person where people come back and say, look, sounded like a good idea but didn't work out that well, right?

You don't want to be the person where people are afraid, you know, and they're like great advice, great advice.

And then they do the opposite thing, right?

Because you won't learn and you become out of date very quickly.

So you have architect, you really have no choice, right?

You need to have a network.

You can still be an individual contributor, right?

I was, you know, I was an ICI love being an IC because I can focus on my stuff and I don't need to deal with managing all these vacation plans and all this other.

So simple and just like all these performance reviews, like right, It's just like I want you.

I want to be happy, but I don't want to be the one who's like in charge of all your happiness, right?

So I love being an IC, but heavily networked.

And I think that's the model that you would be be looking for.

So there's a big difference between like a manager and where you have a large team and an architect, right?

Both.

I think there's three viable paths for people, right?

You can stay an engineer and just be a top notch engineer, no problem whatsoever, right?

You can become a technical manager and that's great because you understand people skilled, sad, you understand motivations.

You're not just a sort of box checker like you understand what people or you can be an architect.

And I would say all three are highly valuable and highly satisfying career path, you know, just with a different emphasis.

From your role as architect, you've mentioned a few times one of your roles is to be a multiplier, make other people smarter in the room.

But also you shared a story where typically you pick up a pen when people have a question because that's the point when they reach out to you, which means that's your value in a vacuum.

If you do that long enough, at some point you're not needed anymore because you've enabled enough people to do that.

OPS is the same, right?

If you have great systems, then your operations team is going to do nothing and that is fantastic.

That's like the end goal, yet we never get there.

Have you ever gotten yourself in a position where you were like, things are actually good and people are kind of practicing what I've preached, then it's time to move on.

Well, I think I'm never afraid to run out of stuff.

So some people are hesitant.

They want to monopolize knowledge.

All right, That's like this Oracle kind of powerful architect kind of persona.

Unmissable.

Yeah, which I totally don't like.

So I've never hesitated to share.

That's why I write books, right?

That's why I read books, right?

I never hesitated to share everything I know.

And I would say there's only two outcomes that can really happen.

The one thing is I really have nothing to do.

And then I just make sure nobody finds out, right?

I just say, yeah, enjoy, great.

Everybody's doing that.

Or more likely what happens is more new stuff comes along and I actually freed up some cycles to deal with new things.

And quite honestly, I'm not that good at that.

So I can definitely get better at pushing more things into into other folks.

For me, that would be the dream, right?

If I uplift everybody to the point where they don't need me for that anymore, there's a million other things that that I could be doing the the catches and large organizations.

I don't think it's a direction that you should be aiming to, but I don't think you should measure yourself by achieving that because that is rare, right?

You will have turnover.

You have different people, you have a large organization.

So the odds that you can really get so much into the ORC that everything runs on autopilot, they're actually not that great either, right?

It's more a direction ideal to to aim for.

Yeah.

But if you manage it, then yeah, just make sure nobody finds out and, you know, enjoy, enjoy the time.

You got a good gig then?

Exactly.

Hasn't happened to me.

Gotcha.

Yeah, we touched on hard skills.

We also touched on soft skills.

And one of my final thoughts was you're dealing with a lot of people as architect.

You already mentioned being an architect in a vacuum, not talking to anyone.

You're never going to be as effective as you need to be, which also means that you need to figure out kind of the internals of your organization, the hierarchy, the politics, knowing when to fight and when to actually be like, no, we'll, we'll let this one slip.

And that for me has always been an art.

Like I've only dealt with that from an IC role, which you don't get a lot of influence on or like your sphere of influence is quite small.

I've dealt with that from a product sense.

You are more responsible, dedicated for product.

So you actually can move a little bit more and choose when to play.

And there's also a concept that you teach with which is the gesture, which might play a role in actually building up that political credit.

But typically, how do you develop those skills to move organizations and to get buy in from people?

It's incredibly difficult, right?

And the way, as you already touched on, we have some, I have some mental models and metaphors that help you be more conscious about it, but they're not recipes I like.

They mentioned the gesture, right?

The gesture is the person who is trusted and tells the truth because they have no other agenda.

And that's what a court jester does.

And I think that relates very well to architects.

We have little direct power.

We don't have the most headcount in the budget, most budget, the biggest teams, but we have high influential power and that's just like a just and we can be trusted because we don't have a hidden agenda.

We're not trying to increase our budget or headcount to make our solutions overly complex.

So our resume looks looks better kind of thing.

All right.

So I think that's a metaphor I use, but always careful with people.

The metaphor is just there to make you more conscious about navigating this then never recipe for for success.

So I would say the the main thing, and you mention other metaphor I pitch is the political capital that that you have.

So I would say 1 boundary condition is like you got to be able to sleep at night knowing that not everything is a perfect state because otherwise you will get very little sleep, right?

It's just like, it's like, oh, the kids didn't clean up the room again.

It's like, whatever, right?

It's like, it's like, yeah, sometimes, yeah, yeah.

People came to me.

Oh, did you know these people doing something that violates the stand?

And I'm like, what am I going to do, right?

I have a cat, right?

It's like trying the cat, like telling the cat what to do.

It's like you also got to live with the fact that the cat will not always do what you say.

Especially.

Cats, especially the opposite.

So you're going to be able to live with that.

If not, you're going to have some ulcer or some other bad disease.

These or at least insomnia you're going to have, right?

But also another metaphor that helps me, we do this in the workshop is to understand how much political capital you have to bring change or, you know, challenge the status quo or rock the boat a little bit, right?

And I think the the metaphor helps you how much how can you earn goodwill and trust?

So by delivering things, keeping your promises, being supportive, being transparent about what you do, right?

These are all ways to build up trust, being fair, being open, you know, sharing, bring what you do right, You build up trust, but then the objective is not to be the most liked and most trusted person in the whole organization.

You wanna go and spend some of the political capital, right?

You might be the gesture and say, hey, look, your baby, in this case the project, he's actually a little bit ugly, sorry to tell you, right?

Somebody is going to tell you that thing that is a train wreck in the making.

And I'm convinced that I'm right about it.

And here's here's why, right?

And that will ruffle some feathers, right?

Some people are going to be, how can you say this?

Everything is perfect.

Look at my project status report work breakdown structure, right?

It's like, you know, basically the implosion is scheduled for Q3 and we're only in Q2.

So everything is still perfect.

Yeah, it's still good.

And you're just like, well, you know, it's like, I call this the Wiley Coyote, right, where the guy is running off the Cliff and he's still running until he looks down.

And then as soon as you look, so you got a crash.

So there's a lot of projects like this.

If they don't look, they don't drop kind of thing, right?

So that will cost you some political capital.

And again, the model doesn't give you the perfect answer.

It doesn't say, oh, today is Tuesday, today I should rock the boat kind of thing.

That's not how it works.

But it gives you a mental model to not overspend political capital, especially early on, right?

You need to 1st earn, right.

You need to build up credibility.

People think like, oh, I'm the smartest guy here, I know everything, so I can go and tell everybody that is wrong, that is wrong, that is wrong and that project sucks, right, right.

Not going to not going to end well for you.

So the metaphor reminds you don't overspend, right?

I always tell people, you know, even your manager can give you a little line of credit.

They can back you up a little bit.

So having friends in high levels helps What?

Nobody has an infinite line of credit.

You can just run around, you know, and call everybody wrong.

And oh, this should have been more loosely coupled and this should be cloud native and that should be portable.

It doesn't help anybody.

So the model of or the metaphor, political capital reminds you, you have to earn before you spend and you spend wisely.

And what I always say meant with spending wisely means have one thing where you really want to move the needle and you feel it's worth spending some political capital on.

Like calling this big projects where they're pouring 10s of millions in, calling that ugly or telling people that you think that's not going to deliver.

That's spending a lot of capital, but on one topic.

And that is much better than starting skirmishes everywhere and running around telling people every project, oh, you could do this, you could do this, you could do that.

So that's where the metaphor helps you channel your your energy.

And that's what I tried to do.

And yes, sleep.

Sleep at night knowing that not everything will be perfect.

Yeah, I I really like this metaphor because even on an architect level, on a product level, on an IC software engineer level, everywhere it applies, right?

I've talked to certain software engineers and we barely have a relationship.

And then I feel like they only complain about everything.

Everything is ugly or everything sucks.

And I'm like, yeah, we don't really have a like good enough relationship for me to be like, I can still trust you or I will immediately judge from that perspective.

If it's some someone that I know, then I know exactly where they come from.

We have a different perspective.

I have more history with this person to be like, they're not negative but they're actually critiquing and their critique is valid.

But if you just do that all the time, then people will judge and people will label you automatically.

You become sort of the grumpy old, yeah.

Person, no one wants to talk to you.

Yeah, I'm in that demographic, so I need to be.

You're good.

Double, double, double.

Careful.

Yeah.

But basically everything sucks to some degree somehow.

Are you right?

There's never the perfect thing to me.

There isn't even the notion of the perfect thing.

I always say architecture isn't good or bad.

It's not like a Hollywood movie, movie or kind of thing.

The battle between good and evil.

It's suitable or not suitable, right?

It does the job or it doesn't do the job.

That means you need to understand what job it needs to be doing, right.

But then you say, oh, but it doesn't do that thing.

It's like, well, perhaps we made a conscious trade off.

We valued this over that.

So it does this and that's what it needs to do.

And that thing, yeah, that sucks, but that's not what we need or that's a trade off that we consciously make.

You can always throw a Pebble.

You can always look at an architecture.

That's why I'm cautious with cautious with architecture reviews.

Like a third party comes in, generally they come with an agenda and they will always find something.

They will always follow the agenda.

Yeah, yeah, exactly.

They always find something matching the agenda, like the vendors always, oh, but you didn't use our latest product and they will find a very plausible case how not using the latest product is a horrible architecture, right.

So I'm always very cautious when people ask me, it's like, oh, go assess this architecture for me.

Like at least 2/3 of the exercise is do they really understand the needs and the decisions that they made?

If the answer is no, well then we have a problem because we don't even know whether this architecture can be good or bad because we don't even know what we're trying to do, right?

But if the answer is yes, if they understand the trade-offs, they can articulate the trade-offs.

Oh, this is like this because of that, right?

And here's how we decided this, then I would be hard pressed to question that.

It's like, well, you understand your priorities, you build this to your priorities.

That means you made a certain trade off, You made a model or model list, right?

Because the scaling thing wasn't as important to you.

I'm like, that is fine.

I can't go in and say, oh, the monolith is bad, The micro service is good, right?

It all depends what you were after.

So I when I do architecture assessment, it's less looking at the final product and saying whether this is good or bad, but more like reviewing your thought process and understanding whether you made conscious decisions and when the you understand the tradeoffs and whether those tradeoffs were aligned with what the business needed.

And if the answer to that is yes, well, and the architecture is good because it does what it needed to do with sound exactly, There's no, I say it's like suitable or appropriate.

There's no global ranking of here's the best architecture in the world and then somehow it ranks down to the worst one.

It's not a one-dimensional, it's not a linear kind of space.

So I think that is is very important to keep in mind when you reviewing someone else's architecture.

You can always find something that sucks in one way or another.

That's not the exercise, it's understanding the trade-offs.

Maybe it was quick and easy and cheap to build, right?

I often remind people, we generally don't like the big bottle of mud so much, right?

We say, oh, the big bottle of mud is bad.

Now The funny thing is, I know Brian Food and Joyota quite well and they're actually unhappy that their pattern got labeled into this.

Yes, they're like, oh, this is bad, don't do it.

So they actually rewrote the pattern to drive the balance more in people because the big ball of mud is quick, cheap and requires limited skill set.

Are those bad qualities?

Not necessarily.

They're actually very good qualities, right?

Who doesn't want something that cheap and quick and made with limited skill set?

Now it has downsides in terms of shared infrastructure maintainability, right?

There's a trade off, but if if it was completely bad in all regards, we wouldn't have any big ball of muds because everybody would say, oh, that is stupid, That's a bad idea.

No, it has some desirable qualities.

Being quick and cheap is a very desirable quality, right?

Deliver fast, deliver cheap and with a given skill set without sending people to like a nine month training kind of thing.

That is a great quality, right.

So it's interesting.

It's all about understanding a nuances trade off.

So even the big ball of mud, you could easily say all that sucks.

It might have been exactly what they needed at that time.

They had a launch deadline of like one month that they can't miss.

They can't hire more people and they gotta get something out of the door.

What you gonna say?

Oh, build a giant platform and send everybody to cloud native training.

Go for it.

Exactly.

The month is gonna be up.

Be like, well, you hammer that thing together quick, easy, cheap, simple, right?

Make it work somehow and then you sort out might have been the best decision.

So it's so easy to judge and be the smarty pants, but I don't think that's going to make you the architect that people want to come to.

Yeah, right.

The architect that people want to come to is a person who understands the trade-offs, maybe highlights the trade-offs in your mind.

So the people who might have made the big ball of mud might not have thought ahead for maintainability.

So I think it's totally fair to say like, oh, that was great for how far you gotten, but what does the future look like?

Do you understand the next requirements?

How big does the system have to get?

What's the expected lifespan of the system right?

And then you can guide them a little bit to what's like maybe a little bit of modularity, maybe a little bit of structure isn't all bad, right?

But this comes out of the dialogue, not out of some judgements or recipe.

Oh, that is a bad pattern.

And that is a is a good pattern.

Doesn't help anyone.

Now I must say, I take this stance a lot to 1st understand and then to actually reason.

And for me it's also fun to just probe for information if there's a decision, how well do people understand the business context?

What's the reasoning behind it?

Like is it actually sound or can I poke holes through it?

And it's not bad, I think to poke holes.

It's to give perspective and to also do it in a way and to take someone with them or with you instead of putting someone down.

Yeah.

And coming back full circle sort of on the architect, the elevator executives do this quite a lot.

So I always tell people the chances that top decision makers like board members, CIOSCOOS, right, CF OS, the chances that they come and say, oh, there's a syntax error in your home chart kind of thing or I think your Kubernetes node allocation policy should have been X, but it was why I'm very low, right?

Is this is your domain, right?

And then their domain, but they have a really good smell for if you don't have your story together or your logic together, right?

If you say, oh, Kubernetes, and if they say why, it's like, well, what dumb question that is.

Of course, everything must be always in Kubernetes because it's the future and Google used it and it's best practice, right?

And you're like hand waving, hand waving, hand waving.

Then they will quickly sense that your thought process probably has a few little gaps and they're much more likely to zoom on this, right?

They're less.

They're very unlikely to like question your actual technical decision and acumen, but they're very likely to find holes in your thought process.

Oh, what alternatives have to consider?

What metrics have to use?

How do we know what the success looks like, right?

How much upfront investment does this take?

Could we defer this decision until later?

Can we start with something simple and then we put it on Kubernetes later, right?

That's what they're after.

So having the skill of being sound and being able to elaborate your thought process, that actually helps you with executives as well.

And once they feel like you thought this through, you're an expert.

You, you work through this by reasoning.

They have very little reason to doubt you because it is your domain.

But if you cheat, generally they have, they like dogs who can smell fear kind of things, right?

They can smell jumps in logic, like if you go like, oh, from here to here and they like come again.

So exactly like exactly.

They're very good at that because that's where hidden assumptions are buried.

This is where risks are being buried.

This is where people reverse engineering from the preferred answer, right?

They know what the answer was, and now they reverse engineer guitar process.

Exactly.

They are very trained at figuring these things out.

And ironically, that's where a lot of engineers stumble when they talk to executives because they don't have their reasoning straight.

And again, that's why I think we're having a sounding board, having an architecture sort of probes a little bit, right?

Does this all make sense?

Is this sound?

Do we understand the traders and the decisions we make?

That is also perfect preparation to take something to the to the upper floors of the elevator.

Yeah, I think especially now when it's easier to cheat, have gaps in your logic just through content.

As a generator, you can ask a magical boxer question and the answer pops out.

You will distinguish yourself if you do that, sure, but also if you have solid reasoning you can use whatever tool.

In the end, your path to whatever answer, it doesn't really matter as long as your reasoning is solid.

You will distinguish yourself in those conversations specifically.

And it's a a huge way, I feel like, to build trust with people that have limited time.

Yeah.

And I have.

I have a very good news.

I mean, if we're talking about tools like LLMS and stuff, I have a very good news about it.

Yeah, I looked at some architecture documents, marketing growth.

I asked like 2 questions and I'm like, who wrote this?

And he was like, well, yeah, I use LLM.

I was like, I'm like, well that's great to use it as a tool.

But if you paste the output of the LLM into your architecture document, you can only lose because either it's really good, then we don't need you, that's not a good outcome for you, or it's not good and it's also not good for you, right?

You can only lose.

I always say your starting point, the output of the tool.

That's your starting point, and you put the.

Value on top and if you don't do that, that's a slippery slope that you're not gonna win.

And yeah, my nose, my nose is extremely good and a lot of other senior IT people, the decision makers also these long lists and the fluffy wording on this like overconfidence and things like it always shines through.

I'm like, and then if you're not sure, you ask people one or two questions, right and then.

The House of Cards.

Exactly.

The House of Cards falls down.

So use the tool.

But always says make sure the tool works for you, not you work for the tool, right?

Use it as an amplifier of your own abilities, not as a substitute.

If it becomes a substitute, as I said, you cannot win, right?

If it's a great substitute, you're still lost.

Because we're like, well, why are we paying the architect for this, right?

We just use the same tool that person is using.

Right, I love that.

I'm going to quote that many times.

So be.

Careful, be careful.

Don't be the tool.

I'd be on top of the tool.

Yeah, absolutely.

There's a lot of people listening and we've covered the grounds for what architects do, but also how to get there, some of the traps and also some of the highlight points that makes great architects.

Before you round off, is there still something you want to share?

Well, there's probably a lot more things we could share, but we are also going to going to test people's people's patience, right?

Couple things that I share with people.

There's a few traps set out for architects.

So let's say you're you're good at bringing things in the model with the sketching, visualizing, sharpening people's thinking.

Sometimes that ends up being or feeling anti climatic.

So people come to you and it's all unclear in the head and you draw a picture and suddenly it all seems easy.

It sometimes feels like you haven't done a great job because it's like too easy.

Like could it be true?

Could it be the simple?

So that advice I always gave is give is don't stumble on the finish line, right?

If you made sense out of this and suddenly it seems obvious, you've done a fantastic job, right?

We've gotten so in love with complexity that if we actually cut through the complexity, we sometimes doubt ourselves.

We're like, oh, could it be so easy?

Right.

So don't do that.

That's probably the biggest advice I give is like, don't doubt yourself if it all makes sense, it's probably you found the right model, the right to picture, and you abstracted away the right things.

You did your sense making and now it all makes sense.

That's what success looks like.

So don't doubt that.

So that would be stumbling point #1 and stumbling point #2 is, and we do this in the workshop quite a bit.

A big part of being an architect is to to unearth hidden assumptions.

I like assumptions that are baked into a design that might come back later to haunt you.

Right.

Oh, you're assuming this is always there.

Well, is that necessarily true or not?

Right.

The catch with assumptions is once you state them, they're obvious.

And this is another, these points where you can stumble, where you unearth an assumption and you clarify an assumption that people were like, oh, that was obvious.

It's like, well, if it was that obvious, why didn't you?

Why didn't you state it?

So I have some confidence, right?

There's some skills that you have as an architect to tease things out or make things obvious.

Don't ever let yourself be sold undervalue by people saying, oh, that's too simple or it's too simplistic or that was obvious, right?

If that was the case, they would have come up with it with it themselves and you wouldn't have to do anything.

So really understand that this is a highly valuable skill and being a catalyst, like making it easy for other people to articulate things, sketching something out that is actually highly valuable.

And if the end result is simple, well, that is even better.

That's like the absolute peak performance.

So don't let people ever tell you that, oh, that was easy or, you know, that was obvious.

No, it wasn't.

Gregor, thank you so, so much for coming on.

I honestly learned a lot and I'm going to have a joy listening back to this episode.

Yeah, me too.

Actually, I do listen to my audience.

Yeah, that's a good test, because if I don't want to listen to this for like 30 minutes, you know, I would expect the audience to.

So I always.

But let me know what your feedback is going to be.

Will do definitely.

If you're still here with us, let me know in the comments section what you think of this episode and we'll see you in the next one.