In this podcast Shane Hastie, Lead Editor for Culture & Methods spoke to Elisabeth Hendrickson and Joel Tosi about systems thinking as a lens for software delivery, the cultural "levers" leaders and teams can pull to shape organizations, and building thriving, sustainable teams amid AI-driven change.
Key Takeaways
- Systems thinking treats organizations as non-linear, adaptive systems, when you poke the system anywhere it will poke back somewhere else.
- Culture changes through two kinds of levers: policy, which only leadership can set, and cultural "feeding," which everyone influences just by how they show up.
- Real change starts with seeing how work actually happens, not how leaders imagine it happens from a dashboard.
- What actions to take depends on context, and as software is a function of an adaptive system, context is continuously changing. Right today can be wrong tomorrow.
- Building a thriving organization is constant care and course-correction, not a single fix - and sometimes the "unfun" work of clearing real problems matters more than fun activities that paper over them.
Subscribe on:
Transcript
Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today, I have the great privilege and pleasure of getting back together with a couple of people that I've known now for quite a few years, Elisabeth Hendrickson and Joel Tosi. Elisabeth, Joel, thank you. Great to see you both, and thank you for coming back onto the podcast.
Elisabeth Hendrickson: Oh, thank you so much. It is so good to see you.
Joel Tosi: Thanks for having us.
Shane Hastie: As I said, we know each other, but there will be at least one person in the audience who might not have heard of the two of you. Elisabeth, let's start with you. Who is Elisabeth?
Who Is Elisabeth Hendrickson? [01:00]
Elisabeth Hendrickson: Well, that's a great question, and I never know how to answer that, but I've been kicking around the industry, call it, since 1989 when I got my first full-time job, '88. Oh wow, what is time? I don't know what time is. Anyway, been kicking around the industry for quite a while. If people do know me, they probably know me as test obsessed. I wrote a book called Explore It! and I've also, within the last 10 years, been doing more from an executive standpoint, engineering leadership.
Shane Hastie: Joel, who's Joel?
Who Is Joel Tosi? [01:33]
Joel Tosi: Yes, thanks. Been on the industry for about 25, 26 years. Most of my chops came from building products throughout the years and in an architecture, did a bunch of time, mean that lovingly, of course, with Red Hat and architecture and low latency, high throughput systems. Last time we chatted, Shane, we were talking about some of the other books I had put out around dojos, in essence, really just helping teams learn. Spent a lot of time in that space, and then really just focusing on helping organizations build cool products and make it better for people, just make it better for people to enjoy their job because creating should be fun.
Creating an Environment Where Creating Is Fun [02:11]
Shane Hastie: Creating should be fun and engineering leadership. How do engineering leaders create an environment where creating is fun?
Elisabeth Hendrickson: You don't believe in small questions, do you? Let's just take the highest level answer that I can offer, which is treat them with dignity and respect and like the adults that they are. That is the most important thing that leadership can do, and it's really about what they're not doing. Don't hire really smart people and then try to micromanage them and tell them exactly what to do. It won't go badly.
Joel Tosi: Look, I love that. Elisabeth and I talk about this quite a bit. We're of the same opinion that I don't think any managers or executives or anybody is ever doing anything intentionally to harm their employees. You think about a lot of executives that are shipping software, and my hypothesis, and I'm sure Elisabeth would agree, is that they're stressed about shipping software. They want to be more creative, they want to be better in the marketplace, and they see their teams struggling with that, and so they want to help them. Now, sometimes what happens is they help them in ways that the teams don't want to be helped. And that's I think the nice way of putting it, but the intentions are there. The intentions are true and honest. The challenge is they're just not seeing what's making it hard for the teams. And so they want to help, but they help in non-helpful ways.
Elisabeth Hendrickson: Jerry Weinberg called that inflicting help.
Shane Hastie: Inflicting help.
Elisabeth Hendrickson: Yes.
What Is Systems Thinking? [03:45]
Shane Hastie: The late great Jerry Weinberg. So this does segue us a little bit into, I happen to know that the two of you have written a book that is all about systems thinking. What's systems thinking and why does systems thinking matter?
Elisabeth Hendrickson: You asked what is systems thinking? And I view it as the recognition that the systems that we live within are non-linear adaptive systems. You poke the system, the system is going to poke back. Reality is not something that you can control tightly. And more specifically, as we look at software delivery, it is an incredibly complex interwoven web of influences. People are a huge part of that. And as I like to say, people are hard and I also am a person, therefore I know that I am part of it. I am also difficult, but people are a huge part. That's the socio part of the sociotechnical system. And then from technology standpoint, we ship software that depends on software that other people wrote who are within the company, that depends on infrastructure that is managed by the company, but also probably depends on software that was written by communities, open source software, by other vendors.
So there's this massively complex interwoven collection of interdependent parts. And systems thinking says that the system, the whole is greater than the sum of those parts. It is not divisible. As soon as you take out part of the system, it is now a different system that will have its own set of behaviors because the behavior is emergent and it's systems all the way up and down. So you think about your organization, maybe you're on a team, that team is a system, that team exists within a department, that department is a system, that department exists within a business unit, which is itself a system. The business unit is part of the company. The company is a system. The company participates in an entire ecosystem with other competitors and suppliers and customers, et cetera. It is systems all the way up and down the chain, and it is super hard to reason about.
Systems Are Constantly Adapting [06:01]
Joel Tosi: The only thing I would add to that is the, maybe you missed it or you touched on it Elisabeth, I missed the adaptive aspect of it is that it's systems all the way up and down and they're also constantly adapting. So at the macro level, your organization is constantly adapting to its competitors and regulations and changes in the world and your employees are constantly adapting to new demands on the team as well as new employees in the team and as well as new technology. So it's constantly adapting. And so the need for systems thinking is with all of this happening, how do we possibly reason about it in a way that is, I would say more intentional and less, maybe I want to say less accidental because again, I think people are doing things with the best intentions, but sometimes I don't think they are understanding all of these interdependencies.
And so that's where systems thinking comes in is helping us reason through all this.
AI Rollouts and the Limits of Linear Thinking [06:53]
Elisabeth Hendrickson: It's so tempting to want to see a system and reason about it linearly. Well, I mean, so many organizations today are doing AI rollouts. We're going to become AI native. It's the new transformation. Shane, when you and I met 20 years ago, we were doing agile and agile transformations were the thing. Now it's AI transformations becoming AI native. And it's so tempting to say, all right, well, we're going to run this like a linear program. We're going to choose the tool, we're going to roll it out, and then we're going to get value. And weirdly, that's just not exactly what's happening in a lot of organizations because it is not something where you can think linearly cause and effect, "I do this, I give the input, therefore I get this output."
You poke the system, the system's going to poke back. And in the case of AI, which is why I think systems thinking is needed now more than ever because every organization is going through massive shifts as they try to figure out what does this mean for us and how are we going to grapple with this?
And for organizations that are trying to do a huge rollout and throwing tokens at it, but not necessarily getting the final outcomes that they want, one thing that I see over and over again is they're getting a lot more output than they ever got before and the rest of the system is not prepared to deal with it. AI is an amplifier. It's amplifying one part of the system more than the other parts of the system. And now suddenly it's not so much that it moved the bottleneck necessarily, but it is exposing bottlenecks and constraints that weren't really a problem before.
That was a lot of words. You just asked us what a system is. I hope we successfully explained because it is a little bit complicated to explain given that the whole point is you can't think linearly, cause effect, you have to understand the larger picture.
More Code, More Bugs: AI as an Amplifier [08:50]
Shane Hastie: One former guest on the podcast was talking about a study that they'd done where they found across their customer base, the adoption of AI coding was resulting in about 300% more code and 400% more bugs.
Joel Tosi: I have a group I was working with this morning and I'm talking with the tech lead and the tech lead says, "Can you look at this PR for me?" And I was like, "Oh, yes, sure. I'll look at this PR." And I pulled it up and I'm starting to read it and then I'm scrolling and I'm scrolling and I'm scrolling and for a minute I look at the nav bar and I'm maybe 2% through. I'm like, "How did this PR happen?" Because then I step back and it's like 27,000 lines were changed across 104 files. And he's like, "How do I PR this?" I go, "You don't. You can't. It's not possible, but I have to because I'm the tech lead." Wow. Again, it's a systems problem. Somebody amplified something like Elisabeth said, and now it's created a problem somewhere else.
Shane Hastie: This is the Engineering Culture Podcast. What are the culture elements that we can, I'm going to use the term you use in the book, the levers we can pull that help us to be better at systems thinking?
Defining Culture: The Unwritten Rules [10:12]
Elisabeth Hendrickson: I think it's important to first talk about what culture is because it's kind of squishy. What is culture? And one of my favorite definitions that I found as we were doing research for the book, and I'm going to beg forgiveness of your audience because I don't actually remember and I'm not going to go look it up right now to attribute it properly, but the definition that culture is the unwritten rules, it's the things we don't talk about, the assumptions that we can safely make because we share a culture. And then there are a bunch of hallmarks of culture, things like shared language and shared sense of humor and origin stories and rituals. These are all the things that help inform you. If you were an anthropologist, these would inform you about what the culture is because nobody ever talks about the culture, so how do you study it?
But if these are the hallmarks of it, but the culture itself is the unwritten rules, then how do you find the levers on something that isn't discussed and where it's not even captured and written down? And yet it turns out that you actually can intentionally shape culture. So the way that Joel and I see it, any choice that you can make that affects the system is an example of a lever. And there are two giant buckets of levers. There are categories of levers. There's policy. So if you're in leadership, you have the ability to set policy and policy is anything that requires that mantle of leadership. You can say, "What is our hiring criteria?" You can say, "What is this job description?" It is an example of policy to set the structure of the organization. So those are all policy things. Culture levers though, that's the other big category of levers, cultural levers.
And it pretty much, in my mind, it boils down to feed what you want to grow because when it comes to culture, you cannot dictate it. That's policy. Policy, you can say what it is, but culture, all you can do is shape it. I mean, at the very beginning of this conversation, you asked, how does a leader create an environment in which people can have fun? And that's an example of a shaping question. What do you do to shape the culture? And as a leader, you have so many opportunities to feed, but everyone does. That's a thing. Everyone can influence culture. You do just by showing up, whether you meant to or not, you influence the culture. And an example of feeding is just expressing appreciation. When somebody does something and you express appreciation, mostly you're feeding it. There are occasionally you'll meet people who, as soon as you pay attention to a thing, feel like they're being penalized because they just don't want anybody to pay attention, but that is so rare.
So usually if you just express appreciation, thank you so much for that great pull request that was so small and tight and easy to review, that is expressing appreciation, you're feeding what you want to grow.
Feeding What You Want to Grow [13:28]
Joel Tosi: I love that. The other examples I see in a lot of teams, it might sound small, but I know a lot of teams, especially if they're doing agile practices, they might say, "I'm stuck on this. Who can help me?" And in essence, asking for help. Another way of reframing it though, if you want to, instead of waiting until I'm stuck, you could always reframe it and say, "I would like to work with Elisabeth on this today because I like to see what she sees." And all of a sudden you're feeding what you want to grow, you're feeding that you want to be together to understand problems together as opposed to we work individually until it gets bad and then we come together. We talk about small little nudges, little levers that everybody can reach and everybody can pull. I think that's a beautiful example. I think the reframing and how we ask questions, I've had teams that do demos where it's just like they show the product, they show the product.
If you invert that and instead of showing it, you kind of tell a story about the product and ask the people to try it and see what kind of bumps they hit. Now you're feeding a curious and an innovative culture versus one that just provides a status. And so it's these little things that you can do to feed and nudge the culture along, we can all access them.
Where to Start: Seeing Before Acting [14:36]
Shane Hastie: Lots of little nudges, lots of little things that we can identify. Where do I start?
Elisabeth Hendrickson: I think you start with seeing, but I think it also depends on what exactly you're trying to do. But everything starts with seeing, and that's the part of signals and levers, because you really are going to struggle to affect change in a system where you have no idea how the system functions. And so getting a better read on what's actually real. And for leaders, the problem often is that they have an idea of what work looks like, but not the hands on the keyboard visceral experience of it in that organization at that time. For example, a lot of leaders might have been hands on the keyboard writing code five years ago in a different company, and now they're leading an organization, maybe they're a developer, they self-identify as a developer, they think they know what the work looks like, but they don't know the extent to which there is a tiff going on between Billy Joe Bob in ops who is resisting every single thing.
They don't have the visceral sense of what it's like to try to get work done or the fact that the engineer's job has turned into a YAML developer as opposed to writing code or what it looks like to get Claude to work in that environment, whatever it is. They're dealing with work as imagined as opposed to work as experienced or work as done. So it starts with seeing, actually understanding, not imagining what is true. Observing is the hardest thing in the world because to be able to see what's really there and not what you wish is there or are afraid is there or hope is there or expect to be there, really it starts with observing.
Taylorism and the Separation of Strategy and Execution [16:34]
Joel Tosi: I love that frame, Elisabeth. Before we started recording, Shane, you were talking about your, which I'm sure is going to be wonderful, your work and your class on modern management. You mentioned a little bit Taylorism. And I think what's interesting is when you think about seeing, please correct me if I' wrong, Shane, Taylor was very keen on the separation of strategy and execution. And so if you want to know where to start, you can't separate the two. You can't separate strategy and execution. And so Elisabeth is very keenly talking about seeing signals, but I think it's a little bit more than that. I think it's seeing the signals we're not used to seeing. And so plenty of executives, plenty of people that want to have change have dashboards, they have metrics, they have reports. They see the data that they want to see, but that's not the only signals that are happening.
If you look at the dashboard of the velocity and you see something around the team and their shipping, but you don't understand why it's so volatile. Well, when you go there and you actually see the team and you see that, well, there's lots of misunderstanding on requirements. Well, why is there misunderstanding on requirements? Well, the architecture didn't support the product the way it wanted to be done. Why didn't the architecture support the product the way it wanted to be done? Well, the architecture was designed five years ago when we were trying to do something different.
And so now you start to see different signals that you don't see in dashboards. And so coming back to the... I love the question. I love Elisabeth saying seeing, but it comes back to you can't separate strategy and execution. You got to see and be there to see the signals that aren't showing up in your reports.
Seeing Without Becoming a Micromanager [18:06]
Shane Hastie: How do you do this without being a micromanager or without coming across as a micromanager?
Joel Tosi: Elisabeth alluded to culture as one of those big levers. If you're in a culture that has a lot of fear, it's going to be really hard. It's going to be hard to hop in and say, "I'm not judging you all. I just want to see how it works and for the team members not to clam up." So for me, it's going to start with influencing the culture so that these things can become more true. Now, if you're in an organization where you're able to pair or hop in with a team, sometimes maybe you're hopping with demos and asking teams, "Instead of telling me how the software was built and what the software did today, help me understand what was surprising to you about building the software." Sometimes it's those little nudges around the questions and you start influencing the culture so that you ask, "Hey, can I stop in one day?" Because it sounded like when you were working on that microservice, you had a big discovery and I'd like to understand how that discovery happened because we want to spread the goodness to more teams.
So sometimes if you're a leadership and you're in an unsafe space, it's about creating those nudges so you can get there. If you're in a safe space, then you can see.
Signals Don't Always Mean Pull the Lever [19:20]
Elisabeth Hendrickson: I would add that I also think just because you are getting signals, that does not mean that you need to start pulling levers.
Joel Tosi: Yes.
Elisabeth Hendrickson: So the choice of when and how you start pulling levers, that to me is what makes the big difference between a well-informed manager who is making the appropriate decisions for their role, but doing so with a much better sense of awareness. So for example, not committing to things that they have no business committing to because they are imagining how long it should take rather than having a sense of how long it actually takes to do things. But just because you got information doesn't mean that you necessarily should start yanking levers. You want to be very mindful of which levers you start pulling on and whether or not that's your lever or that's somebody else's and you should let them do their job.
Joel Tosi: Whether it's not your lever I think is interesting, but there's also an interesting pattern you could observe where even if an executive or a leader that wants to help can see patterns without being in a team. And so the things I think about is when we're in a "microservice environment" where all the teams are autonomous and everybody ships on their own, except they're not really autonomous because they have to follow the same process and they're not really on their own because the customer experience goes across all the microservices. But putting that part aside, what happens in a lot of organizations is you start to see when the problems come in, the hop around. I thought it was this service, but then it had to go to that service, but then it was the DBA. It turned out it was DNS because it's always DNS.
And so as an executive, instead of trying to say, "Why did that outage happen?" You could start harvesting patterns and you could start thinking things like, "We seem to be having a hop around problem. That hop around problem probably isn't going to be solved by more meetings. It's not going to be solved by more policy. It's not going to be solved by me saying you better have better monitoring. There's something else happening inside here." And so if that's a problem, there's probably other problems because it's a system. So I think that you can still do some kind of harvesting there as well.
How Individual Contributors Can Raise a Red Flag [21:26]
Shane Hastie: If I'm a member of the team, so stepping into the team, I'm deeply embedded in that system. When I notice something that's not quite right, I need a lever pool, how do I raise this or do I just go ahead and pull a lever?
Elisabeth Hendrickson: So a couple things. One is everyone is deeply in the system. So you said, "I'm an IC, I am deeply embedded in the system." The thing is literally everyone is deeply embedded in the system. That is the nature of systems. They may be in a different part of the system and therefore see different things, but everyone's deeply embedded. But the second thing that you're raising, I think that it depends so much on the context for that specific. So here's an individual, they're on a team, they live within a context. That team has a whole context. The team itself is living within the larger system, which itself has its own context. And consultants always say it depends.
And the important thing is it depends on what, right? And it depends on the context. Okay, so if I'm that individual contributor, how do I ask for help from leadership? I need a lever pulled. How do I ask for help? How do I raise a red flag? How do I make sure that I am not going to get shot as the messenger just because I'm saying something that they don't want to hear? And that is so dependent on the culture within the organization and on the nature of the work within that organization, the nature of the specific piece of information, the red flag, the whatever, the consequences of not paying attention to that.
Red Flags: The Skyscraper and the Tacoma Narrows Bridge [23:05]
There's a case here, and now I'm trying to remember which city it's in. It's this fascinating situation where apparently some work was done on a building, like a skyscraper. I wish I had the details, but whatever, it doesn't matter, like skyscraper. And one worker noticed that there were cracks in a support pillar and raised it. And the first reaction was, "It's fine." But they're like, "No, no, this is not fine." And they persisted, and then they ended up having to get structural engineers in and determined that because some construction had added substantial weight and that resulted in this buckling because it wasn't designed to hold that level of weight, but this is the kind of red flag that in this case, this person is being celebrated.
But when we look at the Tacoma Narrows Bridge, which is one of the stories that we tell in the book, there were very clearly problems because even while it was still under construction, it got the nickname Galloping Gertie because when the winds blew through the Tacoma Narrows, that bridge would start just wobbling. And one of the news articles of the day basically dismissed all of the concerns about it said, "Well, they're going to look at things because people report that they're getting uncomfortable." Not, "We're going to look at things because the bridge might fall down," but sure enough, essentially, resonant frequency and the bridge went boom. These are two cases where it's construction, and in the Tacoma Narrows case, many people had been raising the red flag, but had been completely dismissed. And in this other case that was much more recent, now this person is being lauded for being persistent and getting things checked out.
What's the difference? Well, culture is a huge part of it. And so the question of how do I read the tea leaves on your culture, figure out, find a buddy, find an ally, somebody who you can trust to start having the conversations, see what you poked the system, the system's going to poke back, see what happens, and then figure out how to navigate it from there. And don't be shy about asking for the help that you need because asking for help is pulling a lever, and that's the lever you might not have the ability to authorize doubling the cloud spend or increasing the amount of the token quota or whatever it is that you need or getting that other organization over there to partner more effectively with you. You may not have the authority to do that, but you absolutely always have the authority to say what you need and raise that, and that is pulling a lever.
The Watermelon Project: Red Inside, Green Outside [25:45]
Joel Tosi: In the early days of some of my engineering, worked on trading systems without giving away too much information. There was a big initiative. The organization I was with was buying another financial trading platform, and so we had to merge data, and I was in charge of some of the data dissipation. I remember it was August, and somebody said to me, "Well, we need a status." This is 15, geez, 20 years ago. Back in those days, we did red, green, yellow status. Red means it was a problem. Yellow means there's risk, but it's going to be handled. Green means it's all good. It was August, I said, "The project is red." And I go, "Well, how could it possibly be red? You just started." And I go, "Can't access the data, don't know the formats, don't know any. There's too many unknowns." And I tell my manager this, my manager goes, "Okay, well, sounds like you identified the problems, so we're not going to say it's red.
We're going to say it's yellow." So my manager goes to his manager and says, "Hey, this is a big project. We have to have it done in January. What's the status?" Well, the status is it's yellow. And his manager gets very mad at my manager and says, "How could it possibly be yellow? What do you need?" And my manager says, "Well, we need access to the data." And his manager says, "Okay, I'm going to work on getting you the data, so let's say it's green." So now the reality is that we have nothing, we don't know what we're doing, but the status is being reported as all good, different kind of culture. Now, if you fast-forward to the end in January, what happened, we went live for an hour, and then we rolled everything back for two months because it was real, real bad. So to the point there, that culture is going to dictate what you can and can't do.
Shane Hastie: The classic watermelon project, green on the outside, red on the inside.
Elisabeth Hendrickson: Yes.
Building a Thriving Organization [27:41]
Shane Hastie: One of your chapters is building a thriving organization. It took me to learning organizations, but there's more there. How do we thrive?
Joel Tosi: For me, thriving is, we talked about in the very beginning there, it's creating should be fun. And so it starts with people enjoying their work, aligned around a common outcome, making people's lives better. That's kind of utopic and kind of fuzzy, because of course everybody would say, "That's great, Joel, but that's not the real world because you got to do work." Building a thriving culture for me is constantly looking at the signals around what we want to be as an organization and seeing when we deviate to understand what's causing the deviation and doing those nudges to get it back in place. I don't think it's a big process. I don't think it's a big edict. I think it's the constant care and feeding and attention to the system to make sure you're getting it where you want it to go collectively. Elisabeth, I'm sure you can make that much more crisper than I did.
Elisabeth Hendrickson: I doubt that I can, but I love that. Ultimately, what I want is that all of the people in the system are as healthy and happy as they can be within that system, that we're operating at a sustainable pace, we're not burning people out, we are treating them with dignity and respect. They feel a sense of satisfaction in a job well done and that we've created the conditions for that.
In order for that to be true, I do fundamentally believe that an organization has to be a learning organization. So I do think that it's part of it, Shane, to your point. And I think that there's so much that goes into being a learning organization, and Joel talked about harvesting information and that view of no matter what, we're going to learn from this and not in a punitive way, just genuinely in a, we are going to extract all the learning that we can in order to improve how we execute going forward.
I think that that is absolutely critical. And there's so many things that can impede that, like ego or fear, "How dare you be red? How dare you be yellow?" Those are fear words, but I wanted to come back to the people are happy and healthy thing because some Sometimes the things that you do to create a thriving organization don't in the short term make people comfortable or make people happy. And I remember in one case I was a leader in an organization where we had a fair bit of technical debt and the engineers just were frankly struggling with the code base and frustrated and every day felt like a slog. That sense of satisfaction of a job well done, they weren't getting enough of that because every day they would come in and fight a system that was actively fighting back against them and it wasn't fun.
When "Fun" Papers Over Real Problems [30:41]
And the team lead for one of the teams came to me and said, "We have to make fun into this because people are just not having fun." And then had this whole proposal for doing team building exercises and doing, I don't know, go-karts or whatever, but go have fun and to have mini hack days very frequently so that people could do fun things with the technology. And I shut it down and I did feel bad as a leader, but the point that I made and that ultimately we moved towards was, "Look, if it's not fun, we need to fix the sources of not fun instead of papering over it with a bunch of stuff that feels fun but isn't addressing the underlying problem because then it just becomes this toxic mess." And if you think about it in terms of systems thinking terms, the more time we spend on "fun," fun in bunny quotes, activities, the less time we have to address the underlying sources of pain, the more pain, the more we reach for fun and we're going to grind to a halt and it's not going to be good for anybody.
And so instead, let's talk about how we sequence paying down technical debt in order to optimize for getting to that place of satisfaction for a job well done, which might be a different sequence than we would do if we were optimizing for something else. If we were optimizing to mitigate risk, for example, we might end up with a completely different sequence than if we're optimizing to make people's jobs feel more purposeful rather than what do you do all day? I come in and I fight the YAML. It's not fun. I don't actually get to exercise the part of my brain that I want to be here for. I am just wading through what feels like terabytes of configuration to find the one place where somebody misspecified something.
Joel Tosi: The one missing tab.
Shane Hastie: Oh, yes. Semicolon in the wrong space.
Joel Tosi: There you go.
Elisabeth Hendrickson: Yes.
Shane Hastie: I've done that.
Elisabeth Hendrickson: So sometimes to build a thriving organization, we have to do things that don't feel like they're building a thriving organization as long as the trick, because sometimes we do that and then it turns out that we're just making people miserable for no good reason. And so the trick is to constantly be watching the signals. If we place a bet that if we optimize to make this better, do we then get the signals back that tell us that that got better and we should continue?
Joel Tosi: What I love about that too, Elisabeth, is I don't think you would ever say we are constantly always going to optimize for making that problem the code base better, even when it's in a good spot because let's be honest, it's a system and you have external things influencing your system. So what might be right today might be wrong tomorrow. You might optimize for one thing now and then have to optimize for something later. But the key is everybody's seeing the system together, seeing the same reality and understanding where the influences are and where the levers are at and why we're pulling the levers we're pulling right now.
Elisabeth Hendrickson: 100%, yes.
Shane Hastie: We're coming close to the end of our time, but what's the really important question I haven't asked?
Elisabeth Hendrickson: What would you like to know that you haven't asked?
Favourite Parts of the Book [33:56]
Joel Tosi: I'll ask Elisabeth other question and then she can ask me a question that you haven't asked, Shane. Elisabeth, what's your favourite part of the book and why?
Elisabeth Hendrickson: Oh, that's actually harder than you think it is. I'm going to dodge your question and instead answer it from a slightly different perspective. So the book has a fictional component and a non-fictional component. We kind of break the fourth wall. So there are stories and we wanted that because we wanted to have what felt like a case study that it's fictional, so it's not technically a case study, but the source for that fiction is the cumulated between Joel and me, we have what, 65 years or something of experience. I mean, that's what we drew on to build this out. So we had so much fun creating this fictional company and the characters in it and putting them through absolutely miserable experiences. And our first drafts were actually too nice. They had small little problems and then they overcame them and it was sort of like a 20-minute sitcom.
Whereas we needed it to be more like an extended drama series with some highs and some lows. So we kept amping up the challenges for them, but that our fictional world exists in the same world as the Parts Unlimited and in Phoenix Project and Unicorn Project, which is the same fictional world that IT Revolution has this fictional universe. We live within it and there's a little bit of character crossover. So that was some of the most fun work as part of the book was to come up with a story that would support all of the non-fiction explanation of here are the tools and here how to use them. Joel, what about you? What's your favorite part of the book?
Joel Tosi: So I had all this time to think about it and I still don't know if I have a good answer. I think what's interesting is my favorite parts would change throughout our writing. I think one of the things I enjoy the most, and hopefully it comes across for some of the readers, there's two things. One is I think systems thinking is something that people naturally and intuitively do. And so that's why the narrative was there was to show, look, people are doing it and we're just showing how to codify it so more people can see it and codify and point to what you're thinking. I think that's really beautiful. But I think there's this thing where Elisabeth and I were working on U-curves from economic theory, talking about context and this whole thing around right today, wrong tomorrow, and wrong today, right tomorrow. And the fact that we could start building these mathematical models that could show based upon your context, here's a range of good options for you.
But then of course, as your context starts to shift, your options also start to shift. And so it became a nice way of saying things like, if you don't have any testing at all, start with some regression testing. But as your context starts to shift and that those become more expensive, you probably want to invest in different types of testing. And so what's appropriate for you? It depends upon your context, but we can model it. I think this interweaving of system thinking tools in a very approachable way and showing that people are thinking about it anyway, we're just helping you codify it.
I think that was one of the things I enjoy the most, especially when Elisabeth and I would get together for three hours and try and say, "How do we tell people how to do this?" Because it's hard at times, but I think we made the codification really nice and that's my favorite part.
Elisabeth Hendrickson: I will also say for the record, I have adored working with Joel on this because that get together for three hours thing. I had a question for him that we both thought was going to be 20 minutes of just him explaining to me something I didn't understand. And then it turned out that it was harder than either one of us had realized. And so three hours later, we're still arm wrestling with this problem and that happened over and over again. So perhaps my favorite part of the book was the opportunity to work with somebody who challenged me and taught me, and it's such a joy.
Joel Tosi: And vice versa.
Shane Hastie: Well, Elisabeth, Joel, thank you so much for taking the time to talk to us today. It's as always been an absolute pleasure and good luck with the book.
Elisabeth Hendrickson: Thank you.
Joel Tosi: Thank you so much, Shane.
Mentioned:
