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.