The making of a decision

So, as Gretchen was saying, I've done some stuff - and it's great to be here with you, by the way.

Thank you for inviting me to speak here.

And I kind of wanted to show a little snapshot of what I've done.

Just so that you have some context.

And what I kind of want to impress here is that I've worked in kind of quite different industries.

I worked within big corps and outside big corps, inside little companies and outside as well.

And that means I've been exposed to multiple decisions and their effects.

And one thing is that there is kind of a lot of decisions.

And I really like how Andrew Harmel-Law in this fantastic book called Facilitating Software Architecture really puts it.

And this is about how "architectural decisions are happening over and over again throughout the lifespan of the system, eternally and unpredictably." A lot of decisions piled on top of each other, and they are an ossified record, right?

So that means we're kind of really, really, this is the base in which we're building on.

And that is recording power structures and feedback loops and - or the lack of them.

I mean, I'm sure you can relate to lack of feedback loops if you've made decisions.

And then the thing about that is that when I think back to like the ghost of decisions past, what I want you to - I want to ask you to kind of think about these questions.

Which is: Of all the decisions you made, how many times have the decisions gone exactly and precisely like you expected it to go?

Did implementing the decision take as long as possible, as much as you thought?

And I'm hoping to hear Prakriti on her experience of that, and maybe the response from people was different to what you expected?

What happened?

And if you center yourself on one of those decisions you made, maybe think about a challenging situation that you've been in, maybe think about what really goes into making a decision.

What is the anatomy of this decision?

So let's think about a few little things.

So to help us run through this is this decision-making process.

It's just a simplification of a timeline that can happen.

So initially you realize that you probably need to make a decision.

Then you kind of have some options.

Then you take a decision.

Then you share the decision, this is a step that a lot of people avoid for some reason.

And then the decision is implemented.

And then, well, and in there somewhere around there, you should probably have feedback, if not in pretty much all those steps.

So let's see.

You need to detect the symptoms.

So there is some problem.

We need to kind of detect that something's going wrong.

What about the context?

Do we understand it?

The problem?

Now, this is surprisingly difficult to agree on.

So you might have an idea of what the problem is, but you have a different idea, and you have a slightly different idea, and then we're all trying to solve this problem, and it's all a slightly different version of the problem.

Then we need to understand options that we have and also the options that are not valid.

We need to understand your system's capabilities and also constraints.

What are the limitations?

What - can you actually do the thing that you'd like to do?

What about people's availability and their capabilities?

Not everyone can do everything.

Not everyone's there for you when you need it.

Competing problems.

We need to know how to collect feedback and what feedback we actually need.

We need to know how to collaborate and what to collaborate on.

We need to possibly block a decision and make one.

We need to know how to implement the decision, have the capability of doing it.

What if you, you know, you wanted to do it and your hand broke because you went skiing or whatever.

Suddenly things go a little bit slower, right?

We need to be able to change the roadmap.

An interesting thing that also doesn't happen a lot.

We need to validate that the problem is solved.

And it's interesting because otherwise you need to just do it again soon.

And finally, you need to ask others to implement this thing.

Now, this is only a few things that I'm sure you can all relate to.

You've been there, you've done this, and you're like, you're probably starting to feel the pain, and maybe thinking about calling your psychologist, or like, "you know, this was a bit- I didn't want to go through this right now", but what I noticed when I was looking at these ingredients is they tend to fall into two kind of strong categories.

And it's like no surprise is that they fall into: you need to know something, or you need to have the capability of doing something.

or somewhere kind of in between, right?

And so you kind of, I kind of thought, you know, knowledge, power, zero surprises there maybe.

And then I started thinking about how these two things tend to kind of feed off of each other.

And for example, if you know stuff, generally that gives you some sort of power.

And if you have power, you can say: "Hey, can you tell me about this thing?" and people will stop and give you their time and share their knowledge.

Also, and interestingly, I don't know what happens in your organizations, but for each part, each section of the decision making, the balance between knowledge and power might be different.

So it could be that when you're doing this decision required thing, people pay more attention to knowledge, but then as the process keeps going further and further, that balance changes.

And my question to you is: "Is it the way you want it to be?" Is it the best for your organization the way it is?

And only really, you know that because each organization is completely different.

Another thing that I started to think about when I realized these two things is that I thought I had an intuitive knowledge or an understanding of what is knowledge or what is power.

But the reality is that I started to read about it and (Narrator voice) "She did not know what this thing was." So I started reading about power, maybe a couple of years ago.

And one thing I can tell you about trying to learn about power is that I found it extremely awkward.

I felt like I was touching on such a taboo topic.

And I think it's because of the Machiavellian associations.

You start to feel like you're manipulating people.

Like it's wrong.

At the same time, I thought, wait a minute, I can't disregard this.

It's half of decision making.

I can't just shy away from this.

So it seems like...

The way I kind of thought about it is that power exists, and learning about it is not just essential to being effective, but it's a way to be taken seriously and not being taken advantage of.

So I'm here kind of giving talk in a way to try to help you kind of - let's learn about this together and get over the taboo, right?

So I'm giving you a couple of definitions of power.

And this one is known as: 'Power-With.' And what it's saying is that power is basically, I mean, I'm sure you're reading this, it's being able to be a causal agent.

You can initiate change.

Now, side note on this.

This definition is from Mary Parker Follett, and her complete works are in this book called Dynamic Administration.

If you take one book recommendation out of this whole talk, just go and buy this book, because it's absolutely amazing.

It will explain why an organization probably dysfunctions and why.

So, 'power-with' is being a causal agent.

You're working together.

'Power-Over' is the ability to make others do as you would have them do.

I'm sure if you're listening to this, you're thinking: "Yeah, that makes sense.

Can live with one or the other, maybe." One thing that I challenge you to do is to think about: When are you using each definition?

Think about it again.

Think about your decisions that you made recently.

And it's normal.

I realize it's quite normal, or at least I think I'm normal.

Yeah, great thing to say on the stage - I think it's normal to kind of use one or the other in different situations.

And my question to you would be: Are you using the one that you're happy with at the time?

Could you use the other one?

And should you?

And that's, again, a question more on the thinking about how you would like to be.

So two nice definitions there.

So the next thing to think about power is like, okay, we kind of have some working definition.

We know it's about either making change either by telling people or not working together or something like that.

But where does it come from?

So when you're trying to learn about this - also unsurprisingly, there's like a million books called (insert number) Sources of Power.

And a lot of them talk about really how to manage and kind of deal with influence.

And I was looking for a source that was more about trying to understand where does that actually come from.

And the closest I got is "The Dawn of Everything", which is a book about the history of humanity.

Unsurprisingly, one of the sources is authority.

And in the context of architectural decision, this means generally two things.

One would be access, so access to a room, access to people, access to documents, access to know which one is the right document.

And the other way is to - on the performance side of things, right?

If people are discouraged from doing right things, whatever that means, then they won't do it, and so you won't see those behaviors.

The second one is a little bit surprising, I think, and that is charisma.

This is a blend of influence and affability.

And finally, is unsurprisingly as well, access to knowledge.

So if you know stuff, that gives you power.

And I think probably people in this room are quite familiar with that.

[Speaker B] So.

The next and last kind of big thing about power is these laws of power.

So the first one is that it is dynamic.

So wherever you are, let's say this is a little power, this is a lot of power, wherever you are there, one thing you know for sure is it's gonna change.

What you don't know is when or how it's gonna change.

And that's something that is good to know.

The second thing is that power is like water, and your organization is a sponge.

Power gets through every single crevice of that sponge, and you need to bear that in mind when you're talking to people and trying to make change happen.

The last one is that as you have a lot of power, you tend to get more power.

And the weird thing is that in a dynamic system, this kind of tends to - these three laws make power balance itself.

And then - insert spiderman comment - great power, great responsibility, etc.

Etc.

Anyway, so on power.

Now we move to knowledge.

This is the bit that I thought I get this, right?

It's about knowledge stuff, right?

What could go wrong?

I was, yeah, not so right.

So a really nice definition of knowledge.

A sophisticated integration of data, which you could think of in terms of like facts, information, you know, you kind of get some context in there, and experience.

And it's how we create our concepts, basically, how we create laws and theorems, best practices and heuristics, strategies, and predictions based on patterns.

So this is again from the "Learning Systems Thinking" book, which I think is really good, especially in this subject.

And I kind of like to think of knowledge as the thing - you know, maybe you're building, you're trying to make some drink, and maybe you don't know if you should make tea or coffee, maybe you want to relax with a tea or wake up with a coffee.

But knowledge is what helps you not create tea-coffee.

Have you ever mixed the two?

It's absolutely dreadful.

So that's what I think knowledge is.

So we're trying to kind of help people understand, basically better understand the systems they're building.

On wisdom, and I really like that this involves concepts of systems, wisdom is kind of the next level after knowledge, which is our ability to discover true leverage points in the systems we live in, really, and push them in a valuable direction.

So it's basically the application of knowledge over time is wisdom.

And the thing is, it's weird, right?

Because in all, in this, in this room, we're, we're all knowledge workers.

And I think we all think about the fact that capital is our thing, like our capital is knowledge.

But sometimes we tend to forget a little bit about how, what we're actually paid for, what we're actually supposed to be doing is think.

We sometimes think about a lot about delivering things and stuff like that.

But actually, the main thing we're giving and we're working for is thinking.

And to kind of talk a little bit about what John talked about earlier on knowledge, I think we tend to value a lot knowledge stock.

So if you think that each one of these piles, right, could be, oh, this is what John knows.

This is what Gretchen knows.

This is what I know, it doesn't matter.

So there's different types of knowledge and they're represented as things.

So we know about our internal stock, but what about flow?

So knowledge flow is our ability to transfer knowledge between people or between people and technology in ways that shift and change the system in a kind of valuable direction.

So these lines is something that we sometimes take a little bit for granted.

And we shouldn't.

And this is why.

Turns out in this awesome paper by Liao in 2007, it kind of crystallizes a lot of things that we probably intuitively know, which is that knowledge transfer is a crucial determinant of an organization's capacity to innovate and absorb knowlege.

Like how do you get better?

How do you - But the problem is that this is what knowledge distribution looks like.

So this bit is like, oh, don't really agree with that.

We need to ask Bob in here.

It's like, oh, this bit of the system, the guy that left.

So the thing is we tend to find this whole knowledge sharing a little bit complicated.

Because it's really difficult.

[Speaker B] Right?

So, okay, now we have some sort of idea of what's going on.

What do we do with this?

I like to think that understanding a little bit better, introspecting and understanding ourselves, gives us options.

So I have three groups of tools to kind of, I'm not gonna tell you exactly what these tools do, But I'm gonna give you some sort of, go search this.

And you can ask me about this later if you want.

But just giving you something to peek at, right?

So we only have 20-something minutes.

So I split this into large.

So large groups of people, more than 20.

Medium, around 20 or less.

And tools for just you.

There's more tools than this, but I just selected a few, right?

So in the large groups we have, the architecture advice process, which is this.

So it's also better explained in the Facilitating Software Architecture book, but the big idea is in your org, anyone can make a decision.

The thing is that they need to seek advice, not permission, from anyone that knows about this stuff or anyone that is affected by this stuff - being this decision.

So the reason I'm suggesting this is because what we're trying to do is resetting the way knowledge flows, which as we just talked about is quite difficult, and also we're kind of resetting or changing the power balance.

And we're doing it in a somewhat of a controlled process.

The second tool that we're talking about here is "Team Topologies".

So this is all about trying to focus on how the teams are configured.

For a long time, teams have been created by HR or honestly, it seems somewhat random to me.

I don't know, but we've known about Conway's Law for a long time.

So I like to think that Team Topologies just kind of impresses on people the fact that team architecture is also software architecture.

So, the big idea here is that you have four kinds of types of teams and three forms of interactions.

And it's trying to push you or your organization towards healthy interactions that provide a steady flow of valuable software.

So it's all kind of geared towards delivering value.

Right, so the next group - so this is like less people, you have two tools here.

There is a lot more in this amazing book called "Collaborative Software Design" by Evelyn, Gien, and Kenny.

And the first one is: Event Storming.

So Event Storming, I don't know if you've ever heard of it, but the big idea here is to explore complex domains basically by using very lightweight - basically using sticky notes - to kind of say: How does this value stream flows?

Like literally, if you're in an e-commerce shop, you're trying to think about 'customer purchases a thing' and then it's delivered.

How does that actually flow with domain events, commands, actors, external system, et cetera?

I like to think that this is a great exercise in destroying silos.

So slightly biased on this, just a tiny little bit.

So, Bytesize Architecture Sessions is a tool for knowledge sharing as a way to build your architecture practice deliberately.

So you're doing time-box sessions often as a way to either build your system or maybe you wanna make some change, right?

This is what happens inside a session.

And obviously, if you want to know more about this, please, I'll be hanging around here later.

Finally, personal tools.

And this is particularly interesting when it comes to this whole power thing, especially if it's new to you and you're like, which is how I felt.

So the first one is called: 'Left-hand column.

And what you do is during interactions, you record what's happening on the right.

So you record like: 'John said this, Jane said this other thing, they showed a picture of a dog,' and stuff like that.

But on the left, you record what you thought: 'Why did she show a picture of a dog?

John didn't tell me about this important thing.

What is John thinking?' etc.

So as you're writing this, what it helps you to do is to introspect on not - you're learning about your reactions a little bit more, because you're going to react.

Now you kind of are trying to understand why.

The next one is especially there for understanding networks of power.

So in this, this is basically what an 'Influence Map' look like.

And if you're going to learn about this, definitely look at Charles Lambdin's post, because that's probably the best write-up on this that I found.

And in here, you see like this 'D' person is basically the decision maker.

Sometimes in organizations, decision makers are one.

And, you know, that's arguable.

We can talk about that in a separate, that's a complete talk on its own.

But what you see in this map is how these other people are influencing 'D' and how you can proxy the influence through other people and stuff like that.

Should you do this?

I don't know.

But it helps you see it.

So if you're trying to learn about what's happening, at least now you have a map, which is better than trying to do it in your head and just kind of go: "I don't know what's going on." So, these are all the tools that I wanted to present to you.

Making this talk took quite a bit of reading.

Like, this is an abridged version.

There's longer versions of this, and reading these has been an absolute pleasure.

And actually, this is just the books.

There's a lot more in that write-up.

[Speaker B] So.

If you like them, please check them out.

I think they're excellent books.

On power stuff, especially on the balance of power, this book "Pedagogy of the Oppressed" was written in Brazil in the '70s.

Extremely uncomfortable read for me, but I don't know if you, but it's a great way to learn about this.

And with that, I want to say that you can make better decisions by being aware of the balance of knowledge and power that goes into them.

There's power flowing through all of your systems.

That means power laws apply, might as well use them.

This is a technical system full of knowledge workers, how are you using stock and flow?

And with that, I want to say thank you.

That's it.