Hi everyone. My name is Patrick you.
And for today's episode, we cover systems thinking, we go
over what it is in the first place and why it's becoming more
prevalent as software grows more complex.
I invited my guest, Diane amount a lien on who's currently
dancing with systems over at metrics group.
Love that Twitter handle. I'll put the links to our
socials in the description below.
And with that being said, enjoy the episode.
Welcome to Beyond coding, a dive into the world of successful
people in IIT from your sponsors Z, Bia, creating digital
leaders. Here's your host, Patrick akhil.
I love the tea mug. He's me, I have a collection,
some of them are gifts or they all have meaning.
So, every time I make a cup of tea, I get to decide which mug
to use, and always there's always some some good sort of
emotional part of it. And so, yes.
Me too. How many of them do you have
that mr. Not a lot?
No, probably 20, probably a good 20 knots.
Fits on the bottom shelf, but it's just neat to have meaning
to feel connected to meaning in the choice and mood, you know, I
choose different ones depending on my mood or sometimes to
remind myself to stay calm, or whatever, the whatever it is in
the day, another makes sense. It's weird.
How when we get a gift, I hold a lot of value in that gift way
more than what I would get something myself.
I actually don't really get stuff myself because, I mean,
First of all, I don't need a lot of stuff and when I get a gift
it's the more better. I think I agree.
I agree. Especially with things like like
the like a mug for coffee or tea where every day you experience
the connection to the person that gave it to you.
You think is yeah, I really like that ritual friend when she got
married had as a gift. She said just bring Christmas
ornaments bird. Christmas is.
And so every year, when she puts up her Christmas tree, She
thinks it's an every person that that gave her, that that
ornament. And I thought that was a
wonderful idea. Yeah, I love hearing that II got
a water bottle, which is a mean, sounds kind of stupid right by
drink. A lot of water.
I don't drink coffee, I sometimes drink tea, but water
is what I drink throughout the day, and I love that bottle.
I have multiple ones because people give them to me.
When I met my girlfriend, we were gonna date remote.
She was moving to London within a month of meeting.
Her. And I bought her this water
bottle. And at first, I was like, who
gives the person a water bottle. So I didn't bring you the first
time I went, but the second time I did, I had enough confidence
apparently, to give it to her and she still has that.
She says, that was one of the best gifts because she had
always those kind of shitty plastic ones that you would buy
in the store. So that's my, She carries you
with her all the time. Exactly.
So I get that, some kind of
emotional attachment to the stuff we get or the stuff we
give. Right?
Exactly. Exactly.
Yeah. This is a lovely way to start
the conversation. I feel much more relaxed.
We can we can just keep it going from here.
I don't need to do a countdown. We're already recording and
everything. So welcome Diana, welcome to the
show. Thank you.
Yeah we already kicked off starting to talk about tea and
and water bottles so just keep it going.
I invited you on to talk about systems thinking because I think
it's getting more and more prevalent as software is getting
more and more complex as our outside, world is getting more
and more complex in the first place.
But let's start with the system's thinking term.
What is systems thinking to you. So, it's interesting because
I've really wrestled with that phrase and part of the reason
that I have is because it depends on a context in your
point of view. So an Academia for example it's
developing a meaning and Technology.
It's developing a meaning in business and even in marketing
it's developing a meaning and so and so I've really struggled to
integrate the Different definitions.
So, I've switched to using nonlinear thinking instead of
systems thinking because then by then I can bring in things like
pattern thinking, right? So when we, when we think about
the orchestration in the system or or event-driven or the
conversation, the relationship between software we're often
thinking in patterns, Edward de Bono.
I I think he calls it parallel Thinking Out of the Box thinking
all of these things are part and parcel of what, how I would
Define systems thinking, but what we mean is that when you're
thinking more about relationships patterns, the
relationship between Parts. One of the, the one of my
favorite word's. It on in the subject is
emergence, which is when the sum of the parts is more than any
individual part could be. That you start having qualities
that that can only happen because of the and if you put
this and that you get a third thing that you couldn't have
without that relationship that when you're when you're
exploring that that's what I would call systems thinking.
Yeah. If I take it back to software,
right? If I put stuff together,
sometimes I have a side effect. I have this by-product which I
can't really explain. But when you dive into that,
when this happens in combination with something else, it's going
to buy product happens that none of us could foresee.
But I see it happening more and more, right?
Because we're attaching a lot of stuff.
There's a lot of Integrations, even when you're isolated, you
still need multiple moving Parts within your application.
You're not going to build what you reuse, actually a lot of
software. I mean, we We'll build a lot but
we reuse a lot as well, which is great.
But then kind of those byproducts happen when you say
linear thinking. I'm I should think about really
just cause and effect I guess in kind of a straight line.
Well, so it's really tricky because we are so conditioned by
linear thinking or linear thinking patterns that usually
whenever we talk about thinking, it's what we mean.
And so for example this Ready to break down a problem into steps
and then solve those steps towards a goal, that's a linear
approach to and we use that in software all the time.
It's really valuable a lot of a lot of Science is based on
linear approaches. We usually when we engage the
word concrete, we mean linear. When we say we want concrete
thinking or a smart goals and linear thinking isn't separate
from Near thinking, it's just not the container, right?
So, when we talk about systems thinking, or nonlinear thinking
than it contains linear thinking, but it is not defined
by it. Yeah, so when you compared it to
software, so for example, because I most of my career
experience has been in information systems and in
content. So the shift we would install a
piece of software and we would expand it and expand it and
expand. Expand it and add caching but
the software was predominantly triggered by a page view request
or a group of requests for the information but as we've moved
towards towards a source of information, maybe we're editors
work and and prove providing it. So for example, through graphql
where you can in any time, right, and for asynchronous
Cory, Geography, in any time, you can request information in
multiple different types of requesters, you know, not just a
web page is requesting it. That's when you start to see a
lot of emergence because then there's all kinds of things we
can do that. We couldn't do before.
Yeah. Right.
Pushing and pulling information the the timing of what it means
for something to be published or ready.
Shared like that's, that's when you're still using software, but
the relationships that you're designing Now, open up
opportunities, that weren't necessarily there before.
Yep. I like, I like the example of
graphql, right? Because if you compare it to
normal rest apis, it's a bit more defined.
What can happen within a rest API, right?
You have this type of request and you only have these types of
responses. Whereas, with graphql, your
request can be lot of different things, right?
Because it's available for you, the data to query, and then the
response is based on what you actually asked.
If the graph Q IPI, I think it's because things are moving faster
and faster. That we want more different
types of information or two, different way of conveying that
information or making available to the outside world.
I think it's getting more complex that way as well, but
it's getting a lot, interesting as well.
Yeah so from my point of view that this is so this is one of
my favorite subjects so you have it to dive into this.
But so what happened? It used to be in you know, years
ago. In my work we you build a house,
a digital space a website. Everybody did the New York Times
And The Economist. And anywhere that anywhere that
you went Amazon, it's going over to someone else's house and
having an experience and everything was really designed
for that. Yeah.
But now people want information in the context, they're in.
So it, you know what? It that's not just what device
they're on, but also they're on different platforms.
And or in Facebook, or on Twitter and interacting with it,
but also, depending on the context, they're in, they want
different priority of information.
So restaurants is a great example.
Usually, if I'm sitting here at my desk, looking at for
information about a restaurant in New York City, I usually want
to see the menu and how to make a reservation.
Yeah. But when I look at the same
information when I'm on the street in Manhattan, I want Aunt
directions. Yeah.
Where are you? Because usually, I'm on my way.
And so this idea of this jet that, now our way of
communicating is a giant graph. Yeah.
And that we want to mix and match information, depending on
the context that were in. And we want to prioritize
differently presents. This truly delightful challenge
to two systems design. That really just infinitely.
Interesting, exactly. I love the restaurant example
because Before you laid out systems thinking can have linear
thinking within it, right? Because it's more of an
overarching, mean it's a system anyway.
But with the restaurant example, it's one way.
When you're at home, very linear what information you want to
have and what you're looking for and then on the street is
completely different. Probably in a different city,
you're going to look at reviews. You have all of these use cases
now and somehow, when we're building new software, we need
to accommodate for those or even think about what we have.
And Then accommodate for that, which makes it infinitely more
complex. If we just had a few use cases,
right? But because we even have use
cases, which we can't even think of, I think we just need to
incrementally, keep going and discover and Implement.
Basically. I think that's the only way.
Yeah. And it's so so that the
challenge with systems thinking with with nonlinear thinking, is
that out-of-the-box, we're truly terrible at it and and we're not
Helped by the fact that we tend to be educated in a linear
model. And so we really and more than
that. We all of our own cognitive
biases, and logical fallacies, and all of, they seemed very
real to us. And and we have to cultivate a
lot of self-awareness to become aware of how our own thinking
gets hijacked by our own preconditioned thinking and the
ER, docs is that in order to see that we have to actually be good
at nonlinear thinking to Nord, it's a see that we're not good
at nonlinear thinking and so it's a, the way that I've been
writing and teaching about it is that it's a practice, right?
It's not, you can't, it's not like JavaScript where you can go
to training and then start, you know, in your writing code and
it's more of a some principles and some patterns just I can
systems. We are the system that we will
build, right? And so we have to adopt ways of
working with our own patterns and find the the counter
intuitive ways that we're operating that we don't really
see in order for us to get better at Building Systems of
software, and what happens, which is fine, it's totally
fine. But I've seen this again and
again where teams will go from A monolith to microservices,
right, because this is really common in my part of the
technology world, because that's what information systems are
doing, right? So the team goes from monolith
to microservices and then discover they have the same
linear patterns in their micro services that they had in the
original software and that's because that's only so we could
only change our thinking patterns so much yeah.
In order to build the microservices and that's fine
because V2 You gets more asynchronous and less linear and
so it's one of the things that we it's not there's no real lift
and shift change from linear processes to nonlinear
processes. It's an iterative practice of
Designing patterns but also changing our own approaches in
our own ways of deciding what to do, as we're have more and more
experience in more and more complexity, you know, I feel
like Like, for myself, for kind of my personal journey, I was
very much focused on kind of me. And the thing, the tasks I
needed to do, right? And as I got more comfortable
with that, you move towards the team, and as you get more
comfortable with that, you move towards, wait, what am I
actually doing? What are we as a team?
Actually doing and I come from an operations background.
So, looking at different applications that are connected
to each other, sometimes linearly sometimes in parallel.
That's how I kind of got started in the adult works.
So then when I transitioned into software that kind of always
stuck with me being that, okay, this is coming from a certain
Source, then we going to implement something and then
it's going to X Y and Z party. But zooming out, I think that
really just helps when you're good and comfortable in what
you're doing, zoom out a bit more towards your probably
direct sphere of influence your team and on their sphere of
influence, maybe other teams, or parts of organizations to get an
understanding of the system that at you operate within, right?
Not even on a software space. But even on a business level,
right, when a client actually has a problem, how does that get
to you? And how does that get to the
software, right? And if that is has millions of
hop scene between it then, do you actually know if you know
your customer or you get some kind of version of that story in
the first place? yeah, it's so for me the most
The most essential initial practice, right?
So then it's really the first thing I started talking about
is, is in a single artifact that describes a task.
So you know what your task is? Do you know why it matters?
Do you know why to the mission that you are serving this
matters? And it's interesting because
there's a lot of resistance to keeping that cohesion.
And interestingly, I have experienced it from the People I
we don't need, we just need that.
You know, we don't need to explain what we just.
I just want them to do what I'm asking them to do.
Yeah, no yeah, no. I mean that's nice for you dear.
I know that that's what you that's what it is that you want.
But we can't create code is Al is just a language and system
speaks a coding language and people speak a, you know,
English or German or whatever it is that they're speaking and
that we can And we can synergize those languages better if we
stay connected to the Y. And so it's really important
that when I'm when I'm building something in my little piece of
the system. I also really do understand how
this is going to benefit the the measured the system as a whole
and the mission that that we're serving.
And that's not really a trickier time-consuming thing to do, but
it does go against a lot. The way that we organize
ourselves to get work done, right?
And so, so it really, this is the biggest challenge.
It's kind of like, when people adopt agile, but they still have
a waterfall structure, but, and they put agile inside, then
that, I mean, it works a bit but it's gonna push against the
container. So it's the same thing with
systems thinking and And bringing people's people
together to, to work together towards a healthier system, a
more robust system, one that has better relationships and create
emergence in that system. You have to start with, exactly
how you said the task level, like improving the way we think
about the, when we we move from thinking about investing in our
or finishing, a jira ticket and we begin to think How are we,
investing our time, energy and attention, where am I putting my
energy and my attention in order to move this the software, the
system or the infrastructure that contains it.
So that it is growing, right? Is growing, the whole ecosystem
is growing and it requires often a change in the way that we lead
as well as in the way that we code exactly.
It kind of makes me sad that some People don't get that
dialogue, right? That understanding of, why are
we, why are we doing this? Or, why are we within a team
doing this right? What gold can does it contribute
to which is makes me sad, because first of all, there's
not a lot of Engineers. There's millions of job
positions, not enough Engineers to fill them.
So then when you actually are within our organization and want
to be effective, if you don't get that information, if you
don't get that dialogue, then it's just a waste because
probably you're going to make some assumptions.
All of them are going to be correct.
What? You're going to hit a strike now
and then, and you are going to be correct.
But with misinformation or lack of information, you're also
going to make mistakes and those mistakes are not going to be
bad, but they could have been prevented by just receiving the
information. And really just having that
dialogue. It really makes me sad that
within some organizations friendly, you don't get that
which was a strange realization. Yeah, it for me, I confess it's
very geeky confession, but it makes me systems sad too because
of Conway's law that, you know, the way that an organization
structures communication is exactly the way that their
technology will be structured. If you want to see how an
organization operates, you just look at the code and how the
relationships in the code happen, right?
So, if you have an organization that that Wants to have a
healthy system and to have benefits like you're saying
like, you were saying, right? That is a byproducts that they
didn't even expect like, they get, you get more than you give
when you have a really good health East technology system,
but if you don't have that exact same thing in the people, and
the way that the people interact, you won't get that in
a system. So, it just it limits, what we
can do, as technologists, it limits our ability to E to build
and design things that, that matter and are useful and that
grow. And, and that's sad to me
because I, I like to see beautiful systems, right?
And so they go, it's sort of like watching someone make a
decision in their life that you know, is really going to limit
them. Like it's not great for them and
they're going to suffer the consequences of that.
I feel like that about systems to.
Yeah, I get that it's still baffles.
I might, I don't understand why that dialogue can't happen,
right? It's something in that.
Maybe in the people, the culture of the organization, I can't put
a finger on it, but I hear more and more.
That sometimes the dialogue just doesn't happen or the technical
side of the operation. Doesn't have a seat at the table
when decisions. Get made, for example, which is
just I mean it's the basic element, right?
You grow up with it, communicate whatever you want together,
we'll make it happen. That's basically what my parents
said. We can always have a dialogue,
right? And I can be incorrect or I can
be correct, right? Depending on my age and how much
I know about a certain topic, but there's always a dialogue.
There's always an understanding or at least from one side trying
to explain for the other side trying to understand and somehow
some we don't give the same time and attention within
organization which is just ought to me.
So it's really interesting you're saying this.
I had not thought of this before but the that that is essential
to system seek, like, you can't, you can't do systems or
nonlinear thinking without what you're talking about.
And that's the way I raised my son to the.
So if I say no, you can ask what you can we can you can ask.
Why? Because it's right to have a
discussion about it. You can't keep Sighing.
Why? Why?
Why why? What?
That's not like them. Yeah, there was a time in which
I said. No.
And that's why is it? No no no.
But when he went to college and then he was in a philosophy
class and you called me and he's like um yeah some that the other
student they can't think and this is what he meant Whitman.
My son is now it microservices engineer.
Right? Surprisingly yeah so But it's
this ability to have self-aware dialogue.
Not just delegation delegation dialogue.
That's not what I mean. I self-aware dialogue.
One of the things for me that I really lucked out earlier in my
career I was on some really good teams communication wise and and
the role of the product owner, the role of the technically the
role of the people on the team and the All of the scrum master
was all about this communication and rather than delegation what
it was is. So at the end of the day, the
product owner is going to be ultimately responsible for
delivering the value. And so if the product owner
would suggest something and technically I thought it was a
crazy. Not good idea, right?
Like just know, I would say that and we would have a discussion
but in the end he or she would make the final Decision and I
would respect it. And that's what I would do
because I'm not the one who's going to, you know, I'm not the
one who carries the responsibility, but the same
with the tech, like, the product owner could say, well, I think
maybe this or that, and I would still make the final decision.
And so I carried that into my career and I think this is why I
eventually became a systems architect, right?
And working at the Enterprise level because it it is all about
communication. Vacation is funny because I'm on
sabbatical, now writing a book and the eight ended up throwing
away what I was doing and starting all over again.
And when I started all over again, I realized, you know, I
was deciding between writing acting teaching the things I was
doing before and writing code and going in technology and I
made this big binary decision and now it's like, it wasn't it?
It was a fake. Vision technology is
communication. Exactly.
Communication is taken. Like, there's no divert, there's
no, my, my role is predominantly structuring thinking.
And how is that really different from other kinds of roles that
structure thinking, right? Sadly.
It's the same thing with in a different jacket or different
challenges, I guess. I mean, the more and more I talk
to first of all everyone that I've had as a guest on the show
also the future guests, I'm going to have the I realize that
the technical problems are actually quite easy, right?
If you break it down, if you go back to school, you think about
the theory, think about an isolated problem, you can solve
that problem, because that makes it very linear right, but
everything around it. Connecting it to other pieces of
software other teams in the communication around it.
The more human side that is actually what we're struggling
with that is actually quite hard, right?
How do you fit that within kind of the overarching organization
and the structure? In the culture and the hierarchy
there and then still be effective.
That makes it a lot more difficult, all of a sudden.
Yeah and it. So this this way, be dragons,
but it's a dragon day so I'm going to go I'm going to say
that Dragon Day part so so there are a number of things, so
empathy, for example, yeah. When you talk about the, why and
knowing the why write this requires a, putting yourself in
the shoes? Is of the people that are going
to use what you're building or experience, what your building,
which is one way of describing empathy.
And then I've mentioned self-awareness right that you
need to become aware of your own thinking and I would also add
friendliness what I call Meta. Right?
So this this ability to when you if you and I are working
together and you share your idea that I see my role as As
engaging with you to see if we can strengthen it.
Like, can we, can we add more good reason behind what you're
thinking, right? So, it's a yes, and which I
learned from acting and improv, it's an improv rule, right?
You always say, yes. And you go with it, right?
Well, Tech is a huge. No culture.
Like no, no, no, no. Okay, no.
Oh yeah. Someone is wrong on the internet
like you and myself and my cell phone.
Included and so recently, I so while I've been on sabbatical in
writing the book and pandemic and colleagues, at War, all
these things that are going on, I went on retreat in which I was
doing a lot of movement and a lot of self-awareness work and a
lot of sort of rebalancing emotionally, right.
So, I stopped reacting to everything and regain the
ability to respond. And two things.
So what's interesting in my daily life is greater than 90%
of the people I work with are when I'm teaching or speaking
our men and on this Retreat greater than 90% of the people
were women. And so it's like having about
foot in these two worlds where we value one aspect of skill
intuition as a big one, I don't know how people work in this
industry especially as complexity Says without some
intuition like you just kind of know, right?
And then systems are very counterintuitive, our intuition
leads us in the wrong direction so we even have to learn how to
trust and distrust our intuition.
And so I was thinking at the end of this Retreat like we need to
cultivate experiences that bring those two worlds together,
right? So that a whiteboard test is not
going to show you how people think about Relationships.
But systems are only relationships than of.
I can be the best JavaScript programmer in the world and
still be terrible nonlinear thinking.
And so you have people that we're even saying in order to be
worthy or valuable. You have to be good at linear
skills and we end the the others are soft skills of a colleague
that I really respect and he started to call them core skills
and he said it's been going Fine since he did that but for me I
think it's the we have a cultural bias towards what it
means to be someone good at Tech and that bias leans in the
direction of a particular gender in particular race.
And and there is nothing about gender that makes one able to
JavaScript exactly and so, but we don't the tricky part is that
when we open up this can of worms, like it gets messy right
away. Way, because it really isn't
about gender. A lot of men suffer the same
kinds of things. A lot of women agree with the
Nike. It's not, it's a very complex
thing, but mostly it's just a way that we've, we've not merged
the different skill sets that are involved in thinking and
found a way to describe them in a somewhat non-binary way,
right? Exact.
So And we need to, we need to give in pandemic and climate
crisis and War and all the in the fact that our information
systems are so vulnerable to abuse, we need to learn to bring
different types of skill, sets than what we think of as it
skills together or we won't, we won't, I mean, who knows?
We won't? Where we won't get better
systems? I don't know, I don't know
whether we survive as a species. Now that's a whole nother
discussion but we won't get better systems will get the same
systems that we already have in different forms.
Yeah. Feels like a never-ending Circle
at some point because somehow you need some intervention,
right? But the people that are going to
make the change. So new people can be brought in
right with different sets of skills.
You already need those decisions being made at the top level at
the people on the inside. I feel like if you're following
a bachelor's degree Computer science.
Probably I haven't followed computer science myself, but a
lot of the skills, I'm assuming you get taught there is
execution mode, right? Solving, an isolated problem
solving, some algorithm solving some complexity issue.
Something like that. I'm assuming.
But I've also seen it in hiring, right?
Do this kind of code lead. Hacker rank challenge, solve
these issues. Before you even have a dialogue,
right? And before then I'm just talking
to an automated email system that says alright thank you for
your application. Do this hacker rank on a
challenge. If you pass, then you get a
person on the other end, which is so strange.
And then they start still looking at very technical
skills, but then first of all, the culture fit happens.
So you already need a technical bar that you need to kind of
reach before. You can do, that culture fit,
then you can see, okay, is this a good match on an
organizational level, then your questions even get asked?
And hopefully answered, but the bar is so high to get that
conversation now, Days, which is so strange.
I do see it changing, though. I more and more that
conversation. Number one is just a culture fit
and then it's a dialogue more about technology and everything
around it. Rather than the actual execution
solving an isolated problem. And therefore I'm kind of
hopeful that we're at least moving in the right direction.
So it's interesting, I this is this is we're heading all my
favorite subjects in the very fun that.
So there's some of the best hires that I've ever had ever
done in my career. The people that I hired did not
have the technical expertise in this in the software that we
were working in, because they learned that and they learned it
fast because that's what we do, right?
I mean, whatever the skill set, that I started with what I was
coding when I started, I don't code that it like that's not
what I do anymore. They just so many constant
skills. So I do think sometimes that
suppress, sometimes you need someone who who does already.
So I don't think that that's a universal doesn't matter if
people have technical knowledge, it does matter for sure.
But I've had great success not prioritizing that.
So it is very encouraging and I've never seen it fail, people
learn or they don't that's what kind of gas.
What we do. Yeah.
But the way that the way that I the way, I think it's been most
successful at least for me and then partly because it matches
my style is that someone comes in may bring people from the
team and someone comes in with a problem that they solved, right?
And they walk us through it like, they walk us through.
Here's the code here was the problem.
Here's how I understood it and that if 20 minutes later, we
forgot that this is an interview and instead We're just all
talking about this problem. And, you know, the, those other
Engineers we're asking like, oh well, why did you do this?
We've had that in the past ouo and you eat and then then then
what else do you need really? Yeah.
Like then we're going to continue to solve problems
together and be able to work it out and be able to think well
together and that's that's mostly.
It's mostly what? I what we do, right?
Least for me that's what mostly what I've done.
And what what I've done with teams and and the there's an
interesting Quirk and it's kind of embarrassing to say I'm from
it's funny because I feel a bit embarrassed to say it, but it's
true. It's an interesting Quirk is
that I've worked my entire career I have never not worked.
I have always had the next thing as always come in.
The next thing is always come and I make A lot more now than I
did when I built my first Drupal site for a local YWCA.
That's good, many, many years ago.
And so, so it's that way, if a very successful, I have never
been hired through a traditional hiring route.
Okay. That that I haven't done that
very often because usually the next thing comes along and the
next thing comes along, but a few times in my career, I have
done. Knee, like met someone who's
like, oh, we're looking for this and submit your resume and I,
it's never led to a job that way and I could be me, it might be
me, but I think it also says something about because the, I
mean I've been really successful for some of the same companies
later when I came in a different way.
Yeah, exactly. And do you think, I mean, you're
probably on the inside, do they still do those traditional
hires? Because this is more of a We
already know you. You start with a dialogue,
right? Do other people.
Get that same treatment when they come in.
So I think some people are just good.
Also, at the way that we that we at that structure, they're just
really good at it. So I think a lot of people who,
you know, are great to work with terrific to work with do fine in
that structure and they get hired.
But I know a lot of people who are more glue roll people,
right? Which would be the systems
thinkers writers. The non linear thinkers.
A lot of people have had really dehumanizing experiences in
companies that everybody would know and think are awesome to
work with. In fact they found it just
humiliating really. So I think it's kind of it's
like public education. Like not every 12 year old is
working at the same level and every subject really.
So we have a linear model and some people happen to fit really
well in that near model and some people don't and we don't
question the model I have seen in my career and maybe it's just
the way the environments I've ended up.
I've seen more whiteboard testing as a way of hiring now
than I did say 10 years ago and I am concerned about that Trend
and not to say a black or white, yes, or no, good or bad.
But I do think that this task Stir.
But this brings up a whole nother subject of communication
in a hierarchy and nothing brings out our our our ego
structure, like hiring, right? Like we like we like that a lot
of us, a lot of us do, right? We sort of like that some of it
feels like hazing to me like we're all applying to a
fraternity and we have to get through this hazing in order and
that isn't Partnering for for Progress, that isn't Collective,
reasoning and collaboration and the kinds of things we need for
systems. So I think one of the challenges
is as soon as we get this, this power aspect.
Yeah. Playing a role then it's like
Schrodinger's cat, right? We looking in the box that would
change the result so we're making it really super messy.
And also that you say that I'm sorry, no worries.
It's interesting that you say that because I recognize that I,
I got hired when I was, I think 21 and then at 22, I needed to
do an interview but I was, the not, the interviewee.
I was the interviewer which, to me was weird because the person
sitting across from me, was probably in their 30s or 40s and
I had a resume and I needed to ask questions right already in
my mind, there was some kind of weirdness here because there is
some mean it was weird, interviewing someone.
When I was older than me, even though they had probably far
more way, more experience than I had, obviously, in different
areas, but still somehow it's shifted and I hadn't realized
that until you said it, but now it's just a dialogue, right?
I start with the conversation with listen.
We're equals this needs to be a win-win.
So we're also going to have that communication that dialogue as
equals, right? Because in a team that's already
there. As soon as we hire, you were one
in the same within the same team basically.
And that's how we should treat each other.
I don't know for myself, when it shifted, when it didn't become
this weird hierarchy thing, but it just became kind of an equal
level of communication. But I'm happy, I realized that
now and I think it changed for the better actually.
Yeah, yeah. And there's a difference between
judgment and discernment, right? That we are.
We have to discern, we don't have to make a choice here,
right? And there's some discernment
that goes with the choice, but that doesn't have to be judgment
or fact, or any of that. And, and also, we also many of
our own biases, get in the way and in Tech, their reaffirm
reinforcing. So you were telling you or
talking about computer science. So for me, I went to my mentor
after the second year and I said, This isn't work for me is
that I just took a final exam where the person who we all
wrote code and the code fought against each other.
And the last man standing got the a, this is not academically
interests. Exactly.
Oh, Come to Me said, I feel like I'm in a room full of Tonka toys
and Legos and these, and I like those toys, but that's all
that's not what I'm trying to do in the world, right?
And he said, and he was the reason he was my my Mint or
whatever the right word is is because his class is terrific.
That's what got me into computer into programming in the first
place. And he said, he said, I
wholeheartedly agree, Diana, I wholeheartedly agree.
And I want to hire more diverse professors, but in order for me
to do that more women have to stay and get a PhD, which means
we have to go through the gauntlet of how things are.
And he said the thing that you don't know, No, though he said,
yes, we've got these whiz kids and I was 35 when I learned to
code like I didn't I had a whole life before I went into Tech and
so in he said, he said, he said the thing you don't know though
is your who business wants? He said that.
Basically what you're saying, he didn't say it this way, but it's
what you're saying, it's the ability to have these strategic
conversations, it's the ability to think this way that you've
got these whiz kids with this incredible Tech skill.
That's only part of the equation and I was getting a so it's not
like I was struggling to write the code but I was struggling
with the, with the, the culture of the structure of the work and
the what we thought was winning, what?
What? The other people, the other
students thought was winning is not what felt like winning for
me. Yeah.
And so that that has been a career-long challenge.
And I have worked with many, many people.
And, of course, almost all of them men, who have been
instrumental in my ability to do what I do.
I've had people throw me into in seemingly, impossible challenges
and trust me to code my way out of it raid.
So it's definitely not, you know, it's not a duality and
there's a lot of complexity here.
But again, when in the G that I was in, it was reinforcing a set
of cultural values of communication values of all
kinds of things that didn't fit me and didn't have anything to
do with whether or not. I should continue in the career
and that happens in almost every organization and especially
around hiring. Yeah?
Right? We make assumptions that other
people will think like we think. And so we're testing to see if
they think as long as we're testing to see.
Do you think like, I think? Because that's what Counts.
Yeah, well have no diversity. Exactly have no diversity.
Will have no systems. Yeah, I completely agree.
Right. On the other hand weight on top
of that, we need both, right? You still need people that are
the glue. As you mentioned it right there
are great at communicating great at the riving.
Okay? Where's the value challenging?
The product owner, for example, challenging the stakeholders in
a way as well with that technical knowledge that can
still execute, but that might be better at gluing things
together. When it comes to dialogue and
communication and then on the other hand, people that can
execute when you give them a problem, they have X ways of
solving it and they choose probably the right one, the most
scalable one, the most effective one depending on what the
environment asks of them, right? If it's time they can be the
fastest possible. If it's quality, they can build
the best quality service, but you need both probably within
the same people, but people are not necessarily equal, right?
You can have your preferences, you can tip that.
A little bit more towards glue or tip that scale a bit more to
his execution. I just think the Whiteboard and
the execution side is so well defined because that's way more
linear thinking way more. Okay, we have a we have a
problem solve it. We'll see how you do it.
We'll have a dialogue along the way.
Where's the glue side is not as refined, I guess.
It's it's more soft. That's why it's probably called
soft skills and that also makes it harder to test right harder
to make it quantifiable if the person I'm talking to Actually
has that or his movie faking it or is maybe just really good at
storytelling because that also helps if you're great at
storytelling but maybe they don't know.
It's hard to measure. If you can actually execute that
within the current organization because it has a lot more
factors going against it, I think as well.
Maybe that's why the Whiteboard is just way more out there.
Way more chests in that way as well.
Yeah. And it again linear thinking is
what we think is thinking. So we, you know, there's a lot
of reinforcement for that. And this is why the practicing
pattern pattern thinking parallel thinking these things
are really helpful, also, empathy, communication,
self-awareness, it being embodied that, you know, we most
of our reactions to things are not going to help write it.
We need to be able to respond, which means that we need to Be
able to process what we're hearing from other people and
synthesize it with our own knowledge and judgment.
We need to proactively proactively, get other other
people's experience and blend it with our own.
And so these are real skills that you can practice if we're
willing to think of them as it skills and the better we get it,
that the more will develop something a little you know
won't be a whiteboard test, but it will become more apparent to
us. If someone has cultivated that
that skill set and there was something you said that was very
provocative. I wanted to respond to it.
Oh darling. Run out of my fucking about the
kind of the glue in the execution, more tipping the
scale and how he knew both. Yes, because of this is the star
like to me. This is the highlight of at
least for me the most valuable lesson that I've learned and
that is Ownership. So a long time ago, I was lead
on a team and there was some discussion about whether other
teams needed lead or the role of leadership and bless their
hearts. When the question came up of
what lead was? Someone said oh, it's team
secretary. Hey, well, there's a loaded word
right there that. Yeah, exactly.
Like you know, like I don't want to have to be doing the
communication. So first I learned that I was
Doing the communication because my teammates didn't value it.
And so that was a really important lesson to learn,
right? Because I would just going to
play Wendy in the island of Lost, Boys, for my entire
career. If I did not realize that the ID
I needed to not overcompensate in that way.
But also another engineer who was terrific and I still still
one of the best ones that I've worked with.
He said will die. And I want, I just want my code
to speak for me. Your code doesn't speak speak
like literally doesn't speak. So I stopped doing the
communication and the team had 20 points prints because there
was so much happening there that made the code deliverable.
But what came out of that is that he and I write code speak
for me. And me we figured out that
together we are better than the sum of our parts and he's the
person I always want like Exactly what you're saying, the
the execution, the like, no matter how good my code or my my
architecture is he's gonna make it better right, conversely.
I think I'm great at business language, I might speak normal.
I'm not like a Super Geek I speak nor oh yeah, until I try
and do it. And then we would like to have
pointed back in my career there, like read that paragraph Diana,
and take out all the text speak in that paragraph, and I have to
get rid of half of It because I still that's how I talk, right?
Yeah. So I think I'm good at it and
I'm not. So I partner with people who are
good at it and together we one of my favorite Partners was he
was head of Graphics, right? So he's a speaks, a very visual
language and I do not even though I'm an architecture is
really weird because I have to make models and speak visually,
but it's I've had to really practice that skill and I was
not Born with it but I it's also because I learned from him, they
just Basics. Like Diana, there's no key.
There's no key on this picture that you've made what to any of
these symbols. But we don't need keys when we
talk engineer to engineer because we know what we mean
right? We presume we do but as soon as
you talk to people who don't speak our language, they don't
know what it means. So this this that a team is not
a silent that we love this hero. Visual thing.
But if you really want to build complex, interesting matter full
systems, it's about the Synergy of bringing people together who
can blend their strengths and compensate well for their their
challenges. So that you have exactly what
you're saying. The execution, strong, strong
execution, and also the willingness to always be
learning like, no, it's it's hard for me to go into a team,
which I've been recently were a team.
They're brilliant, they're brilliant.
And I'm supposed to be contributing but I'm learning as
more often than I'm actually offering something valuable and
that's how it should be. That's exactly how it should be.
And if we don't if we're not Is that not how we view
relationships within technology teams or between the teams or in
leadership? Then we're really again, it
makes me systems sad Greg, we're going to limit our ability to
create something. That's better than any one of us
could create a loan. Yeah, I mean even within that
team, right? You could call it a system
because if you partner up if you release synergize then you're
going to create that by product for talking about my love.
Dialogue is going to happen if we're going to realize together
then actually oh we could also do this.
We don't just have a and b, which I thought I had a, you
thought you had bo. There's an option C because we
have that dialogue and you can be that way loyal machine that a
team should be, but you can't do it all.
I used to think if I multiply myself and I was in a team of
Patrick's, we get stuff done. I luckily now realize that's
actually not the case, I'm actually not as good at a lot of
things that still are required. Right.
But that's what we synergize, and we can synergize best by
having diverse backgrounds, diverse people within that same
team and knowing, and having that dialogue.
What each other is actually good at what their preferences are,
what we can help them win, or how we can still that share that
knowledge, right? Because I still want to know the
things. I don't know that other people
are better at, right? You're never going to stop
learning. And I think, the only thing you
need, there is just the hunger to keep learning.
Yeah, and be better. That because of it.
Right? And that and then you get to the
next level rate, which is now for me when I make an artifact.
So an artifact can be anything really, any way that I'm
structuring thinking to share, right to for people to give
feedback or to see basically to show if we've come to a
conclusion, then I want to show how we came to that conclusion.
What are the reasons that support?
But I'm saying, here's an action.
I recommend here are the the strong reasons why I This action
and also, some of the risks and, and weaknesses.
And in. So, in order for me to make a
recommendation, that is sound, right, that I is trustworthy
might not be right? Yeah, but it sound and it's
trustworthy is I have to go find the people who don't think we
should do that and understand why they don't and then discern.
So does that change, does that change the way the argument that
I'm making, right? Then I'm the conclusion that I
have come to and if it doesn't then I need to handle it.
This A this is a point of view and it's a valid point of view
and here's why I'm not I'm not flowing with that point of view
like here are the trade-offs because we think, oh, do we
think? Oh, we think we think there's a
right? And a wrong.
Yeah, we love and I love it. Like, at being at a conference
in debating. Like how you do configuration
Management in a piece of software, 2:00 in the morning,
is one of my favorite things to do.
I'm never Up at two in the morning and less amount of
conference something I've missed so much covid is are debating
things as if there's a right and a wrong answer, but there isn't,
there's only in the context that we're in.
This is the best possible solution.
We could come up with together by thinking together and also
outside of our own little bubble and we've come up with.
And so then we're going to try it.
And we're going to see See what happens.
And if we're wrong then we're going to learn, right?
Exactly. And that's not that again.
This is where the root of linear thinking concrete, right?
Or wrong yes or no show me how this is delivered you know break
this down. Show me how it's deliverable the
you're too abstract you're too abstract everything, the whole
point. We build what we think.
So, if we can improve what we think, we can't improve what we
build. And so we as this the, you know,
people say about well concrete concrete.
So if you have an architect, that shows up on the piece of
property and immediately says, pour concrete over there.
That's not what you want that role, right?
You want some discernment because once that concrete is,
is poured. That's where the house is going
to go, right? The same thing with software and
there's a even there's endless discussion about the word
architect and the role architect and engineer versus Team versus
Rural. And sometimes I find it
offensive and sometimes I find it tedious.
And sometimes I find it incredibly interesting and
energizing it really depends on my mood and also the where the
conversation is going. I was at speaking once sitting
at a table at lunch and some Young man sat down nice and he
saw that, you know, I was a speaker and Architects and he's
like oh, you're an architect. I want to be an architect too
but I don't know enough of kubernetes yet.
Oops, that conference most of the other speak, most of us were
constantly engaged in that discussion is senior
technologist. Or is it?
And then a lot of people hate it because it's another hierarchy
role, which I don't know how any architect it succeeds in that I
need my teammates. Educating me like sorta to
succeed. So I can't.
And besides, I don't like who are they working with?
With, I never worked with a team that wants me to tell them what
to do, they that would never have worked for me.
Like they wouldn't have done it, like, it had to be Collision.
But what I mean is that someone has to be the voice and thinking
about the system as a whole, how the patterns and how the parts
come together. So that some of us can focus
more deeply. Some of us can focus more
broadly, some of us can focus on business like big, so again,
it's a Synergy but it is the one who is going to And nonlinear
thinking, and nonlinear approaches and structural
challenges, and tweak the abstract.
So that the abstract is sound and and and strong and well
synthesized. Exactly.
I don't think everybody has to do that, but everybody does do
that like, it's not, it's not either/or, it's not that, I
don't code. It's not though mostly I don't
because there's too much. Alexa tea for me to stay
constantly engaged but I do I still do that but that's not
really the point. Like it's the - about we're all
actually building the same thing.
Yeah, who are you speaking for? What are what's your point of
view that you're contributing and what are the different
points of view that are necessary in order for us to
have sound reasoning? So that when we build something,
we can be pretty sure that we've made a good guess and it's
exactly. Yeah, and it's all about kind of
getting that shared understanding, right?
Because within that team, it's great.
If everyone understands it to the same degree, right?
That's not necessarily required, that would be great.
But you only need to understand it to a certain degree and then
from a role of an architect, that's how I see it, right?
They probably understand it more or better than the teammates,
right? Because they are more involved
within that. They're also think about
communicating that to the business more so than the people
that are Within that team so it's a Synergy, it's relying on
other people for certain skills and that makes the team actually
a team at the end of the day when they can rely on each other
learn from each other and execute the best.
A team can. Yeah, and being open to
flexibility that. Like I've had a number of
different titles of CEO was my title once in a real Anna, in a
start-up. Like it depends on the context
that you're in. What you're going to speak for
like, what you're going to speak for and then what you call
yourself aligns with that. So it it, you know, I, at the
end of the day, I think, probably in my heart of hearts
Engineers, always going to be my favorite, my But it is it is
someone I've learned so much from an expert in knowledge
system, Knowledge Management wisdom like how we cultivate
wisdom through Knowledge Management and has worked with
some of the very biggest biggest brands and he said, you know, if
you're saying Knowledge Management or information and
people aren't that, that's, you're getting tripped up on
that. Don't call it that too.
Stopa just practice the principles and I find this with
agile, I find this with architect, like we got a bit
hung up and people have had bad experiences and then they think
that's the thing like they've had.
They've worked in not really agile and then they don't like
agile, right? So so some of it for us to is
about being contextually, strong in principles and strong in our
practices, but a little less opinionated about what we call
them. And I Reframe them.
They were learning and and maturing ideas every time
someone unfortunately it's like the virus right every time
someone adopts one of these practices.
Then it mutates somewhat. It change that connect and it
grows and it becomes stronger. And so, so that's another linear
and kind of concrete way that we like to have absolute yes, or
no, right or wrong. This is what we do.
This is what we don't do. And we don't, I am a very I do.
I my job is very hard and I think it requires a tremendous
amount of self-discipline and and a lot of work but it's also
can be very fluid and flexible and I think that's true in
educating ourselves about anything.
Like I'm definitely not. Someone once said was on
Twitter, they was unstructured. Learning is a complete waste of
time. Like I said, like what, how who
how do you get through a day without any unstructured
learned? Like, we, like, we're constantly
unstructured learning, but at the same time, structured
practices are good. So what are they?
What's that balance between just enough structure in order to,
then be able to discover? And they think that What an
architect helps to do, right? It helps to create just enough
structure for what we're building.
So that and with people building it not off on their own, but
with people building it just enough structure and that
structure is flexible enough so that it can some can change and
some cannot and you're clear about what you're marrying and
what you're dating in terms of the ideas that you're that
you're that this this has but also creates the space to play
in. And, uh, space for ownership of
that, and a Reliance on other people's expertise.
So in the work that I do now, the, the moving pieces,
especially so AWS is a great example.
Like every three seconds, there's a new tool, I guess
something a better way. And there's no way for me, these
are not founded a to be the expert on all of that, all that.
Exactly, but I don't have to because I work with brilliant
people who know their head I gave you No it.
So it's okay for me to be wrong. I'm usually right about things
like structure and patterns but I won't necessarily know the
best approach but I've got five other people, it working with me
to figure out together the best approach.
So I don't have to know. I just have to know enough to
make sure that were maintaining integrity and conceptual
Integrity across the system and that we're asking the right
kinds of questions about the type of patterns.
That will make a system like feedback loops will make a
system grow and and I don't have to be the smartest person in the
room or the most expert on this particular software, that
particular software because it would hold everyone back.
If we were limited by only what I know.
And also that wouldn't be interesting to me, like, I think
it's a do this, please? No worries.
I think it's a, it's a strange comfort that you It from
realizing that right? That you actually, you don't
have to know everything, it's fine to say, I don't know, but
we can figure it out or I don't know.
But I know, you know. So as a team we could figure it
out, right? It's very comfortable because
then all of a sudden those closed doors that you're
standing in front of they get opened up right.
And you have way more options because you have that those
people around you, those people that you could learn from and
those people together with you can execute.
Basically, I really love this. Conversation.
It kind of went when all over the place.
But I love the route that it took.
Thank you for coming on Diana. Oh, I'm sorry, there's a little
bit of a lag. I think.
And I keep interrupting or is apologize for that.
No worries. I wanted to say, I want to thank
you for coming on because it's very, I guess the last thought
about this, right? Because I think we've landed in
the exact right place and it's the secret Truth.
For me, the teams that are really good at what you and Just
talked about, we deliver a lot more faster.
Exactly. That actually also been the most
successful at doing what we're doing teams.
And the ones that really struggle with this or not,
haven't just been painful, but we also get very little done.
So, in my secret heart of hearts because I actually really liked
building things. I'm like, but this is what works
mentally like dead. Get out of our own way.
So I like that we landed there like Effectiveness we It came
from abstract and right back to, this is actually just how to
write code, like, pow to deliver products, or whatever it is.
We're building. Exactly.
I love the route that I took. Again, I want to thank you for
coming on. I'm going to put all Diana's
socials in the description below.
And with that being said, thank you so much again.
We'll see you on the next one. Great thank you.
Thanks so much. Thanks for listening everyone.
If you like the episode, I want to support the show.
Don't forget to leave a rating better yet.
Share the episode with a friend. Let us know in the comment
section below. What you want to hear.
I will make it happen. Cheers.