S5E149🎙️ LIVE with Elisabeth Hendrickson (Multi Tracks Audio)

Hi, I'm John Maxwell. When the top companies in the world are looking for trainers, speakers, and coaches, there's one name that stands above the rest, and that's Maxwell Leadership. Our certified team members have gotten proven results for companies all over the globe, and our reputation, I'm proud to say, is second to none. Some of our members have risen to the top of their profession, including the one you're going to meet today. I proudly introduce you to my friend Bob Fabien Zinga.

Welcome to the Leadership and Success Podcast with your host, Coach BZ, where we help you lead with purpose and succeed with impact. If you're ready to grow into the kind of leader others want to follow, this podcast is for you. If you're determined to elevate your success and leave a lasting legacy, this podcast is for you. As my mentor, Dr. John C. Maxwell, reminds us, everything rises and falls on leadership. Our goal is simple: to inspire you, challenge you, and equip you with insights that can transform the trajectory of your leadership journey. Welcome aboard to Welcome to another episode of the Leadership Success Podcast with Coach BZ.

Harry, my sponsor, says it's time to start. So we were just debating, should Harry get up and introduce me? And I decided that he didn't have to do that because he's so comfortable there with his laptop. It seemed cruel to make him get up. So instead, I'll introduce Harry. This is Harry. In case you don't know Harry, Harry has been at Google for how long now?

8 months.

8 months. Harry is the model-based testing guy among other amazing things and collector of testing-related lyrics up on his website and is now blushing, I think, just a little bit. So I'm here thanks to— I want to tell a story from a workshop I used to teach a long time ago that blew my mind. I was teaching a class for agile coaches to learn how to design their own teaching exercises. This team had designed an exercise and put some of the other coaches who were in the class through this exercise. And remember, everyone involved is an Agile coach. They are there to learn how to help other people see what they see with respect to Agile. So, the leaders of the exercise sit these people down and they start throwing random tasks at them. "Here, blow up these balloons. Here, twist these pipe cleaners. Here, fold this paper. Here, roll these dice. No, that's not important anymore. Roll these dice." And it's total chaos. The entire room is laughing as they're doing this. And they say, "Okay, so round 2, instead of walking up to you and just telling you to do stuff, you get to be a self-organizing team." And so then we do round 2, and the participants have come up with a backlog system. They have the conversations to prioritize the backlog, all the things that you would expect. The mind-blowing part is in the debrief, the participants said, you know, "Here's the thing though." I liked round 1 better. You liked chaos better? Yeah, it was so much easier. I didn't have to think. I just did whatever you told me to do, and that's what good looked like. Why is it so discomforting? Because comforting illusions are comforting.

All right, welcome to another very special edition of the Leadership and Success Podcast. I am your host, Coach Bizzy. We have a very, very special guest today. So, uh, for those who've been watching the show for a while, you kind of know what to do. We're gonna start with what we call a moment of gratitude. This is where we take just a moment every time we meet to be grateful for something. So if you would maybe close your eyes, put yourself in your happy place, take a deep breath, and think about one thing that you are grateful for. I must tell you, Since June 10th, there is just now, recently, July 4th, our 250th in this country, if you can believe that. I am really, really grateful for freedom. I think there is just nothing like it. I am so, so grateful to be a free man in the home of the brave and the land of the free. So grateful for all of the people who have served in our armed forces, any branches, including the newest one, which is space. Space Force. Myself, I am a US sailor, and I'm just, just grateful for the young men and women who go out there and fight for our freedom. Wow, I'm so grateful for that. So let us know in the comment what you are grateful for, where you are connecting from, what city, what state, and if outside of the US since we've gone global now, also which country. And if you have a question for my guest, make sure to type it in the comments, whether on LinkedIn or on YouTube. Okay, without any further ado, let me see if I can properly introduce our guest today. She is very special to me. Our guest, we used to be colleagues. She was the Vice President of Engineering R&D at Pivotal, a company at the time owned by EMC. I guess Dell now owns the brand. But anyway, I am really excited to welcome Elizabeth Hendrickson. I believe she's a Silicon Valley giant, uh, to the Leadership and Success podcast. And Elizabeth is a technology executive, engineering leader, author, speaker, and founder of Curious Duck Digital Laboratories. Uh, with more than 30 years of experience in software engineering, quality, and organizational leadership, she has served as a VP of R&D, VP of Engineering, and advisor of technology leaders building high-performing teams and sustainable engineering culture. Many in the technology community know Elisabeth as the author of the influential Explore It!, a landmark book on exploratory testing that continues to shape how software professionals think about quality and risk. She's also the co-author of the upcoming book Signal and Levers: System Thinking Tools to Unblock Software Delivery, which explores how leaders can identify the right signal, improve decision-making, and build organizations that deliver value Predictably. I think we're gonna have a surprise guest when we start talking about the book today. But whether you lead sellers or software engineer or cybersecurity team or enterprise organization, I believe that Elizabeth's leadership philosophy will remind you today that technology is powered by people, and great systems enable great people to do their best work. So some of what you're gonna be learning today is why great leaders focus on systems, instead of simply solving symptom, but also why better system ultimately create better teams and better leaders. So I'm especially excited to explore how Elizabeth's ideas on system thinking apply not only to software engineering, but also to cybersecurity, military leadership, believe it or not, and mission success. So without any further ado, please help me welcome to the Leadership and Success Podcast, the one and only Elizabeth Henriksson. All right, good morning, Elizabeth. How are you doing today?

Good morning. That was amazing. I've never had an intro quite like that ever in my entire career, complete with the stadium cheers. Wow.

Well, it's a great honor and privilege to be talking to you. This is just awesome. So how are you doing today? What is one thing you are grateful for?

I am inspired by your gratitude of freedom, and I am grateful for community. As a general concept for— so grateful for all of the communities that I belong to. But I have to say, as a community, Pivotal is how you and I know each other, and I am particularly grateful to you. What other people don't know is before we started, as you were preparing, you did the most thorough deep dive of my website that I think anybody has done in well over a year, including me. And you found stale links that go nowhere that have been stale for over a year, and Nobody had detected it, and I was able to fix it before we went live. So, I am grateful for community, but I am particularly grateful to you. You're amazing.

Thank you. Thank you. Wow, this is really awesome. No, it's really great to see everything you've done since our times at Pivotal. My goodness, that's great. And you also got a Silicon Valley legend to actually write the foreword for your upcoming book. How in the world did you manage to do that?

Gene Kim is a wonderful person and he was so supportive of the book.

He—

IT Revolution is his company and he was so supportive of the book from the very beginning. So supportive that Signals and Lovers and The Phoenix Project actually exist in the universe and we had a crossover of one of the characters, two of the characters.

Really awesome.

So I think that that might have had something to do with it.

Yeah, I know he's a prolific author as well. We've been connected, I think, since our time at people. So I'm trying to get him on the podcast. Hopefully, he's going to be here soon. But yeah, just a Silicon Valley legend. That's all we have to say about it. So what is something about you I like to ask most people may not know? Something unique, maybe a superpower, something most people just don't know when they first meet you.

I never know what to say about myself at all, ever. And so I really, really don't know what it might be interesting to anybody that they don't know about me. I'll say this, my car is one that most people don't predict when they meet me. I drive a little two-seater convertible roadster that I just love. And so you can picture me toodling around in California in my little two-seater roadster.

That is, yeah, but I think that's one of the first electric cars that Tesla made, right?

Oh yeah, no, sorry, not a Tesla roadster. I mean, in the category of cars, it's a little, the thing about roadsters is that you can really feel the road. And my mother, who was, shorter than me and very petite. She— I got this from her because she, she drove a little two-seater roadster for my entire life, convertible. And I didn't understand it at all until I inherited her car. And now I'm on my second one. Her car was the first, and I— that one eventually went the way the cars go. So now I have mine that I bought, uh, new because I realized the appeal.

Yes. I guess now that our second daughter, our last one is going to be going to college this fall, maybe we're going to get rid of the minivan and I'm going to maybe go for a sports car or something. So that sounds appealing to me. So let's go back to your origin story because every great leader has an origin story. You often joke that you wrote your first line of code in 1980.

Wow.

That's so long ago. And almost immediately, you found your first bug. Looking back, what did that first bug teach you that still influenced your leadership today?

I'm going to be honest, I don't actually remember exactly what my first bug was. But I do have to paint a picture for you, because I do have some lessons learned from that time.

And also being a woman in the tech world, especially back then, wow.

Things are actually in some ways worse now, but I'm going to skip that. And instead, let's talk about the TRS-80 and Basic, not, not Visual Basic, basic basic. And I'm, I'm, I will be surprised if very many people who are listening to this actually know what BASIC looked like, but you had to number your lines. Um, and so there are, there are actually 3 things that I learned from that time. One involves line numbering, because as a naive first-time programmer, I made my first line 1 and my second line 2 and my third line 3, and I had numbered my lines. And then I had to edit my program, and then I spent another 20 minutes remembering all of my lines. Oh, and editors were not like they are today. Like, I think I had to edit it like one line at a time. I don't actually remember the details at all because this was 1980. So, so the first thing is to, to never assume that I'm going to get it right the first time and always create space for, for the things that I learn as I go along this journey. So that was lesson number 1. Lesson number 2 was about reading code, because I suspect my first bug was probably when I typed in— because what you would do, you'd get these computing magazines, and there, there was no like copy and paste. That was not a thing. So you'd get these computing magazines, and then you would type in the program listing that was in this magazine. I know it sounds like caveman times, but type it in. Um, and I, I discovered that, that it was so important that I actually fully understand what I was typing in, because that's probably where my first bug was, was in mistyping something, and something was outside of a loop that was supposed to be inside, or vice versa. I don't know. Um, but reading code and reasoning about what it's actually doing is an absolutely critical skill to develop. So I, I definitely learned that in 1980.

How much things have changed. Uh, I don't know if you remember one of the first languages I learned, but with them I think which is completely dead now, was Fortran, right? For formula translation, I think. But anyway, completely dead now. Now, when I came to Pivotal in 2014, it was the first time I was exposed to the Agile methodology and all that. And XXXP, I guess you guys were very, very good with that. And I remember how you used to do pairing and all that. All completely new to me. I had to learn all that. I'm so glad I did because pretty much everybody else in Silicon Valley They pretty much use the same philosophy when it comes to the, the, the developing code. How, how did you get to become an expert in XP?

Um, I, I hesitate to call myself an expert in anything, but that's neither here nor there. So, so, funny story, uh, I met Rob Mead, who ended up being the CEO of Pivotal. I met him— I didn't look up the year, but early 2000s sometime— at a little peer conference that Brett Petticord, a colleague of mine and someone I respect tremendously, he was running this tiny peer conference, and he invited me, and I came. That peer conference turned out to be— that, that was a life-changing moment for me right there, going to that little conference. And so the series of random events that had to line up in order for me to be in that room was kind of amazing, and I'm so grateful that I was there. So Ward Cunningham, the guy who invented the wiki and many other things, Ward Cunningham was there, and Rob me there and, and a bunch of other people. The, uh, that was the conference where I first saw Selenium, the test automation framework, um, uh, being demonstrated. Uh, so anyway, Rob Mead, as he was talking about how his groups worked, I already was familiar with the principles of XP. I had taken a class that Josh Kerievsky had that was immersive and taught XP, so I was familiar with the concepts, but I, I I could not, I wanted to work that way on something real. And the more that Rob described how his company, which was at the time Pivotal Computer Systems, not Pivotal Labs or the Pivotal that later existed, the more he described how this little consulting company worked, the more I wanted to weasel my way onto one of his projects. And so eventually that happened. I found myself on two of the origin story projects projects that Rob would talk about. And I learned so much about not only the mechanics of extreme programming, but also being able to observe it from the inside helped me understand why it worked so incredibly well. So fast forward, I ended up doing a lot of little projects. I would come in as a friend of Pivotal periodically. I didn't work there, but I would come in and do a project and then go away. And so I got to deepen my skills in extreme programming, and then ultimately joined Pivotal in 2012 to work on Cloud Foundry.

Um, yeah, yeah, I remember Cloud Foundry. Yeah, and I joined 2 years after you. Like, I think, remember our mission at Pivotal? It was to teach the world how to do modern software. I believe that was it, right?

Transform the way the world builds software.

That's right.

Yes.

And for me, it was to do it securely. I just added— yes, that was so, so much fun. Because I remember even when you did your Google talk, I only showed a very small clip of that, which would be The entire clip will be available on my LinkedIn page. But even back then, you were talking to Googler, which was back then, I think, the equivalent of what TEDx is now. And I think there was only one person in the room that even knew what XP was or was working on a project towards it. Right? And that's kind of amazing because today, pretty much everybody does that. That's quite amazing. Now, you've been a programmer, a tester, engineering executive, a vice president of R&D, a founder, advisor, author, and man, is there anything you don't do? A coach, and man, Do you have time to sleep? My goodness! Which transition stretched you the most as a leader?

Definitely, it was the, our shared experience at Pivotal. I ended up being the VP of R&D for the data products. And that was, first of all, the largest organization that I have managed. And second of all, it not only was it a distributed organization, relatively large, I think I was responsible for like 170-some-odd people working on 3 mission-critical data products.

I think we've had people from Europe and from China too, if I recall.

Yeah.

Oh, yeah.

We had, we had a big contingent in China. And I am so grateful for— they all kind of took me under their wing to help me understand how, how China works. Because it is, I mean, I'd been to China before, but I didn't fully understand. And so I am so grateful to everyone I worked with who helped me as I grew and stretched.

Yeah, so many different challenges there too, because I remember we had to use a special VPN for them to be able to get access to our stuff and things.

But 100%, yes, absolutely, yes. And I also was responsible for all aspects of R&D, including product management and design, as well as engineering.

Wow.

Yeah, so it was definitely the biggest stretch of my career, man.

So what did you learn? What leadership lesson did you learn during that time that's still useful to you today?

Oh, so many. I don't even know where to begin. Can you ask a slightly more precise question?

Yes. Okay, which, which, which lesson has been the most impactful? Or one of the most impactful?

Yeah, I actually, I think that there were so many lessons. Because there were so many challenges that we had. Just to explain to folks who might not understand. We When I stepped into that organization, we were a very traditional enterprise software development organization. We were shipping production quality. And, and like I said, these are mission-critical enterprise shipping software. This is not a SaaS. This is not something where if we mess up, we can turn around and redeploy. It ships. It's in somebody else's data center. We don't even know how they're using it necessarily. In some cases, it was going into dark sites where we would have no ability to diagnose what was going on. So it had to be really, really solid. And the practices that we used when I, when I got there, the practices that we were using were fairly traditional in terms of there's a bunch of engineering and then there's a bunch of testing and hardening, and then there would eventually be a release. And one of the products was shipping on about an annual cadence, and another one of the products actually, I think it had been something like 2 or 3 years since they had had a general availability release. They had done patches features, but they hadn't done a general availability release. And we transitioned, we were transforming the way the world builds software, including the way that we built software, because those products came, they grew up in other companies, and then they were part of a big— Pivotal, the company that you joined, was a big merger, you know, an M&A project. It was throwing together a bunch of companies.

VMware and Pivotal Labs, right?

EMC had acquired Pivotal Labs and had also a bunch of other assets, and I'm not remembering which ones right now. And then VMware had Spring Cloud Foundry. Oh, EMC had Greenplum, of course. What was I thinking?

Right?

And that was one of the products that I was responsible for. So between EMC and VMware, they had basically said, these things don't make any sense in our portfolio, so let's do a spinout. Combining these things because there was already a tight financial relationship between EMC and VMware. So they did this spin-out. That spin-out— it took— yeah, Pivotal Labs belonged to EMC and it was part of the spin-out. And the thesis was, hey, uh, modern software delivery practices with the— what Pivotal Labs does on a modern substrate of cloud with a data fabric. And, and the thesis all made sense together on a slide deck, but actually making it happen, where things were integrated, that was the big M&A project. And so when I stepped into the role in data, the data organization hadn't grown up in XP or Agile or— very traditional. So there are so many lessons there about transformation. And I don't know how to pick one. Because transformation is not easy.

True, true.

Yeah, that was really a great chance for me, because I remember I was just coming off of active duty. And this was my first job in Silicon Valley. And this was the first time in my life I had actually 9 interviews before you guys hired me. I think you were one of the people who tortured me during the interview. I was like, this doesn't make any sense. But then I understood why it was so important for you guys to really get the right culture, right? Because usually the military is not kind of top-down and all of that. And yeah, so that didn't make much, much sense for Silicon Valley culture. But then later on, I figured out that the way we did software, again, people told us the way everybody was doing software everywhere because I became a consultant and all of the startups I went to, it was pretty much pivotal, duplicated or cloned. So that was very helpful. But also, like you said, some companies, they only do software updates like once a year or something. That's what the Navy did most of the time, maybe once a year or twice a year or something, waterfall type of thing. But you guys, for the most part, I think we are doing a sprint cycle like every 2 weeks. I'm like, how in the world are we going to be able to secure this code? And you have to publish them on a 2-week sprint cycle. I'm like, man, that is crazy. But anyway, that completely changed the way I looked at software ever since. But that was quite something. So you have led startups and publicly traded companies too. What leadership principles remain constant regardless of company size?

Yeah, I knew you were going to ask me this. And again, it's a little hard, but I do actually I actually have an answer this time. And that is that you can't, no matter what the size is, you can't lead by telling people what to do. And I think that's one of the things that first-time leaders in particular haven't really absorbed yet. Because every time I did that, and I did make, I made plenty of mistakes at Pivotal. And there were times when I would tell people what to do. And I'm pretty sure that they were all wrong. And instead, the important thing is to establish what I now call kind of the house of management. If you think of the roof as the goals, this is where we're trying to get to. And then the walls are the constraints. These are the things that we, we, they are outside what we can do. So like, we're going to bring GemFire to the cloud. But what we're not going to do is rewrite all of GemFire to make that happen. So that's the goal. Here's the constraint. And then you have to build all of the house. It has to be on a solid foundation of culture and trust and psychological safety. And so the, and it is not OK to reach inside the windows as the leader and mess around inside the house. Because what you're doing is you're creating the, the degrees of freedom, the space in which the people who report to you are going to be able to operate. It's totally fine if you're not getting what you need to shrink the house. Like, I mean, maybe it's a communication issue, or maybe it's something, but you can say, "All right, let's, let's go for a smaller goal and tighter constraints to see if we can align and get where we need to go." And if you end up shrinking the house so small that it does feel like micromanagement, something has gone horribly wrong. And that's the point to start evaluating, you know, what to do. But at no time is it OK to reach inside those windows and start messing around.

Yes. That is, that is so insightful. And you mentioned psychological safety. We talk about that quite a lot here. What is something you think, as a leader, you should do to enable a culture and environment where psychological safety possible, like it was at Pivotal, I think?

Yeah, I think that there are a couple of things. One is to create space. And sometimes, as a leader, it's so hard to do that. But to create a— take a deep breath and just allow people to have the freedom to make mistakes. And then that's where the second part comes in. And that is to create a learning organization which means that if people get their bets wrong, you don't come down on them like a ton of bricks and blame them, like, "Why didn't you foresee that?" or, "How could you have made that mistake?" That doesn't mean we don't learn from whatever happened. But it does mean that, just, I think Deming said to get blame out of the system because it inhibits learning. So create the space so that people can learn. And then don't mess up the learning by blaming them if things don't go exactly to plan.

I like that. And I also believe pivotal was the first company I worked for too, where we started using OKR and KPI. We had goals for each quarter and then we kind of break it down. That was so helpful to me because I've never really worked at a company that actually did that. It kind of forces you to actually accomplish something. I mean, you're not always able to do everything that you plan, but at least you make a lot of of progress as you plan your week and so forth. How do you build a culture where people not only work as hard as they can, but they actually want to be there? And I must remind you, one of the core values we had— first, I wonder if it was a joke, because I think one of those core values you said Robert made, one of his values was dinner at home. Do you remember that?

Yeah, oh, 100%. We caught, especially on Cloud Foundry, I came up through a different path than the data products. And I was part of the Cloud Foundry leadership team first. We took all of the Pivotal Labs principles and practices and we adapted them to shipping enterprise software, but they were all present. And part of that was we started every day at 8:55. Oh, sorry, no, 9:08. I got the times wrong. Long time ago, but anyway, 9:08. What a weird time to hold standup, right?

Yeah, for 15 minutes exactly, right? That's what we call, yeah.

Yeah.

Which is weird to me too.

So, so let's, I mean, let's just call it 9 AM. So 9 AM, everybody starts. There's none of this roll into the office late because you were working late.

Daily standup, yeah.

Yep. Daily standup starts at 9 AM and you go home at 6 PM.

Yeah. That was something.

Yeah.

And that is so important because what, what that did for an extreme programming team, we were all co-located. For the most part with the people that we were working with. There were exceptions, but mostly we're all working with people who are right there. And that overlap meant that we could really optimize for collaboration during the day. And then a sustainable pace is absolutely critical. And to make it sustainable, you have to go home. Or you don't have to go home, but you can't stay here and put in those extra hours and, and burn yourself out, because that actually, that, that is not a really not doing the company a favor or doing you— it's not doing you any favors. It's not doing your family any favors. But it's really not doing the company any favors because you're not going to be able to function for very long like that. And we want you to be able to function as well a year from now as you're functioning today.

Man, that is so, so powerful. Bob Fabien Zinga was my boss. I remember the first vacation I took as a pivot. He told me not to take my laptop with me. I'm like, what, what, what, what? He's like, no, you're on vacation. Don't work. Don't call. No, unless— no, you know, somebody's gonna die or something. But yeah, right, vacation, enjoy your time off. That was the very first time in my entire career where I went on vacation without working at all. I was like, wow, that's something. And also during the stand-up, another thing that I felt was so important, I've never done that quite before, it also teaches you to be more humble, right? Because you can actually ask for help. Hey, this is what I'm working on, I am kind of stuck, can somebody help me? And people will be willing to. I've never really seen that ever in my entire career. That's just so powerful. And by the way, we do have our mystery guest, he's in the green room. We're We'll be bringing him or her very, very soon. I'm glad that he's there. We do have our first question from the audience. So Daniel Young from Metland, Florida is saying, Elizabeth, in your work with Signal and Lever, how do you recommend leaders identify when the signal of organizational stress is an indicator of a degrading human firewall versus a purely technical failure?

Failure? Uh, I love that question. I would actually love it if you'd be willing to bring on our surprise guest at this point because this is directly related.

All right, let's see. Ladies and gentlemen, please help me welcome our surprise guest, the one and only Joe Posse. Let's see if I can find him. Here he is. Hey, Joel, how are you doing today?

I'm doing wonderful. I've been watching the whole episode. It's been wonderful the whole time through. And Elizabeth, I told you I know basic, so we can talk about basic all day.

Okay, maybe that'll be your next book.

I'm just telling Elizabeth, maybe I can convince you to come back because I know you've published at least 2 or 3 other books. I'd like to have an hour just with you. It's just amazing the work that you guys are doing. So can you help us with this question from our live audience?

Yeah, the question from Daniel, it's a wonderful question. I mean, the interesting thing is that it could be an indicator of both. And because systems are systems, there aren't just one kind of attribute. I mean, they're influencing each other. And I think that's the beauty and the profoundness of systems thinking. The architecture could be challenging, which causes stress because we're trying to get stuff shipped. And that causes degrading morale and becomes all these intertwined factors. So we can't necessarily just pull one apart and say it's definitely that. I think the signal is what's important. And then like, what do we do about it becomes a really interesting question.

Hmm. I like that.

Anything you would add, Elizabeth, to what, uh, oh, Joel's answer was so much better than mine was. I was gonna go into a deep dive of, well, it depends on which signals you're seeing and hearing, and it would've taken forever and not gotten to the point as well as Joel Yes.

Okay. Since Jules is here, let's talk about this book. I know it's going to be a best-selling book. So, the book we are talking about, yes, that one, Signal Lever: System Thinking Tools to Unblock Software Delivery. And I know it's going to be available in the fall, September when?

September 22nd.

22nd.

Wow.

That is— But you can preorder right now. Go to Amazon. It is available for preorder. Okay. I guess the first question I have to ask, to both of you is, why did this book have to be written?

I'll take my stab at it, Elizabeth, then you can chime in. So just to kind of set context, we've both been in a lot of organizations where at the end of the day, everybody wants to help each other, right? And so it's kind of like, I think for a period of time, I work a lot with teams, I work a lot with managers, I work a lot with executives, and I'd be with a lot of teams and they would say things things like, the managers just don't get it. Like, they're doing these things to us. That's the problem, the middle management and the executive, they're the problem. You talk to the managers, and they would say things like, I don't understand why the team doesn't understand the problems I'm facing. And so everybody wanted the best thing for each other. But usually what was happening, it was, it was actually hindering each other, because they weren't kind of understanding the system at play. And So for me, like, this book needed to be written as a way of maybe stopping the arguing. Yeah, that sounds too utopic, but I mean, it's really to get people to see the same reality and work together on the problem as opposed to like trying to optimize individually.

Okay. What about you, Elizabeth? What leadership problem kept showing up over and over again that convinced you that this book needed to be written?

Well, I'm going to answer the question from a completely different dimension, and both things are true. So there's a long origin story that gets us to this point where I got to appreciate a class that Joel had designed on systems thinking that was focused around causal diagrams and variability with Shewhart charts, process control charts, and U-curves. And those 3 tools were self-reinforcing in ways that I had never seen before. And I think the point at which I said, hey, Joel, "I think we need to turn this into a book" was when I really appreciated the extent to which Joel had pulled together such an interesting collection of tools. And the first version of, of what we thought we were writing turned— was named The Thinking Leader's Toolkit, because it really was a toolkit of, of things that came together. But then as we started working on the book, it became more than just a toolkit of, "Well, this looks like a job for a U-curve," and became much more of a holistic holistic view. But I still think that the book needed to be written because I am unaware of any other books that pull together, yes, um, the concepts along with concrete tools that you can use to apply the concepts, um, in, in a way that, that, that, that is genuinely a, a holistic and a, a holistic full viewpoint on systems thinking applied to software development. And Joel deserves a massive amount of credit for having identified the right set of tools that form the core of that.

That is really insightful. Even the title itself, right, Signal and Lever. So what are leaders missing? So maybe, Elizabeth, you can explain the signal part, maybe, you know, how executives misread organizational health. And Joel, maybe you can explain the lever part, right, how coaches identify leverage points and what actually changes system. So fascinating.

Yeah, signals. I didn't have the right vocabulary at the time. But for years and years and years, I have thought in terms of signals. I just didn't have the right vocabulary for it. And they surround us. It's not just the dashboards and the— you've got your DORA metrics, or you're doing whatever process, and it's got those metrics. It's not just that. It's also When you can't find time to meet except on no-meeting Fridays, because everybody's calendar is so, so jammed up, that is a signal something is up in the organization. It's not a diagnostic; it's a signal. Or the extent to which decisions get delayed until things become a crisis—that, that is, that is both a choice that people are making, but also the fact that they feel compelled to do so. That is a signal. So signals can be quantitative; they can be qualitative. And you are 100% surrounded by signals all the time. The challenge is figuring out what are they trying to tell you and how do you filter out the ones that are not providing useful information? Because they're actually, even if they're on your dashboard, if they're not helping you make better decisions, they're probably noise.

So true. What about you, Joe?

I mean, Elizabeth nailed it with the signals. It's, it's how we reason with complex systems. What about the ground level? Yeah, on the lever side, levers are really just the things, the decisions we make to try and influence the system at large. We would be remiss if we didn't mention Elizabeth and I were both highly influenced by Donella Meadows and a bunch of her groundbreaking work in systems thinking. And in one of her— call it a metaphor or call it her frame— she talks about 9 levels or 10 levels of levers in the system and various kind of leverage points.. And so what we were trying to get across with levers is that when you're trying to influence the system, you're in essence pulling a lever. Now, kind of like how much leverage you get kind of depends upon a multitude of things and where you're acting in the system and your relative control. So it's, it's a really beautiful metaphor. Um, I think another takeaway we'd like for all the readers to get out of it is even if you don't think you have levers available to you You probably do. So sometimes it's like talking to— like, if I'm working with the team members and they're complaining about, or they're challenged by all of the meetings they're in, it's like, well, you know, you don't have to go to that meeting. What do you mean I don't have to go? You could make that decision if it's not helpful to you. And sometimes just like those simple small things become like this mind-blowing moment for a team that feels stressed.

And they say, say, "Oh yeah, I could skip that meeting." And maybe just send an email, right?

Yeah, exactly. So levers are all around us, and it's just kind of being aware of the levers we're pulling and the influence we're trying to have.

Well, if I may, I'd love to connect with a story from Pivotal that I think is going to help you see, Bob, why I was unable to answer your question about like one lesson. So there was this meeting that I was invited to. I was in a leadership position. I debated about whether or not to go. It seemed to be a huge meeting, and I really wasn't sure what my role was. But I decided that I was going to go because I did not want to send the message that this meeting is not important. And I felt that if I didn't go, I would be sending a message. So I went, and within the first 5 minutes, it became very apparent to me that I could not offer value in this meeting, and that in fact my presence might prevent value from happening. Because again, I was in a position of of positional authority. So my voice would carry more weight, and I didn't actually know enough to be contributing to this discussion. And so I found a good time, like very early into this meeting—it was within the first 10 minutes—to basically stand up and say, "Look, this is a critically important meeting. I want you to have it. You need to continue having this discussion. However, I, I'm gonna invoke the open space Law of Mobility that says if you're not going to get value— and again, this is an important meeting, it's just that for me personally, I just— you need to figure this stuff out. I love that. And if I'm not going to give value, and I am here to tell you I have nothing helpful for you, so I'm, I'm gonna hope I don't offend you, but I'm gonna slink away. And I did. And I tried to do it in as respectful a way as I could, and I was really afraid that that somehow that was going to break the spell and they wouldn't stick with the meeting. And most of the people stayed, but one person snuck out right after me, like didn't even let the door close, was right on my heels, and turned to me—

your permission to do so—

and turned to me and said, it never occurred to me. Yes. And so in that moment, this other person had a realization that then they carried forward with them that they are not actually being summoned every time there is a meeting invitation. They have a choice that they can make. And that is one of those— it's a tiny lesson, but making people aware when they have choices is a leadership lesson.

Absolutely. And I must ask you, all of the companies I've worked at in Silicon Valley, Pivotal was definitely one of the best ones, more fun. It was really great. Did you guys go to some type of leadership training or school? Because the emotional intelligence I noticed at Pivotal was much higher than most other companies I've ever worked for in the Valley.

So there was eventually a leadership development program, but I think that it occurred after you had already left. OK. And so what I think you were observing, because I think your department— I remember working with Bob. What a wonderful person. And, and I remember working with your organization. And I think that a lot of the people that you were interacting with were coming from that legacy of a very humanistic style of management that stemmed from Pivotal Labs and the influence that then Labs had had throughout the rest of the organization. Really impactful.

It was, what, 12 years ago, and I still remember it. All right. So let me ask you this then. Let's talk about executive versus coach. So we have the executive here and the coach right there. So As a VP for R&D, what question were you asking when you were writing the book? And, Jo, just so that you can start thinking about it, walking into organization as an outside coach, what different question were you asking?

So I'm not 100% sure I know how to answer this question, but I will say that I was trying to put myself back in that seat, which I'm not in today, but I occupied for long enough. Work with enough other executives that one of the things I really wanted for the book was that it would speak to executives and help them with figuring out how to reason about these really gnarly system problems. Because that's one of the challenges is, is recognizing when the thing that you are seeing is just one slice of it, and the influences that then influence each other and influence the slice you see. Being able to reason your way through to figure out, about how to, how to detect when the system is influencing itself. Or put another way, you poke the system, and the system's going to poke back. And I think that executives sometimes have a tendency to kind of suffer a little bit from the illusion of control, because they have positional authority. So they have the authority to say how things should be. Only you poke the system, and the system is gonna poke back. And so that was part of what I was trying to bring to writing this book was that perspective and hope that I, we would be able to get through to executives who want to believe believe that their positional authority allows them to control things.

So, Joel, as an outside coach, what different question were you trying to answer?

I think there's probably two questions that I try and get across. Many organizations I come into, they want to, of course, ship software faster. And the easiest question is, and then what happens? And then they say, well, then we have more software out there. And then what happens? And so, like, there's this kind of, like, you know, tail wagging the dog effect. Like if we only had more software, we would then be better. Yes. There's no data to back up any of that. Like there's no realization if like the software is highly valued as it is, or there are small things that should be removed because they're confusing. So I always find that interesting. And I also find it interesting when I'm actually working with teams and they're trying to get stuff done, trying to get stuff done. And sometimes we just ask them things like, you know, what is harder than it should it should be. Because you see a lot of teams that they're just so used to like the noise of how this system works, they just kind of get— they get used to dealing with it. And you just kind of say like, what would— what would be nice if it wasn't so hard? And they'll say things like, well, I gotta go kick the Kubernetes cluster every 2 days, I don't know why. But, and— but like they, they spend all this time, you know, on things that they just wish it was easier. And they'll— and they— once you start surfacing that, those are the things that sometimes managers don't see is they don't see the friction and the hard things that should be easy that the teams are dealing with. So instead of even worrying about why can't the team go faster or how to write better stories or any of that other stuff, it's just what's harder than it should be. Because software should be fun and the creative stuff should be the fun stuff. It shouldn't be go kick Kubernetes again.

I like— actually, you actually made me think because there are some people people, they should probably even ask themselves, is what I'm doing even needs to be done? Whether they should really be doing something else right now. That's incredible. So were there moments while writing the book where the two of you disagreed? I'm sure there was at least one. Oh yeah. Okay. All right. Can you please share? It looks like Elizabeth has something to say for sure. Please share.

I'm gonna, sure, I'll share it. I'm not gonna say this one's a true disagreement. It. But it, it was definitely one of those moments of, wait a minute. Um, so Joel— I had just attended one of Joel's trainings on U-curves, and we, we needed to write some content on U-curves. And I totally see the value in U-curves, but Joel had this slide where he said, okay, and so then—

did you have a but, Joel? She said but.

Okay, I did. Um, I— okay, so this is, you know, here's a U-curve. This is what it looks like. This is what it means. This is how you think about it. And then you can create your your own, just blah blah blah. And I don't remember the blah blah blah, but I remember my brain breaking at just. That's why I don't remember the blah blah blah, because that, like, I, I tried to follow along, I couldn't, I could not figure this out. And so I reached out after that, that was a class, and so I reached out and we were already writing stuff, but I said, hey Joel, I'm, I'm confused, how, how, how do I just blah blah blah? And he said, oh, and I, I think both of us thought that this was just going to be a of, I didn't get it, and, and so Joel was just gonna help me get it, and it would take 20 minutes and be fine. 3 hours later, wow, we were still arm wrestling. And ultimately, that, that— I mean, I feel like this is a great example of our collaboration because there were many times when, when we would end up saying, I think we need to arm wrestle over this one. And, and that wasn't about having a conflict together, it was more about recognizing where we, we hadn't fully figured things out together yet in a way that we both could represent. And so our, our U-curve material did end up so much better as a result of the collaboration in ways that it would not have, I think, if either one of us had gone off on our own to try to figure stuff out.

That's really cool. Anything you would add, Joe?

The U-curve is a great example. I think there was other examples where there were parts of the book that Elizabeth would write or I would write that we would be just so like emotionally attached to, and then the other person would be like, I'm going to cut that. I'm going to remove that. And why? Why are you removing that? It's so beautiful. And so then we would talk about, you know, kind of like what's the essence of the chapter? What's the core? Like, and we were just— it's almost like haiku. We were trying to remove it down to the essence over and over again. And then one other thing, which Elizabeth I know is aware of, there was— and I did it once or twice also. I recall one Friday where Elizabeth was like, I, I'm gonna do open heart surgery on this part of the book. And it was like, what are you— like, it was 2 weeks before it was due. Yeah, she's like, I got a vision. And it worked out wonderfully. She was right. But I remember thinking like, I'm gonna step away for a couple days, see what's going on. Yeah, yeah.

Well, you should talk about radar charts.

There is radar chart problems too, yes.

Yeah, that almost made me think of my marriage. I've been married for 25 years now with my wife. I think we are quite complementary. There are some things I do that just drive her crazy and nuts and vice versa. But I can see how you can be very, very scared. Oh my goodness, what are you going to do? It's time to publish. Let's talk about artificial intelligence for just a moment. Everywhere, everybody's talking about AI. I've been speaking publicly now for maybe about 10, 12 years now, the last 3 or 4 years, all we talk about for cybersecurity is AI this, AI that. So AI is accelerating software development, that's for sure. What signals have become even more important? I guess, Elizabeth, if you can tackle like executive governance, decision-making, or risk, and then Joel, maybe engineering practices, learning, and developer workflow and delivery. So the question is, signals have become even more important because of AI. Which, which?

Oh, that's a really good deep question. So, so let me unpack the chain that is going on in my head right now as I unfold that question, which is so incredibly deep. If you're an executive, and you're getting all of these signals everywhere that what everybody else's organization is getting 10x productivity from these AI tools—

There is the FOMO, fear of missing out, I think is playing a a big bounce right now.

Oh, FOMO is definitely playing a huge thing. Or, or you're an executive, and both things can be true simultaneously, but I still want to go to— or you're an executive and your company is making a huge investment, your token costs are through the roof, and you're starting to wonder, what value are we getting? In both cases, they're, you know, the, the fear of missing out on the value, or the fear that we have just spent an enormous amount of money and are not yet seeing the value. So this is all unfolding in my head as I think about your question and what signals, as an executive, should you be looking for to figure out what potential value is there? And then to figure out if you make an investment, are you actually getting the value? And I think that one of the things that I've been seeing happen— I will make fun of token leaderboards all day long, because that was the worst signal ever. Or executives in positions of power where we're saying, "Our organization isn't adopting fast enough. So therefore, we're, we're going to put an incentive, and we're going to see, are we adopting fast enough?" But tho— that— those signals were not tied to the ultimate outcome that they wanted. And so I think that, as an executive, you actually probably should not be changing which signals you're looking at so much that you lose sight of the outcomes that you're trying to get to, regardless of the tool chain that you're using to get to those outcomes.

Business outcome. That is so wonderful.

What would you add, Joel? I'd probably echo a lot of stuff what Elizabeth said. I think what's interesting is AI has become almost like the solution instead of kind of like the, you know, kind of saying what's in essence the problem we're trying to have. This is where I think a lot of the system tools come back into place because like if your challenge is in the rate of software delivery, if you're putting AI in to make code creation quicker, but the problem isn't code creation, the problem is testing or packaging or reasoning or understanding requirements, then you're amplifying the wrong— you're pulling the wrong lever, right? You're acting in the wrong part of the system. And so I think it comes down to understanding the root of the problem. AI, if you have a legacy system that's hard to reason with, instead of having AI write code, you might have AI inspect the code and you could ask it questions to help you reason about it. So it, so you don't amplify the wrong problem. So I think it comes down to, you know, kind of understanding the outcome you're going for, just like you're both saying, but then also understanding where your problem is to make sure you don't amplify the wrong area.

I love it. So we are already running out of time. I can't believe this. It's like we just got started. My goodness. All right. So let's do this lightning round on the book, at least the content. I will definitely make sure to write a great review when it whatever it comes out. So, lightning round. Give me whatever comes to your mind as quickly as you can. Don't elaborate, don't think like a professor, just give it to me right away. Okay, first question. Let's start with Andrew. What do you think is the most dangerous engineering metric? Code coverage. What about you, Elizabeth? Do you agree? Count of PRs. Oh yeah, yeah. What's the most misunderstood DevOps idea, Elizabeth?

Oh, do Joel first. It's, it's— I, I got a tip of my tongue, but Joel, most misunderstood DevOps idea.

I, I think cycle time is— you can have really low cycle time and really high lead time and don't matter. Yeah.

All right, so Elizabeth, let me ask you this one. What is one thing every CIO or CTO you should stop doing tomorrow? Oh, should stop doing tomorrow?

Blaming people. Seriously, it's not helping you, man. It's— well, I mean that in a very gender-neutral kind of way. It is not helping you.

Joel? I would say tampering. Tampering in the kind of classical Deming sense of the word.

Yeah. We talked about it like you put your hand in the house and you just mess everything up. Yeah. Yeah. So what is one thing every engineer manager should stop doing? Monday morning? Joe?

Studying the system, understood. Studying the signals. Elizabeth?

Um, yes, and look at signals that you probably haven't been looking at before, perhaps starting with conversations with your engineers about what signals do you pay attention to, um, to, to, to go beyond what you usually see.

Oh, So let me ask this then, Joel, what is something that Elizabeth taught you while writing this book?

Oh, geez. She taught me a myriad of things. She did this beautiful, deep research in every single sentence. And I mean that in the most kind way. I think one of the wonderful things that she brought and I learned from her was this whole idea of context and context mapping and visualizing context. Context is the cumulative effect of previous decisions. It's just such a great metaphor.

It's amazing. Yeah. Okay, so Elizabeth, what idea from Joel changed your own thinking?

Variability. So the, um, I had encountered process control charts in the 1990s applied in ways that I did not feel actually were useful, and I had dismissed them entirely. And Joel had a very different perspective on Shewhart charts, uh, in particular, and how to use them to see variability in the system and then how to interpret that, uh, and forever changed and grateful.

All right, and I see that the first name is Elizabeth Henriksson and Joel, you are the second name. It may not mean anything, but I was a PhD student, the first name on the paper usually means the most. So this question is going to go to Elizabeth. I think she's the boss for the book. So Elizabeth, the question for you then: the book is written by you and Joel, I think equally. How did you you guys came to speak with one voice? What was that process like? Oh, so iteratively.

I mean, it's a good thing we started from a place of being extremely aligned. Joel and I have known each other for over 15 years at this point, and we knew that we were philosophically aligned. Um, but holy snacks, we, we thought this was going to be like a 6-month project, and 2 years later we finally submitted the fi— the final, um, manuscript that was— spoiler— not the final manuscript.

So it was a lot of So Joel, you kind of answered that a little bit earlier, but when you guys did disagree or were disagreeable, how did you guys come to resolve whatever issue?

Honestly, a lot of Zoom meetings, and we would just, in essence, it's almost like, um, like a Mary Parker Follett thing of like, we were trying to figure out the root of, like, we were going to the same place and we could acknowledge we were going to the same place. And so that we would try and find where, where we were navigating from. And then that's where the conversation would start. We want to get to the same place. I'm going this way, you're going that way. Kind of like, how do we resolve that? We spent countless hours on Zoom going through stuff, drawing, modeling, everything.

What was one of the most challenging chapters to write, Joe?

I think the— I want to say the ending was hard to write, at least for me, because it was we felt like we gave all these solid ideas and now it was like, "Atta konferd." And now it's in your hands. And now what do you need to do with it? I felt like I didn't want it to end. So we have ideas for other books, but I think the ending was difficult for me. What about you, Elizabeth?

Yeah, what about you?

I think it was less at a chapter level and more at an organizational level because these ideas are all self-reinforcing. It is a cloud of interconnected concepts and figuring out how to present that in the linear manner that books require, because they're gonna have pages and pages. It's— if this is a dead, dead tree edition, you can't link from one thing to the next thing. And so figuring out how to sequence it, that's why there were times when I said, okay, I'm gonna do open-heart surgery, don't panic, because I realized that there was another way to lay out the linear progression that would allow that laddering up more effectively.

So powerful. Okay, I know we almost have time. Can I get a couple more minutes before we end? I This is gonna be the last question I'm gonna ask about the book. So basically I have two audiences I care the most about, people from the military and people from Silicon Valley. So I'm going to ask you to imagine you're speaking to three people. One is a Navy lieutenant, so a new department head leading their very first division. One is a new engineering manager, let's say, at Pivotal, and one is the first-time executive, like chief technology officer. So what is one signal it should pay attention to 2, and what's the one lever they can pull tomorrow? So if Elisabeth can talk about the signal and Joel about the lever for the Navy lieutenant, new engineering manager, and new chief technology officer.

I'm gonna confess that I have not been in the military and I am underqualified to presume to tell somebody in that situation about a signal. But instead, I'm gonna answer all 3 at once and say, That the qualitative human signals, the understanding when somebody is hesitating, really paying attention to the emotional overlay in the message, trying to understand what values they're representing when they say something. I think that those signals are underutilized and really important.

Now, I know for first-time managers, that's why I say a new lieutenant to become a division head or department head, there's a lot of, I think, like when you did for the first time, for most people, a lot of doubt, and sometimes they call it imposter syndrome. How would you deal with that, Elizabeth? What would you advise them?

So, I would advise them to honor that internal feeling, but recognize that I call them the brain weasels. They— I, I— brain— we all have brain weasels. They crawl around in our brains and they whisper things to us like, you didn't really earn that promotion. Yeah, they whisper things that are just so devastating. And they come from— I mean, highly recommend therapy. I, I think therapy is great. Therapy is a great way to deal with brain weasels. But even without going to, to somebody else outside, recognizing that is a weasel speaking. There might be something that I need to listen to underneath the, the message, but it's still a weasel speaking, and I can ignore the weasels right now. So park the weasels long enough so that you don't let the, the, that like defensiveness build up, because then that interferes with your ability to engage with the outside world, outside of your head, the world that isn't listening to the, to your inner weasels.

Now this is not exactly from the book, but, but since, uh, you are a woman and I love the few I think it was in 2014, I was at Pivotal when, I can't remember which company it was, they had an ad about a software engineer, but they had the picture of a woman instead of a man. And some of my friends at Pivotal, they just freaked out. They didn't think a woman could be an engineer. I'm like, "Hey, what about Elizabeth? Are you guys crazy?" But anyway. I'm sorry, I'm having a whole series of responses internally right now.

Yeah, yeah, yeah. Because I was wildly unaware, but that's all right. Keep going with your question.

But I guess the question I am going to ask I want to ask you is, being a first, whether you are the only woman in the room or the only Black person or the only gay or whatever it might be, what would you advise to somebody who is a first, who now has a position of leadership, but now they look around, everybody is a white male and they feel like they don't really belong. But like you say, they are very, very smart. They have all of the credential, education, they can do the job. That's why they were so selected. Just that extra like, ah, maybe I don't really belong here. And I'm sure you've been in many rooms where you were the only female.

100%. And, and I, you know, I, I'm so glad that you said, or the first Black person, or the first— like, because being the only of anything that is, is visually identifiable in some way can, can— or even if it's not, but you still feel like you're isolated— like, that, that is a terrible feeling. So my advice really boils down to number 1, you belong. Like, like those brainweasels— just park the brainweasels and instead remind yourself that you got here for some reason that is valid. Even if, even if you can't articulate it to yourself, just, just remind yourself, I am here because I belong. And it might feel disingenuous. I don't care. I am here because I belong. If you keep telling yourself that internally, it feels so much better than wondering, why am I here and I don't belong. So that's the first thing. The second thing is, so many times I, I know that I was treated differently because of my gender. People made assumptions about my lack of cred— you know, credentials. People made assumptions about what I knew or didn't know. People assumed I was in marketing. I'm actually terrible at marketing. So the assumptions that people make about about you. Internally, I knew you're assuming that because I present in a certain way. And but I learned that one of the weird— one weird tricks is just suspend disbelief and pretend that they're not treating you like that for the reason that you believe, even though they may very well be. But this one weird trick, it allowed to not react, like, so dismissively that I eliminate any possibility of finding a path forward. And so those two weird tricks of park the brain weasels and keep telling myself I belong, and then assume that they would treat me the same way regardless of how I presented myself, and that it's not about inherent, um, attributes that I cannot change, enabled me to navigate in cases that were frankly very difficult, even at Pivotal, but especially in my life before Pivotal.

All right, Joel, which lever you think the young lieutenant first-time manager or chief technology officer should pull?

So it's almost a non-answer. A word and a term that Elizabeth and I stumbled on in the book was this idea of pausation. And so pausation is intentionally not making a decision because you should not make a decision right now. There's that famous saying, even if you choose not to decide, you still have made a choice, right? But like, this is— I think the reaction is for a lot of executives, whether they're new or seasoned, is see problem, solve problem. Sometimes the best thing to do is just take a step back and say, you don't need to solve it yet. Is it an anomaly? Is it just the way things are right now? Is there something else? Causing it. And I think that, that, that pausation— pausation is a lever. Saying, I'm intentionally choosing not to do something right now, that is a powerful level.

So powerful. Because I think most of us, we kind of just automatically react to whatever's happening. We don't take time to actually think and respond. That's so, so powerful. Okay, I know I've already used too much time. We need to shut down this podcast soon. But I do want to ask about Jim, because he is a living legend in my book. Uh, Jim Kim wrote the foreword. No, his work has shaped how many of us think about flow, DevOps and organizational performance. And by the way, I'm trying to get him on this podcast. Please, please have Jim come, even if for just 30 minutes, I'm going to be so happy. So how did the idea from Jim really influence Signal and Lever, and where does this book intentionally extend or challenge the thinking established in works like The Phoenix Project or Accelerate? Yeah, I—

can I take this one, Joel? Please, please. I know we're going to wrap up. I'm going to say, I don't think it challenges, I think it very that she's aligned with. And The Phoenix Project is really about the, the key, you know, DevOps principles and agile principles— fast feedback and avoiding single points of failure and so on and so forth— and done in a beautiful narrative style. I remember I had not read the book. I, I found myself on a panel with Gene Kim, so I read the book in preparation for the panel, and I was so upset with myself that I had not read it earlier because it is so amazingly good. Yes. Um, but there is a tie-in. He has a character, Sarah, who I am, I am frankly obsessed with, um, because she's, she's the, the evil villain. And I sat down once with Gene at lunch, at a lunch, and, and, um, was talking to him about, okay, you have to tell me more about Sarah. Yes. Like, what, what school did she go to? What books are on her bookshelf? Because she's the evil villain. But I could tell there was so much more there. And he basically said, well, I don't know what's on her bookshelf. And so we, with Gene's permission, did borrow the character of Sarah and one of the other characters. But, but it's really that scene in our book is about Sarah. And so our book, the fictional company there, Limitless Systems, does live in the same world as Parts Unlimited. You'll notice the limit connection between the names. And I was really hoping to be able to do even more with Sarah in the future, because Joel and I know what our next book is going to be.

Okay, I was going to say next book.

Good. So we'll see how this— how— because the extension isn't— definitely all of the ideas belong together and support mutually, support each other. But also there's a little bit of world-building extension happening. Happening. Yes.

Well, everybody, the book is Signal and Levers, available everywhere books are sold. You can pre-order right now. It's going to be released September 22nd, right? So every good thing needs to come to an end. So as we come to an end, Elizabeth, can you please let us know what can my audience do for you?

Oh, well, I'm so grateful if anybody wants to do stuff for me, but I—

How can we add value Back to you.

I would love to issue an invitation. Joel and I are doing a lightning lesson on Maven tomorrow. It's free. It's a 1-hour session. That's it. Please come. It's an invitation. I would love to see folks from here there.

Completely free and you can sign up and I would have the link in the note of the podcast. Of course, I want everybody to get a copy of the book. The one we're talking about is this one, Signal and Levers. I know it's going to be a best-selling book. Now, can you imagine? I had thought we might have time to actually talk about, explore it, but there is no way. But get a copy of that too. It's available everywhere books are sold. Now, you do have another book that you wrote a long time ago, There's Always a Duck, pretty much a collection of your essays. It's only available on this specific website. Again, I will have the link in the notes. But the one book we want everybody to buy now, I think you need pre-orders, right? Signal and Levers, please. Anything else my audience can do for you? You all are so awesome.

Thank you so much.

What about if someone wanted to hire you? Is curiousduck.io the best place to find you?

That's the best place to find me.

All right, so as we come to an end, uh, let me see, uh, wow, this, this has been better than I actually had hoped. Uh, one last question I, I would like to, to ask before I, uh, let you go, Elizabeth, is knowing what you know now, if you could go back, I would say maybe 17, 18, 19-year-old, what would you say to the teenager Elizabeth, knowing what you know now? What would you have advised her?

Oh, so many things. Um, but the one thing in particular that I, I wish I had, um, been better and more disciplined at that age academically. Um, and so I, I would have a really good heart-to-heart sit-down chat that once, you know, we got over the sci-fi moment of, wait, you're me from the future? What? And why should I listen to you? You must be crazy. Once we got past that, having a sit-down heart-to-heart chat about, all right, let's talk about how college is different from high school. Yes. And what you need to do to prepare. Um, that, that is probably the conversation that I would have had with myself. I wasted so much time, and now I wish I I do kind of wish I had a time machine and could go back and actually have the experience in a very different way than I did. I squandered opportunities.

That is really awesome. And this question is going to be a little bit selfish, right? I have two daughters. I kind of joke, if it wasn't for our family dog, I would be the only male in my household. But this was you when you were 17, 18, long, long, long time ago. What about My daughter, one of them just graduated from college last year. It's really tough for her to find a job with AI taking away all of the entry-level jobs and the age we are living in now. What would you advise a young woman who's about to get started? They want to get into science technology just like you. That's why I like to talk to people like you so my daughter has somebody to look up to. Yes, it is possible, right? So what would you advise a young woman who wants to get into tech and become a vice president, you did in, in this pretty competitive world with AI taking away all of the entry-level jobs? What's your advice for them?

Um, the world is definitely changing, and I totally get the very young, you know, younger— I say very, I'm an old— younger people, graduates who are booing the commencement speakers. Yeah, I get it, but we're in another industrial revolution whether or not we like it. Now that said, I— this is the same advice I would give to anyone regardless of gender or anything else, and that is that, um, the, the skills of being able to think critically and reason about problems and, um, uh, apply logic, as in the, you know, the, the philosophy logic sense of the word, um, and write clearly— those skills were important before they're absolutely critical now because they're how you get your humanness out into a world where increasingly things are being generated by LLMs and how you really leverage AI as a tool as opposed to just kind of letting AI slop, you know, run amok. And so liberal arts classes turn out to be really important for people who are going into STEM. Honestly, it was always true, but it's even more true now. And I love philosophy majors. Yes.

Wow, that is a great, uh, place to end. And sorry I've taken so much of your time already, but I would like to end on a positive note. Anything that you are feeling optimistic about these days?

On my good days, I am optimistic about our future because I do genuinely believe that we are going to be capable of doing things that we never thought possible before. Through the appropriate application of AI as a tool, we'll be able to reach farther. Those are on my good days. So I'll say today's a great day, and I'm optimistic about our future as a species. Fantastic.

I love it. OK, last question, one word that you to present our shared experience on this podcast today, including the time we had with Joel?

One word? Amazing. Wow, that means a lot coming from you.

Well, I am so grateful. The one and only Elizabeth Henriksson, thank you so much for being our master teacher today. And I hope to see Joel here live for an hour. I wanna talk to him, but this is just wonderful. And help me get Jim here, please, please. I wanna talk to the legend, the man, The myth, that's gonna be— because part of the reason why I am doing this, about 5 years ago, it's kind of like, I'm like, okay, I've already, you know, attained my American dream. I started in the military as a seaman recruit, E-1, lowest level in the military. Today I'm a commander, if you can believe that. No, senior officer in the most powerful navy in the world, only 2 promotions away from becoming a flag officer, from being an admiral. I can't even believe it myself. And of course, when I started, I think people Vital was the first one when I came to Silicon Valley. I was a senior security engineer there, but my last job, I was a chief information security officer for Santa Clara University. So anyway, I've done everything I wanted to do. So right now I'm really trying to think and focus on the future, right? We're talking about the future, the future military leaders, the future CISOs, the future tech, the future VP of R&D in Silicon Valley. I really want them to get those leadership lessons from giants and legends like you. So that's why I feel like this is so important to do. I only have 1 hour with you, but thank you for giving me an extra 17 minutes. I really, really appreciate that. So I'm so grateful. Thank you again, Elizabeth. Really a great pleasure to be connecting with you.

Thank you so much. I'm so grateful to you.

All right, everybody, I want everyone to get a copy of the book. You can preorder it today, Signal and Levers, everywhere books are sold. System Thinking: Tools to Unblock Software Delivery by Elizabeth Henriksson and Joel Tosi. So, everyone should get a copy. Let's help make it a bestseller for sure. And also, follow Elizabeth on LinkedIn. So, that's linkedin.com/testobsessed. I love that moniker. And her website, if you want to hire her, curiousduck.io. And tomorrow, there's going to be a free, completely free webinar, which is gonna give with Joel. And the way you register, just go to maven.com/signalsandlevers, and you're gonna be able to register and attend the webinar for free. I hope to see you there. Okay, as we end the show, I want to remind you that tomorrow I will have two interviews. First, I'm gonna be speaking to Shakita Trigg. She's a certified AI consultant, AI and technology technology architecture executive. Uh, you don't want to miss this. And then, uh, later tomorrow afternoon, I will be speaking to a fellow commander, US Navy Commander Arthur Billingsley. He's now a business leader, a strategy executive consultant, and this is going to be a great time. We're going to be talking about leadership principles that help them achieve the success they have, uh, so far. And, uh, as we end the show, as you know, I love to end with, uh, what I call, uh, Black History year because I felt like 28 days is the shortest month in, in the year. It's just too, too, uh, too short. So today our profile in Courage, uh, we are celebrating the life and the legacy of Lawrence Brooks. And Lawrence Brooks is really America's oldest known World War II veteran and the nation's oldest living man when he passed away January 5th, 2022, at the remarkable age of 112 years old. When he joined the Army, the Army was segregated. Black and white didn't mix, and Black were inferior to white back then. So we've come a very, very long way, and I do feel like I do stand on the shoulders of giants. There would be no Commander Bob Fabien Zinga in the Navy if there wasn't a Private Lawrence. So I want to honor his life. So I'm going to play this quick video to honor him, and then we are going to meet again, I hope, tomorrow. Let me make sure I get this. Oh, sorry, I thought this was already set up. Okay.

And it's not just the White House. Professor Holland tells us enslaved enslaved labor was also used to build the United States Capitol, the very seat of democracy, including the iconic dome.

From the bottom floors all the way to the Statue of Freedom sitting on top, it would not be there without the blood, sweat, and tears of enslaved Africans.

In fact, between 1792 and 1829, more than 200,000 200 enslaved individuals helped build both structures, though experts believe it was many more.

It gives us a little bit of ownership of the president's house because it's written right here.

It's unbelievable. Professor Holland took Ashley and Jackie around the Capitol.

This mall was nothing like we see today.

To help them envision what it looked like some 200 years ago. Back then, Washington, D.C. had become a hub of the domestic slave trade, a place where human beings were bought and sold in the shadow of the nation's most powerful institutions.

All of this was more of a slave market. There were slave markets over on Pennsylvania Avenue, and despite it being the nation's front yard, Enslaved Africans were brought down to this area and were sold. One of the more famous places they had slave sales was over near the Smithsonian Air and Space Museum. It's called Robie's Tavern.

Back in the day, slave pens and markets would have been seen on both sides of the National Mall. For enslaved laborers like Calvert Ambush, there were also no formal accommodations.

The slaves that were used in the construction of the White House, they of course didn't live in the White House. Yeah. They lived right outside. All of the area you see behind us when they were constructing the U.S. Capitol, it was actual slave tent city.

Enslaved laborers split the stone at nearby quarries, transporting it upriver and towing it to Washington, where they built Roofs, walls, and columns.

Oh, freedom!

Oh, freedom!

Oh, freedom over me and before I be I'll be buried in my grave and go home to my Lord and be free. Oh, freedom!

Give me liberty or give me death. The act of moral unity has come! The advent of justice— We at last, we at last, we at last thank God Almighty! Yahweh Adonai!

Yahuah Shaddaaayyeh! Very Merry Christmas to all you people who love Jesus Christ! And be free.

Thank you for tuning in to the Leadership and Success Podcast with your host, Coach BZ. If today's episode added value to your leadership journey, be sure to subscribe, share, and join us again for more wisdom nuggets on how to lead better and achieve greater success. Remember, leadership is the most a critical skill of our time. The world will always need leaders to inspire others, drive innovation, and execute meaningful strategy. So why not count yourself among the bold leaders shaping the 21st century? Until next time, stay inspired, stay committed, and keep leading with excellence.