Facilitating Software Architecture: Empowering Teams to Make Architectural Decisions

Intro

Sonya Natanzon: Hey, Andrew. How are you?

Andrew Harmel-Law: Hello. Hey, Sonya Natanzon. How's it going?

Sonya Natanzon: Going well. Excited to be here? I was really looking forward to this conversation for a while. But...

Andrew Harmel-Law: Me too.

Sonya Natanzon: ...before we get going, can you introduce yourself, please?

Andrew Harmel-Law: I'm Andrew Harmel-Law. I'm a tech principal at Thoughtworks and that means I do loads of different stuff, but pretty much I do software architecture stuff for clients, not all around the world, but all over Europe, doing lots of different things and lots of different projects. So, I've been lucky to see a bunch of stuff happening.

Sonya Natanzon: Wow, exciting. That is awesome. And of course, congratulations on your new book.

Andrew Harmel-Law: Thanks very much.

From Blog to Book: Trust as the Core of Software Architecture

Sonya Natanzon: It is an awesome achievement. That is what we're here to talk about today. So, I will give myself a moment to be a fan and say the blog post that started it all was formative for me. It got me thinking more about how architectural decisions were made. The book was really, really amazing. I went through it. It is the most in-depth work I've ever seen. I felt like, "What am I going to ask about today?" But there are a few questions both on and around the book that I wanted to unpack with you, so we can get to it. Maybe start with, how did you get from a blog post to a book? When did you decide to write a book? Was there a moment?

Andrew Harmel-Law: So, it's a good question. So, I think I'd wanted to write a book for a long time and I've been annoying O'Reilly people. So, I got feedback from various people who know better that I should have spoken to multiple publishers, but I'd wanted since I started working in IT, at Sun Microsystems years and years ago before the 2000 kind of dot-com boom, I saw O'Reilly books and I was like, "I want an animal book." So, I'd been annoying O'Reilly people at conferences, the people who run the book stalls and stuff because they're the marketing people. I'd been asking them how to write a book. So, they told me to kind of send emails to these people. So, I pitched a few books, and then meanwhile, we can maybe talk about this, I'd been getting frustrated with how me doing my job as an architect, was beginning to get in the way more and more and not necessarily kind of... In the old days, it would kind of make stuff better and make everything work better and I was realising that me doing my job was actually slowing everyone down. So, in COVID, I was really lucky to work with a client who allowed me to do a bunch of experiments and they're named in the book.

Actually, Pete Hunter, who was the person I paired with at the client, we basically tried a bunch of stuff and a bunch of experiments and it really worked. So, then I got told by the delivery principal, who's like the chief kind of delivery person, Thoughtworks person, Mel Mitchell said, "You need to write this up." So, I wrote it as a blog post, which Martin Fowler put in his blog. But then I kept getting asked questions about it and I kept trying to do lots of different things and try it with different clients and other Thoughtworkers would try it with different clients and then people like yourself, Sonya Natanzon, right? Because it was on the internet, people could try it. So, then it became, and then I was like, "This might be a book." So, one of the three books I pitched to O'Reilly, two of them I thought were terrible ideas, but this was the one I thought was quite a good idea. So, then it became the book and then it took nearly two years to write. So, you said it's very in-depth. I think O'Reilly would call it slightly too long and there was a lot that got cut out because I had a lot of opinions. So, to the staff.

Sonya Natanzon: Wow. I don't know, two years to write a book seems about the right time frame for me...

Andrew Harmel-Law: It's quite a thought. 

Sonya Natanzon: ...but then again I've never done one and it is very, very in-depth. There is a lot there, as you just said. So, if I were to ask you to extract the most important idea from a book, what would it be?

Andrew Harmel-Law: So, I think I realized it was important, but I didn't realize how important and I realized it's important because there's a certain thing that needs to be in place for this to work and the thing is trust. And so trust is kind of spread throughout the book. And so I kind of knew that, but what was cool about writing the book and is cool about being edited, so O'Reilly gave me an editor, Rita. So, I'd write something and then Rita would say, "Well, we need to kind of structure this and that you seem to be talking about trust, but you seem to be talking about a social contract where everybody, you know, we all agree to let everyone work in this way, as long as we agree to support." You know, we agree to work in a trustworthy way and therefore everyone else agrees to work in a trustworthy way too. And then I was in the later chapters and it was all about transparency and kind of helping trust. And then even later it was about, like, working with variability. And so like I kind of was wrestling with the fact that actually you can't be right.

There is no right answer to a software decision. It's like you've just got to do your best and then trust it and then test it as soon as possible and then you'll get feedback. So, all that came in. And then I was speaking to people like Diana Montalian and then Diana was like, "That's fine for like a White person." You know, a male presenting, White person to say all of these things. But what if you're not, right? You know, and then all these things. So, then I was all of this stuff kind of got baked in, which was like, maybe some people are trusted more than others, maybe some, you know, grey-haired actually white person. And I became aware of all of these things. That's where lots of the stuff in the book comes from. But fundamentally, it's all about trust. If you trust each other and there's lots about how to build trust and to learn to trust each other, then it works. And that's kind of the central thing. And so there's lots of ways you could fail. So, that's in the book, too, right? Things to watch out for, so…

Recommended talk: Navigating Complexity with Systems Thinking • Diana Montalion & Andrew Harmel-Law • GOTO 2024

Evolving Architectural Decision-Making: Experimentation and Collaboration

Sonya Natanzon: I'm going to pin that trust question and talk about it a little bit more later, how you get to that really good balance of trust and accountability. But I wanted to come back to the experiments that you ran before you came up with the idea of writing a book about it. As you were writing, as you're thinking about architectural decision-making change, that all post those experiments, and if it did, how did it change?

Andrew Harmel-Law: This is a really great question. So, I think there used to be a lot of footnotes in the book and many of them got taken out because my page count was too high. But one of the ones that survived, I used to be... One of the things that triggered this book was I would go in and I would be being paid to be the architect. So, I was working in Norway before COVID happened. And so one of my jobs there was kind of to go in and do lots of architecture and to kind of tell people what to do, tell people what the architecture was. And so I would try and collaborate with them and kind of be like a hands-on architect. But fundamentally, it was me that was deciding. But I was working with a product manager, a Thought worker who now isn't a Thoughtworks anymore, but a product manager called Monira Rhaimi. And I would say things very definitely and sound like I knew what I was talking about. Monira would just go, "How do you know?" Which is a classic, you know, like it sounds good, but you don't know, right? You haven't tested it. You haven't seen if this will happen when it makes contact with the code or with the customer base or with the expected load.

Like, all of these things, you're just guessing. And I was like, "Oh, crikey, that's interesting." So, that was very interesting. And then, meanwhile, James Lewis kept telling me to read Don Reinertson's, "The Principles of Product Development Flow," which is amazing, and more people should read it. But it's quite thick. But interestingly, you realize underneath, underpinning all of that stuff is a lot of stuff about making decisions and driving products. But if you add the word architecture in front of a decision, it all completely makes perfect sense. So, you could... So, I just looked at that and read through that all the time. And so that led to my kind of understanding about the decisions, the phrase which there was debate about whether it should stay in the book, but it comes directly from Don Reinertson is, "Fast and wrong is better than slow and correct." So, as I think, then I then say, "This is probably triggering to, you know...

Because software architects, we spend ages thinking, trying to get the right answer. But when you study, you know, the principles of complex systems and all of this kind of stuff and flow and feedback. There's so much going on in software architecture these days that the far bigger enemy of software architecture is taking a long time to think really hard and find that. Even if you get the right answer, maybe it took you three months when you could have tried three bad things really fast, learned, and then got to the same place faster, right? So, that, you know, being able to then split up decisions to understand the relationships between decisions, my relationship with decisions, and how that plays into architecture became super interesting. Then I reread bits of "A Pattern of Language" by Christopher Alexander. And then in there, there's a whole thing about relationships between patterns, which also works for decisions. And then I reread the blog post that Michael Nygard wrote, which kind of introduced ADRs (Architectural Decision Records), which was a big part of the book.

And I hadn't realized there's a single sentence where Michael Nygard says, "The consequences of one decision are frequently the context of the next decision." So, I was realizing that there were all of these kinds of decisions that were sitting within each other and inside each other. So, all of that, which I kind of half gut feel knew I had to think out loud, express it. Rita then had to tell me it wasn't clear and I'd have to rewrite it. So, it's quite a lot of rewriting, which nobody tells you about when you write your first book. Just to kind of get that down. And so my understanding of things has changed fundamentally. So, now I worry a lot less about whether it's correct or not. I worry, are the right people involved? So, we've got the right information. Is it as small as it could be so we can learn as rapidly as possible? And have we properly taken into consideration all of the things which kind of surround it? That for me is far more important than picking the right flavor of Kubernetes or something. So, there's...

Sonya Natanzon: Okay. Sounds like a lot of crystallization happened as you were doing...

Andrew Harmel-Law: Yes, of course.

Sonya Natanzon: ...the research. And the piece that I really relate to is the pairing with a product person. To me, for an architect, it's such a key pairing and it's almost a force multiplier. If an architect is paired with a great product person, you can question them meaningfully and say, "But what about this?"

Andrew Harmel-Law: Totally. There's another thing that it's in the book that Diana Montalian says, which is like, "Architecture is always it depends." The question is, what does it depend on? And lots of the time it's technical stuff, but sometimes we could have three technical, could be technical option A, B, or C. But then the product manager will be like, "But this maps to the product strategy, which isn't technical." That's like, okay, right? The product manager, if we collaborate with them, they can do it. So, now when I'm running this for clients, I like encouraging product managers to leave comments and advice on ADRs and stuff. Because you can frequently see them where they'd be like, "I like option A and B, but C will get us to my product goal faster." Really? Okay, that's cool. Let's do that. So, that's a superpower. It's amazing, so…

Recommended talk: Release It! • Michael Nygard & Trisha Gee • GOTO 2023

Decentralized Decision-Making: Characteristics, Challenges, and Success Factors

Sonya Natanzon: I want to talk about the organizations that have successfully moved to decentralized decision-making. And I am curious, what are the characteristics of those organizations that are able to make that leap? And you don't have to name names. I always like names but...

Andrew Harmel-Law: I can name two because they're like publicly... I'll let you finish. But, yes, I can name two.

Sonya Natanzon: Talk about those. I'm curious, what does success look like and what do you have to be in order to get to that success?

Andrew Harmel-Law: So, the first things that I thought would be necessary for success, but aren't. So, I thought to begin with, so this gets thrown at us a lot. There were two things actually. So, people go, "Yes, but you're Thoughtworks." So, that sounds a bit egotistical, but people like they go, "Yeah, but you're associated with good software engineering. So, therefore, do you need to be like this Thoughtworks type software engineer?" That's completely not the case. There's a quote, which I think I found to put in the book which is from Reed Hastings, who started Netflix. So, someone asked Reed Hastings, you know, "Where do you find all your awesome engineers?" And Reed Hastings said, "I hire the people who are upset, you know, like who are frustrated at your company," whoever the person asked him, and then get out of their way. So, fundamentally to this is, is that again, and it builds on trust. There almost every single person I've ever worked with is better than everyone thinks they are because they're not given the opportunity to ship code or, you know, to be involved in decisions or, and this is the next thing, to be able to fail and learn. So, that's the trust thing, but it's also safe, right?

So, it's important for diversity because you get diversity of opinions and diversity of thought, but it's just important for everyone, right? If you think you have to be right the first time, then you're not going to really be innovative. You're not really going to do the thing that's going to make a big deal. You know, you're going to take the safe option or you will take the safe option and still fail, but you won't be willing to admit that it's there. So, kind of key things that need to be there are kind of like enthusiasm, willingness to participate, and it doesn't need to be like a certain skill level. I've tried this with lots of different people and frequently what's exciting is you'll see junior people will start to kind of step up within an organization because they'll be like, "Well, I see this in the code all the time and it annoys me." And they'll maybe try and make a decision or they'll start providing advice against decisions that are happening. And so that's really good. The other thing is, it's like, so then there's a later chapter in the book about leadership. Because I realized there was one thing I was worried about and it turned out not to be true. I was worried that maybe this just happened because of my first force of personality.

So, I was there waving my hands around, but actively not deciding. So, I would be like, "I'm Facilitating," which is the title of the book. I'm facilitating your architecture, but I'm not doing it for you. So, my great fear was that maybe it was me dancing around and my enthusiasm, which was causing that. But then other Thought workers started doing it. And then even more excitingly, people like J.D. Carlson, who I met in an open space at the virtual DDD community, said to me, 'We're doing this." They completely arrived at a similar endpoint with all of the bits glued together from a slightly different angle. So, they didn't... You know, my book was just confirming what they'd already figured out. And that was super cool. So, they hadn't... From first principles, architecture is hard. We should decentralize it. We should optimize for feedback. We should make small decisions. We should get the right people involved. We should be safe and learn and stuff. They got to the same conclusion I had, but without knowing anything about my blog post or anything.

So, I was like, "Okay this is good." So, it's not a factor of my personality, but it does require leadership. But it requires leadership to kind of get out of the hierarchical position and then foster leadership in the small. And so leadership, for example, is stepping up and taking a decision. So, therefore, it's creating space for people to lead themselves. It's creating safety for failure. So, again, there's a thing in a Reed Hastings book. I think this one's "Powerful" by Patty McCord, who's the person who's responsible for co-writing the culture deck with Reed Hastings. Patty was like, "If you want to build safety, the easiest way to do it is to model fairly like acceptance and learning of failure from the top." Because people are always like, "It's okay if the top fails," because then they can pretend it didn't happen. So, there's a famous video of Reed Hastings admitting and explaining why it was spectacularly wrong to stop shipping DVDs and Netflix, which was a big thing at the time. So, that's all the criteria.

Then what's interesting is if you have all of that, then you'll end up with a learning organization. But you'll end up with a learning organization, which is learning with the architecture that you've got, with the products that you've got, with the skills that you've got, with everything that you've got, right? It won't be like some vanilla flavor that everybody does. It'll come together in the way that you need it. So, certain people teach other people, people will be able to admit when they don't know things and stuff. So, that all kind of comes together. And that's super cool. So, those are the things I've kind of seen. I've roamed quite wide on the answer. But all of those pieces, it's like if you put these little bits in place, then it turns out you can unlock this latent capability that Reed Hastings pointed out, that is already in many, many people. And then you just kind of get out of its way. And that, again, is why it's called facilitating software architecture. There's a lot in there that everybody has, but they don't know where to put it or where to express it. So, that's kind of the goal of all this stuff, so...

Sonya Natanzon: Wow. So, it does sound like it needs a catalyst. It needs a leader to make it happen. And in that, we're very much in agreement. I arrived some time ago at the idea that an architect's role is a leadership role, even though they may not have a position of power but they do. This is what they have to step into if they want to be successful.

Andrew Harmel-Law: Totally.

Sonya Natanzon: So, what about the opposite? Have you experienced an organization where you've brought these ideas into and it just fails spectacularly?

Andrew Harmel-Law: So, luckily, I haven't, because that would be quite dramatic. But I have this. I haven't introduced this on every single client I've worked with. And the thing that's fundamental, because I spent a lot of time because sometimes... Now, because of the books published people are coming to me going, "We're going to do this." And I'm like, "Well, I'm not sure." But there was one place where I have and where I did work and the trust wasn't there. And it wasn't, you know, because of the individuals. But it was just the way that the people who worked on the systems were structured and everything. It was set up so that there would be so much that would have to be changed. That trust, it was never going to be there. It was set up in an adversarial kind of hierarchical way. And so if I'd have tried this, it would have failed badly. And it could have been weaponized or, you know, there is this, again, based on Diana Montalian's feedback, you know, she's like, "You're still assuming everyone wants this to work. What if there are people who don't want to be like that?" So, I've got a talk I did at New Crafts last year about, like, the kind of the fact that the pressures of society and the societal systems impacts on your code.

There are people who've kind of built a career on knowing about a bunch of stuff, which keeps them in a job, for good reasons or bad reasons. And like Alberto Bandolini calls him a Dungeon Master or the famous blog post about big balls of mud, talks about swamp guides and stuff. And even if you think about the Phoenix Project, right? Brent, who's not a bad guy, but he's the person who knows, right? And everything has to go to Brent. So, if you're an architect working for that company, you need to speak to Brent because he would tell you how to get a product. So, not to say that these people are good or bad, but sometimes they're in a place and they can't let go of things. And so, you know, sometimes it's worth checking. What I have to know is the way to find out if you can start small. So, if you're an individual architect and you don't know how your organization will react. You can just start trying to do the advice process on your own. So, instead of just deciding arbitrarily, you can go and seek advice. So, the advice process is anyone can decide as long as they seek advice from people who are impacted, affected, and people who have expertise. So, you can model and say, "I'm doing the advice process. I'm still retaining the power to decide because that's how it works. But I'm seeking your advice. I want to know what you think."

Or you can be a team, which, you know, in a maybe traditional architecture organization, doesn't have the power to decide the responsibility and accountability for deciding still sits in an architect somewhere or at the review board. They can still prepare the decision, write the ADR, collect all the inputs, etc., etc. And then say, "We are recommending that you do this, that you take this decision, but we know we don't have any power." And then you can build up trust that way. The good thing is, again, channeling Monira, the product manager, if that's going to crash into your culture, you'll crash into it very fast. Don't do this. You can't make decisions. Stop, right? So, then you can fail fast. But if it works, then you can maybe do it in a team and then maybe do it in two teams. So, the last chapter is all about, like, don't go big bang. Start small, find out what your culture is, find out how you react and respond, etc., etc, because it is very simple to put, that there's two core elements.

The core elements are the advice process, which anyone can decide as long as they seek advice, and ADRs, which gives you transparency and history. Because in typical organizations that use the advice process, they're not deciding about software, so software moves fast. Everyone's working on it all at the same time, and it changes so quickly. You need to have a record. So, those are the two things I put together. Everything else is optional and you end up with other bits. But those are the two key things. And then how those bits fit in your organization will depend on your organization, right? So, again, it wound up on Rita a lot because I spent ages saying, "I'm not going to tell you how to do it." And Rita was like, "But this is a practical book. People want to be told what to do." And I'm like, "I can't tell them what to do because then they'll fail." So, there's a lot of me dancing around going, "This might be the thing. And, again, this is where all the words come from. Here are some criteria which will help you decide whether or not you need to adopt this additional practice, etc." So...

Sonya Natanzon: I think that's a really good approach. I tend to agree with Rita. A lot of these types of books, I want to read through them and I want to figure out how to apply it pretty quickly, otherwise, it's more of a thought experiment for me. So, it's good to have those with the caveats that this isn't dogma. Obviously, situations are different. Organizations are different. Pull out things that work for you. And here, the foundations that you definitely have to have and work out the rest. So, I love that approach. 

Recommended talk: How to Deal with Software Complexity • Gail Murphy & Charles Humble • GOTO 2024

The Transformative Power of Writing

Sonya Natanzon: So, you sound like you had some very interesting experiences, maybe some scars or stories. What is one story that you wanted to tell that's not in the book?

Andrew Harmel-Law: Not in the book. There's some really good ones that are in the book. There's ones where I thought I was right and it turned out I was wrong. And that's where Pete gets his biggest mention because Pete... So, I sound like a big advocate for this. I was, but until someone disagreed with me and then I was like, "Well, let's throw it out the window. They can decide whatever they want, but that seems like a really bad idea. So, I'm going to tell them to stop." And this is in the book, Pete went, "Well, if you do that, then immediately you've completely undermined... You know, you've destroyed... I would have destroyed the trust. So, something that's not in the book. I think, what's a good one? There's lots of little ones. The thing that's not in the book and I tried not to put in the book actually is. I've realized having written a book that the skill of writing, is not just a skill of, like, communicating, it's a thinking tool. And so there's lots of instances where me trying to write things down and trying to explain things and trying to understand things.

And it turns out it's what I've been doing for a long time. I just never realized it. By trying to write things down, you understand what the problem is or you understand you don't understand the problem, and then you can kind of clarify and crisp it up. So, there's lots of times, it's more than just one story, where I've been trying to understand something. And in the process of writing it down, then it's become a lot clearer. Or I've realized I'm stupid or whatever. And that's something which is kind of scattered throughout the book. But it's like I'm never... I think maybe I'm lucky because I work for clients and I've moved from domain to domain. I'm kind of allowed to be dumb because the client always knows more about their domain than me. But there's lots of stuff. I've done stuff in electric vehicles. I've done stuff in Bitcoin. Some Bitcoin I had no idea. Loads of stuff I just didn't know. But it's quite nice to be able to say, "Blah, blah, blah. You know, is this right?"

The other thing is I've learned that being an architect, whether you like it or not, even if you're not, you know, an old white person, with grey hair, people will trust what you say, even if you don't know. And so the other thing I've learned is it's very good to kind of put in place to say, "I don't know if this is correct, but... And then you will get it, because we work in software. Everyone loves to tell you that you're wrong. So, then you can trigger people into their kind of geek nerd. Well, actuallyness you can trigger that into getting them to help you write a better blog post or not blog post, ADR, sorry. Also, it does work for blog posts. And that's like if you can trigger but for the forces of good, not the forces of evil, like all of the kind of well actually ness of software engineering and architects, it's amazing. And then suddenly three or four or five, six people are writing this ADR and it's not just me. Again, I'm facilitating it as opposed to actually doing the work, so...

Sonya Natanzon: Yeah, there's so much truth in writing as a crystallizing activity and clearing things up. I think I need to bring you in to talk to engineering teams and say, "Pull things down. Write things down."

Andrew Harmel-Law: Yeah, write things down.

Recommended talk: Software Architecture for Developers Part 2/2 • Simon Brown & Stefan Tilkov • GOTO 2021

Balancing Decision-Making and Accountability in Software Architecture

Sonya Natanzon: They can't all be in your head. No, that's great. I want to submit a little bit of the advice process. And so it combines this fast, autocratic process of decision-making with a more decentralized consultative process. So, what do you do with the more authoritarian types, either overriding the decision or maybe the decider avoiding responsibility at the end of the day going, "No, I got bad advice."

Andrew Harmel-Law: So, that's a great question. So, the key thing is, and this is again, there's another book which I'd read, which has nothing to do with the advice process. But I realized when I was writing all of this stuff and trying to explain things that it became relevant. So, there's a book by Shoshana Zoboff, which is "The Age of Surveillance Capitalism." So, it's not about architecture. It's about how, the argument is like Google, etc. Kind of, you know, there's value in knowing what you spend time on and what you do. And so there's an argument that runs through Shoshana's book, which is that it's not just important to know who decides, but it's also important to know who decides, who decides. And so that's the key thing that flips everything. And there's bits about this in the book because I knew people would be like, "Wow, well, hold on." So, like you said, the decider can be autocratic. That's kind of the point. The person who's taking the decision, whoever's decided to take the decision, is obliged by the social contract, the trust, to seek the advice. But they can completely ignore it. They have to listen to it. And when you use ADRs, people write it down.

So, therefore, it's recorded as advice offered by, you know, this. I was going to decide because I'm the author of the ADR, right? So, it's me. I write the body of the ADR, I write the context, the title, the decision, and various options. But then below it, you keep the advice so you can see who I asked and what they said. So, on the advisor front, if I'm ignoring people, what is polite, because I'm British, what I advise in the book is like, if someone has offered advice, but you think you're going to ignore it, you should say, "Despite the fact that so and so recommended I did this, I'm still going to make this decision." So, then you're kind of taking responsibility for the fact that, you know, whatever. And it then drives people to get deeper into the advice to say, "Why does this?" You know, for example, I ask advice, for what programming language should we use? And someone says, "Don't use Java." If I go into Java and say, "Why do you think we shouldn't use Java?" And they can give me reasons. Then I can say in the ADR, "I'm ignoring this advice because that advice was about Java 8 and now Java is Java 21. And everything has changed. There's a new GCL alorithm it's not slow or blah, blah, blah," all this stuff.

So, it drives more detail, more context, and better decisions. Also, like, you said, the kind of check to the... Well, the fact that your name is on the authorship is aligned very much with the open groups' approach to architecture. So, they used to state that, you know, there should be an architectural group of people and those people should have responsibility and accountability for decisions. So, that's why it worked. But it was always a bottleneck because it would have to go through these named groups of people. In the Agile version of the open architecture framework, the OAA, they say as long as accountability and responsibility. So, like me taking the decision and me being accountable for the decision are in the same place, the same human being or team. That's fine. So, then you write it down in the ADR. So, a team can decide, but then they're responsible for it. Or an architect can decide, but they're responsible for it. And the fact you have this permanent record of, like, immutable ADRs, which is a trail of decisions.

I think the section in the book is called, "A Check to the Reckless," because I've yet to see someone take a completely reckless decision, knowing it was reckless or bad or it would have a big impact because they know that it's going to be there, right? Publicly on the intranet somewhere, intranet somewhere. So, if someone comes back and goes, "Who made this decision?" Well, it turns out it was Bob. Bob did this. You know, Bob wrote their name against it. So, that's good. But like you said on the other point, the autocrat thing, it is hard. And there is a whole chapter on, like, how to emotionally let go of things. And like I said, there's a story where I couldn't let go. So, the kind of the core story is, you're right. It is hard to watch a team potentially screwing up. But the point of that, my story there was they didn't screw up. I was wrong and they were right. And you can't see the future.

You don't know if you're right or wrong, like you said, Sonya, right? Till you've coded it up, you put it into prod and you've learned from feedback. So, you can't tell, right? So, learning that and going on this journey as a person who used to have power, who is beginning to share that power, or the opposite journey, which is someone who isn't used to it. So, now we need to take more, you know, care about their steps and, you know, think about the consequences of things. Both of those are baked in. But it is a journey, right? Again, that's where trust has to... Like, you will start with probably an organization in most organizations that is capable of trust. But the way we organize this means it isn't there. So, you slowly build it up. You do one team at a time or whatever. And then you'll see it evolve, which is cool.

Recommended talk: How to Stop Testing & Break Your Code Base • Clare Sudbery • GOTO 2022

Harnessing Reframing and Bias Awareness for Better Decisions in Software Architecture

Sonya Natanzon: Wow, I think Journey really does describe that. Shifting gears a little bit. So, I love all the conversation about biases, especially the framing effect. This was actually one that I learned from one of the best bosses that I had who said time and time again, "Don't let a good crisis go to waste." Originally, I was like, "What does that mean?" And then I realized, "Yeah, this can always be an opportunity. How do I take that as an opportunity and use it?" What were some of the dramatic perception shifts that you've observed due to framing bias in reframing things for people?

Andrew Harmel-Law: So, I think, one I've already mentioned, actually, is a really good question. One is the architects that you need to make the best. Like, I get this. This is a talk I'm going to rewind. I'm going to write a talk this year called "How to Make the Perfect Decision," (there is no perfect decision). Because I don't know, maybe it's because of love, so I say in the book, I'm autistic. So, I'm very aware that certain people of certain types drift towards software because it's very ones and zeros. It's binary. You know, it's like the code compiles or it doesn't. It runs in the product or doesn't. But that seems to have spread into the complex socio-technical world where we just think that because we can control the small things, we assume we can kind of be right and correct about the bigger stuff. And I don't think it ever was, but it might have been more possible to be correct in the past. But now with microservices, the cloud, loads of stuff is not in our control. But I still think lots of us labor under the fact that we can think really hard. And if we think really hard, we'll be right. And then it'll work.

And that's the biggest shift, which then goes small and fast is better than... Sorry, fast and wrong is better than slow and correct. That's big. Like, people do get triggered by that sentence. And like I say, quite a few of my colleagues get triggered by that sentence. But it's really, really true. And then it focuses your architecture because you... So, then you get this kind of knock-on effect of big realizations and framings. So, you learn, if that's good, then you're like, "Okay, cool. So, we should optimize for flow, which means we should architect for flow, which also means we should optimize for smaller decisions." So, you architect for smaller decisions. And just if you the triggering thing being it doesn't matter if I'm wrong, but as long as I'm learning and I'm optimizing for learning and finding and evolving and, you know, like I know from having chatting to Neal Ford, there's a bit in the book again about the evolution of systems, right?

Because even if we design it, even if we're very, very good and we design everything right and it's perfect, it'll only be perfect for six months or three months. You know what I mean? Then something will happen and it'll be wrong. And we'll need to change things. So, that kind of cascade of framing changes and things. And then watching how that changes, how people think about teams, about how the organization is structured. So, I've seen there's another mention in the book about Vanessa Formicola, one of my ex-colleagues, she has social decision records. So, if a team is deciding that it needs to change which bits of the Micro service it owns, they were like, "Why can't we also decide whether we split as a team? You know, we don't need to wait for someone else to do that, right? We'll do that ourselves." So, then she's brought in this kind of idea. And there's a blog post which is linked to from the book again, which is like, "Well, let's just, you know, start doing that."

And that's the kind of stuff that Matthew Skelton and co- author Manuel Pais and teams are beginning to talk about now, right? Trond Hjorteland is talking about it too. If you're designing the system, it's a socio-technical system, right? It's not just a technical system. So, slowly the edges kind of blur and stuff, and people are like, "It shouldn't be someone else." Like, I've got loads of these good quotes, but Michael Nygaard said, "Your HR department does the first draft of your architecture because of Conway's Law." And he's right. But why can't you do the second draft, right? Like, it's just a human being who said that you're in this team and you're in that team. So, you're a human being. So, to make a decision based on good rational thought and propose it to whoever can decide, right? So...

Sonya Natanzon: I think this is the ultimate in self-organizing teams and a lot of what Agile has, I think, originally intended. Unfortunately, there are times that I've encountered where people actually don't give it much thought, engineers don't give it much thought. I think the biggest example of this I've seen is somebody telling me, "Well, it's really arbitrary and not really critical which team I'm on." And I thought, "No...

Andrew Harmel-Law: No.

Sonya Natanzon: ...it's very, very critical."

Andrew Harmel-Law: Especially, yeah, if they start to realize that they can, then you're like, "Okay." And then some people don't care. They just like being told what... You know, not told what to do, but they like someone... I think, again, as in the book, it's like you're not obliged to decide. You just have the opportunity. So, not everybody can do architecture. It's anybody who thinks they want to. Some people are happy. They go where they turn up. They get given a user story they build and they like running their code. But other people are kind of pushing. They're like, "No, but I've got that. I don't agree." That's wrong. We can make this better, which is a very, again, software engineer, architect type thing, right? And if you can give them this measured, careful way of doing it, you can. Those people who are always more than... Like, I'm always surprised like the people, you think that person's definitely going to have opinions. But there are people who are just below the surface who also have opinions. And then when they step up, then people below them are like, "That person, I have an opinion, too. Maybe I'll... This is why I love doing it. It's super cool and I get to do it for lots of clients. You'll see these people kind of emerge. It's very, very exciting.

Recommended talk: Insights on How Team Topologies Drive Organizational Success • Manuel Pais • GOTO 2024

Psychological Safety and Accountability in Decentralized Decision-Making

Sonya Natanzon: Well, I'll ask one last question and I'll talk about, we'll switch to psychological safety. You talk about that a lot for those... How important it is for those that are gaining power and decision-making, for those that are losing power, giving up power and decision-making in this decentralized system. So, how do you balance creating this type of psychological safety for everybody? But balancing that with accountability, especially when decisions have big consequences, which in decisions with very big consequences.

Andrew Harmel-Law: It's a good point. So, I mean, this is what kind of... Again, that's another cool thing about this approach, because... So, there was a client where I did this and they were like, "That's fine, but everyone will talk, but nobody will want to kind of make the decision, right?" So, they just thought it would become a talking shop. And it was a very valid criticism, which I was quite concerned would actually turn out to be true. But the reason it didn't is because and again, it might be product management, or it's just generally the organization of the business. There's a force which is behind which is like we need to build the thing. We need to make the decision. You know, the software needs to evolve or be updated or whatever. So, that kind of like pulling force, which is the same force. You know, it's not just a kind of pulling and, you know, you need to ship a product or whatever. But even if you're not, even if you're just maintaining stuff, there's a force that Simon Wardley kind of identifies and it's even there actually in Christopher Alexander.

Those things because you're living in them and they're existing in the world, they're changing, right? So, even if your thing is stable, you're still in a very slowly moving conveyor belt, right? So, if you're on Java 8, you're on Java 8. If you do nothing in 5, 10 years time, you're on Java 8, which is not the same as being on Java 24 or something like that. So, there is this force that's pulling things along. And so psychological safety is important. Like, you want people to have all these kinds of things, but it's safe in the context of building a product and maintaining a product and kind of like, I don't know how to write this book, but I keep trying to convince other people to write this book. There's something around like existing in some... This had to get cut from the book, but there was loads of stuff in Christopher Alexander's book about you build, you design, you use architecture patterns, right? You build a house, but then the house evolves and grows and changes and stuff based on the people who live in it, right?

So, rather than architects, I think we're like people, especially developers, and architects, but especially developers. We live in the code base, right? So, we are trying to make that more habitable and kind of evolve it and grow it as tools grow. And like, you know, in a house, there might be a new way of, like, tiling your floor or heating your home or whatever, right? So, you would want to kind of bring those things in. With us, there might be a new way to do deployment or a new way to test something or, you know, a new feature in an updated version of the language. Those things would kind of come in and bring stuff up. So, that plus the psychological safety to make, maximized the sensory area, right? You want as many people in the team to be able to think as creatively as possible, to be aware of those things, right? And to bring them in and to say, "I'd like to think about this." And I talk a little bit about the safe way of bringing things in as a spike, right? So, the spike is like an ADR before it's an ADR. You want people to experiment and learn and fiddle around and try things based on making their part of the system hospitable.

So, I think if you have that and you nurture that and you're like you're looking out for, how many different people are proposing ADRs? What is the type? Where is the level of ADRs? Are they small? Are they big? Are they blah, blah, blah? All this kind of stuff. Then you can kind of look out for it and then you can support it when you see it. So, you'll see people, maybe a little person, not a little person, but a person in a team, which, you know, this isn't going to change the face of the product, but they've got an idea to do a thing. Nurturing that is as important as nurturing the big decision from the big person, you know, the important team. Because people then realize that it's their code base as opposed to a code base that they're just renting or something and their product, etc., etc. So, it makes a big difference, so...

Sonya Natanzon: All right. Well, thank you for this. It has been amazing to talk to you. It's...

Andrew Harmel-Law: It's been a lot. 

Sonya Natanzon: ...I learned a lot from the book. This conversation had just added so much color to this. I really appreciate the time.

Andrew Harmel-Law: The questions were amazing as well. So, thank you very much for it.

Sonya Natanzon: All right.

Andrew Harmel-Law: It was lovely to speak about it.

Sonya Natanzon: Awesome. Thank you.

Andrew Harmel-Law: Thank you. Cheers.