The story behind why some organizations win big and keep on winning.
This week, co-host Conor Bronsdon interviews Dr. Steven J. Spear, renowned MIT senior lecturer, founder, and author, to discuss the core principles from Dr. Spear's new book with Gene Kim, Wiring The Winning Organization.
They delve into why some organizations consistently outperform others, highlighting how the best organizations create systems that enhance problem-solving through slowification, simplification, and amplification, aligning processes with cognitive strengths.
With case studies from NASA's Apollo missions to Apple's smartphone market dominance, the book is a must-read for those looking to harness collective ingenuity for exceptional achievements."
Episode Highlights:
- 02:00 Inspiration behind the book
- 05:30 Social Circuitry
- 10:00 Applying system thinking to leadership
- 16:30 The 3 Mechanisms
- 22:30 More insights from the book
- 26:00 Lessons for engineering leaders
Episode Transcript:
(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
Conor Bronsdon: Hey everyone. Welcome back to DevOp. Did. I'm your host, Conor Bronson. We're here at the DevOps Enterprise Summit.
in the Dev Interrupted Dome, and I'm excited to be joined by Dr. Steven J. Spear, a senior lecturer at MIT, founder of See to Solve, and co author of the upcoming release with Gene Kim, Wiring The Winning Organization. Welcome to the show, Steve.
Steven J. Spear: Oh, thanks for having me. Yeah, I'm really glad to be here.
Conor Bronsdon: I'm glad you could bear with me while I flubbed the intro like three times here.
You didn't laugh too hard, which I appreciated. And I'm really excited to have another author on the show cause it's honestly been a while and this isn't actually your first time writing a book either. You also previously authored the book, The High Velocity Edge, right? What did that teach you about writing books that you've applied now to Wiring The Winning Organization?
Steven J. Spear: Oh yeah. Thanks. First of all, I guess one key lesson is work with Gene Kim. It's a very good experience, last time I, solo authored and anyway, that's a whole separate story, but lemme tie it back to content. Both books, both wiring the winning organization and the high velocity edge, which proceeded it come outta the same motivation is that I came a professional age in the late eighties, early nineties when, japanese companies were posing this existential threat to American competitors. And I was one of many people who are trying to understand what they were doing different that on any given day, those organizations were able to generate and deliver so much more value into society than their American counterparts.
And what I came to appreciate after years of study and immersion in places like Toyota. Was that the winners had created far better conditions for people to give fuller expression to their ingenuity, their creativity, their minds, internal capacity to solve problems in front of them and then have those individual efforts harmonize and integrate in a beautifully choreographed fashion into collective action towards common purpose.
In terms of, your question, what did I learn from the High Velocity Edge to the Wiring the Winning Organization. The first book was based on my work with industrially intensive organizations. Toyota is at least half the book. Alcoa is a major case study in there. And so in that book, I gave a lot of expression to the design of linear processes.
And how they can be designed to make it easier for the individual to understand where he or she fit into the larger whole. Accomplish their work in such a way that when it's passed on as a intermediate input into the next step, those handoffs and exchanges are very good. And also, around this idea that anything we design is going to glitch at some point.
This idea that not only do you have to design things with your best understanding, but you have to design them so they reveal a very... Quickly and early and often that something's going wrong. So in that book, I called this idea design things so that you can see problems. So it quickly triggers this response to solve a problem.
And you mentioned, I appreciate the mention of the software we've designed. And it's built and actually our company is called C2Solve. So it's around that. So making the transition into wiring is that working with Gene We shifted, I wouldn't say shifted, we expanded our area of concern from processes which look industrial in that they lay out in a linear fashion, sequential fashion through time and expanded to worry about things that spread out over space, technical systems.
What we discovered, and I think it was, fabulously exciting and validating, is that the same issues exist, that how you create the conditions as a leader, the conditions you create for those people for whom you're responsible, fabulously affects their ability to bring their ingenuity to bear on the problems which you as a collective are trying to solve.
Where we went with this is that we had a better appreciation that we're designing around the minds of human beings. And that we have to worry not only about things which exist spread out over time, but which are spread out over space.
Conor Bronsdon: I think that's a wonderful insight because so many people hear phrases like organizational system design or system design and they simply think, Oh I'm designing a technology system.
They don't think about the people that are leveraging that system or the people that make up these organizations. And high performing teams need the right conditions to deliver. So what did you identify that was so similar for these high performing teams across? Both manufacturing and these other styles of teams that you mentioned.
Steven J. Spear: That's right. Yeah. Great question. In the book, we introduced this notion of three layers at which people express their ingenuity, their creativity, and that sort of thing. And again this was a very important insight in writing this book, which I hadn't realized in the first one. And is this the three mechanisms of performance?
So it's on the way to those three mechanisms, 100%. The first layer is the object. in front of the person. Literally that could be, a ball valve or a submarine hatch sitting on a benchtop in front of a mechanic who's tasked with fixing that thing. More modern technology.
It might be the the genetic code, which is sitting someplace that someone is trying to manipulate to deal with an ailment, fix a disease, that kind of thing, or the code itself that your community worries about. So that's layer one. And the capabilities and concerns on layer one are very technical engineering concerns.
Layer two is the instrumentation through which people work on the object in front of them. That that mechanic who's working on a ball valve or a motor or whatnot, it might be the The the tooling, the machining that they use to deal with voids and pits and that kind of thing.
For the person working on DNA, it might be the CRISPR technology that allows them to manipulate that. And then there are the tools that you use in the software world to affect the code. So that's Layer 2. Also, very technical, very engineering very scientific. This is when we get to Layer 3. Is that Layer 1 and Layer 2, we can imagine the individual using that instrumentation on the object in front of him or her.
When we get to layer three, what are we worried about is we're worried about the processes, the procedures, the routines, the norms by which all those individual efforts at all those literal and metaphorical benchtops, how all those individual efforts integrate into this collective action towards common purpose.
In the book, we refer to that overlay of processes and procedures as Circuitry, SocialCircuitry. And we use that term circuitry not metaphorically, but really deliberately. You start thinking about what a circuit does, a technical circuit. It takes something which is in high concentration in one location, but where it's not needed.
Let's say charge, and it allows it to flow efficiently, effectively to where it's in low concentration, but actually needed. And when, and sometimes the circuitry is exists not to just allow for the flow, but allow things to mix and commingle and react, whatever the case is, you're thinking about why we have processes and procedures and organizations is that you're working on something, Adam's working on something, Brett's working on something, I'm working on something and we're all doing good work.
But that individual work is necessary, but it's not sufficient to achieve that common purpose. And it's by the way in which the work we're doing becomes coordinated, collaborative, integrated, harmonized, choreographed, that determines whether we're successful or not. When we wrote Wiring, we were very concerned about guidance on how to design that social circuitry, that Layer 3 overlay of processes and procedures, so that people...
Can invest their ingenuity on the hard problems in front of them for which society will value the solutions and not in a poor, poorly designed or poorly wired organization. Spend so much time, so much ingenuity, so much emotional energy just trying to figure out where they fit into the larger whole that they have little energy left over for the the hard problems in front of them.
Conor Bronsdon: I'm really interested in this concept because we talk a lot about this amorphous idea of, team culture, team dynamics. And the social circuitry of a team seems like a great way to describe it. Honestly, I plan to borrow this phrase and use it repeatedly. I'll try to reference you back, but don't worry.
Please do. Can you dig more into what you saw the most high performing teams do as far as constructing that social circuitry?
Steven J. Spear: Yeah. For technologists, engineers, scientists, there's a tremendous deliberate concern with the architecture of the objects on which they're working, the design of the circuits on a chip, the design of the codes.
In a larger software package the shape of the teeth on a gear so it meshes properly with the the apparatus into which it's inserted. So there's a lot of concern about that architecture. And certainly there's a lot of concern with the architecture, the design, the operation of the instrumentation with, through which people work.
What's an un, what's a missed opportunity too often is a similar. Engineers concerned for the design, the operation and the improvement of this social circuitry that determines how people will work together. And what ends up happening in the absence of having a simple first principle based way to think about the design of the social circuitry, because we have those, right?
We have principles we use to talk about the design of the object and the instrumentation. But in the absence of being able to talk in a first principles, I'm sorry, a first principles way. About the design of the social circuitry overlay, we get stuck with some things like trust is important.
It's yeah, duh, trust is important. If I think you're going to stab me in the back, I'm never going to turn my back on you. Respect is important. Again, yeah, duh. If you walk into a situation, you think I'm going to be insulting and ridiculing. We're not going to, those are all given.
But, those fall into the category of things I learned in kindergarten. Yes, they're important, but important in an obvious way. What's important in a less obvious way is this methodical, deliberate approach towards designing process and procedure with due full consideration, in fact, almost as an objective function consideration for how people's minds work.
And the type of problems they can solve well, the type of problems they can they struggle with, and making sure that the circuitry is designed with that consi those considerations in mind.
Conor Bronsdon: What's an organization that you think does this really well?
Steven J. Spear: Alright, so look, I'm gonna have to root back to Toyota.
And, I know, people may be listening. I've gotten this for now 30 years. Oh, we don't make cars, so bear with me a little bit. But, when we start off the book and say, who should read this book and why, we talk about how important it is for leaders to read this book if they want to understand how to put their organizations to the front of the pack.
And so here's what I mean, and this is why I think Autos is actually a very good example. And again, for the people saying, oh, we don't make cars, just understand. A car is about as complex a technical system as exists. The millions of lines of code that sit on a Prius is actually, way beyond.
I think what happened is most anyway, I'm gonna stop making the case for cars. If you don't like cars you, you've dismissed me already. But anyway why do we look at that? Is one of the points or the opening points Jean and I make in the book is that when you have level playing, field competition, your organization and mine are looking more or less at the same market space. We're looking for the same and probably finding similar market opportunities. We're depending on the same resources for capital equipment, raw materials workforce. We're operating under the same set of rules and regulations, right?
It's a very level playing field. And yet what we see is some organizations which, given all that commonality of input, all that commonality of challenge, The differences in output are extraordinary. They're just like crazy. And this was certainly exemplified back in the auto industry in the 1980s when people were worried about Japan an existential threat.
But the, and the numbers then, just to, anchor this for people, what people were, what was being observed is that in the production of automobiles, which is a very difficult thing because the factory that you have to design and operate... Involves thousands of people doing this choreographed work to get cars coming off the line every 50 seconds.
Conor Bronsdon: And increasingly automated, all these new technologies bringing in IoT, all this stuff.
Steven J. Spear: Absolutely. This is a non trivial problem to get an auto factory to make one car, let alone one every 50 seconds. Look at how many car startups fail. That's right. Bingo. Apropos of this level playing field competition, but non level playing field outcome.
So when people first started looking at the the auto industry, they said, holy cow, on any given day, everyone performs about the same level of productivity, effectiveness, efficiency, except this handful of factories, which produce twice the cars with half the people and half the time, half the resources and half the space.
So I don't know if that's 2X, 4X, but whatever it is, it's a lot. And then when they started looking at design they said, Oh, wait a second, everyone takes more or less the same number of calendar years and number of engineering years to design a new model. Yet there's these exceptions to the rule with half the people and half the calendar time.
They generate twice the designs and the designs are better both for manufacturing and market appeal. And here's the thing, stepping out of autos, you start seeing the same ratios. Of exceptionalism across these multiple dimensions simultaneously, quality, productivity, safety, and workplace safety, security for data time to market, product variety, product response, resilience, agility, reliability, and so on.
All concentrated, all great concentrated on one or two organizations in the sector and everyone else. This is in healthcare, it's in education, it's in IT, obviously. So anyway what seems to be, that's a huge elaboration when I look at cars and the examples. So when I look at Toyota, it's cause they're in about as competitive a field as exists in the world.
And not only do they have leadership on, Nearly every important dimension, but they've maintained that leadership for 50 years. 50 years. It's like, all right, I know the Boston Celtics, they won a lot of championships over a period. The Lakers won a lot. The Yankees won a lot. The Patriots, obviously, I'm from New England.
I gotta, throw that in. Wow, you're a Patriots fan? I'm sorry. I know that lands badly with the West Coast folks.
Conor Bronsdon: I'm a Seahawks fan, so it was just a tough year a couple years back. Yeah, that was a tough Super Bowl.
Steven J. Spear: So for what, as an aside, I wrote up a whole case study around 2015 about the Malcolm Butler interception.
Oh, okay. And we'll probably read that later.
Conor Bronsdon: Yeah, I'll check that out.
Steven J. Spear: I hope you're not poisoning my water now. But a 50 year dominance in a field with that level of competitiveness? Incredibly hard. You gotta say, what the heck is going on there that's not going on elsewhere? And again, tying back to my first research going back to the 90s, is what we found is that Toyota had created an organization which was a knowledge factory.
They had designed their systems. In such a way that the systems themselves, the systems of moving material and producing parts and turning inputs into outputs were deliberately designed around, designed towards the cognitive strength of people and away from the cognitive weaknesses. And with all the problems involved in building a factory, launching a model, running a factory on a day to day basis the environment was such that people's minds can be more fully engaged individually and collectively on solving those problems.
Whereas you went into their competitors, it was just so overwhelming, confusing, and frustrating that the human intellect had very little ability to give itself full expression.
Conor Bronsdon: So it sounds like you're saying something which I think we've seen in a lot of research recently, which is that... High performance is predicated on cutting down on friction points, cutting down on distractions, and being able to achieve flow state and really focus.
Steven J. Spear: That's right. Yeah, I appreciate the the notion of flow because in the book we talk about three mechanisms, which if each is end of it and if each is employed, I'm sorry, if each is employed individually. You make it much easier for people, and obviously if you use the combination. Three mechanisms we call.
One is Slowification. And that plays onto the research of Daniel Tversky, Thinking Fast and Slow. Yeah. And creating situations in which people can engage their slow, creative, deliberative, generative thinking, rather than having to be in a fast thinking, impulsive, reactive kind of modality. So that's one.
Then we have this third mechanism we call Amplification, which is to make it more obvious that problems exist to be solved in the first place. But within, sandwiched between Slowification, which is to make it easier to solve problems, and Amplification to make it more obvious that problems exist, we have this thing called Simplification.
And Simplification is to actually change the nature of the problems, so that the problems themselves are easier to solve, that the piece in front of the individual is more tractable uh, understandable, so on and so forth. And that way, as the pieces come together, they come together more simply.
Anyway, the reason I went into that is you mentioned creating flow. It turns out within this simplification mechanism, creating flow across functions, across departments, across specialties, so that things have a more sequentiality to them. As opposed to having work jump back and forth move over here, move over there, get passed to this department, this division, this function, this subject matter boom.
Just line the, the work, the people who are expert at doing that work, lining them up so it can be this baton pass of value as it accumulates. Turns out flow is a critical technique within this idea of wiring organizations around the cognitive strengths and away from the cognitive weaknesses of people.
Conor Bronsdon: Makes total sense. Reducing context switching, letting people focus on these things is really crucial. And I know that we've seen it in software development, continuous continuous growth, continuous implementation, continuous delivery, these things where we say, okay, let's take a process, let's apply workflows to it, let's iterate on it continuously, and create this like knowledge capture mechanism, which I know you talked about and I want to dig into where you can then say, okay let's create an iterative process that's going to work continuously for folks and hopefully continue to improve.
I know you mentioned this in the book as well, this knowledge capture piece that's saying we're learning from our mistakes and we're continuing to grow, reducing the friction points. Can you dig into that a bit?
Steven J. Spear: Yeah, absolutely. Look, the baby, when we wrote the book, we said, look, the, why to read the book is you're leading an organization, which has accepted onto itself a mission and you want to succeed better, faster with more certainty than not.
All right. So that's why I read it. We have this kind of rhetorical question, which is why do we even create organizations in the first place? And again, it's to accomplish mission. But why an organization? Why don't we do that individually? And the reason is there's more work to do than any individual can ever hope to accomplish, right?
When we start talking about projects, the the hundreds of thousands of engineering years involved in designing something, right? It's not like you say I'll do it myself. It'll just take more time. No, I don't have thousands of years. I have a few. As we start talking about this why we create organizations because there's more work than an individual or small group can do, but there's a key point here.
It's not just the heavy lifting, like you grab one end of the couch, I'll grab the other end of the couch. It's the problem solving. In the book, we have a couple of vignettes to illustrate in very simple terms. The the largest class of problems in the first vignette is about two guys, Gene and Steve, trying to move a couch.
The point we're trying to make is that even something as familiar as moving a couch... is not entirely a brawn problem, it's a brain problem. That the, part of the reason you have Gene and Steve moving the couch together is, yes, Steve has to lift one end and Gene has to lift the other.
But part of the reason you need two people involved is there's questions about balance, there's questions about navigation, there's questions about grip points, there's questions about how do we go up the stairs and down the stairs and in the, out the door and through the narrow hallway, right?
There's a lot of problems, and I think anyone who's ever had to move from their first apartment to their second apartment to a dorm room to a... House. It was like, Oh yeah, between, it wasn't just, the muscles I brought to this, but it was the problem solving and my ability. And there's another part.
Conor Bronsdon: I've had to host a hoist a couch out a window and down off a balcony. You gotta do it.
Steven J. Spear: Yeah. And yeah, I once had a refrigerator down the slope roof. So we're talking this and you realize that your ability, whether it's the couch off the balcony or the refrigerator down the slope roof. And part of it depended, did you have this sort of the horsepower to, control the couch?
But part of it is were you able to work in a collaborative, problem solving, creative fashion with the person on the other end of the couch or the refrigerator? So no one got hurt. No one got crushed. That's right. Absolutely. And you're here, I'm here, so I guess it worked out well. Yeah, it worked out. We don't know about the other two guys.
Maybe they're on the other side, right? Yeah, I'll stop talking about that, okay? Yeah. Fine. But, WHat we're setting up is that really we form organizations because it's not just the brawn work, which is more than one person can do, it's the brain work. And if it's the brain work, which is more than one person, then we really have to be quite deliberate and thoughtful.
Conor Bronsdon: And this is really interesting because it does correlate to a lot of other research we've seen. So we talk about thinking fast and slow is a great example. Another great example is the research that's been done around teams that are high performing and the importance of diversity of ideas. That's right.
Bringing in these different voices and then maximizing that for creativity. Getting these massive productivity gains. You pointed out design as one area. That's a huge opportunity.
Steven J. Spear: 100 percent on that. Again, it's I don't know if it's a parable, the notion of the blind man trying to describe an elephant and the person with the limited perspective describes the elephant as a foam pole because they grab the leg versus a snake because they grab the trunk or whatever.
tHe way that story is told, it's those poor people who can't see well. Like somehow the seven blind people trying to describe the elephant, a normal person could, someone who had normal sight not vision problems. But the reality is we're all blind.
And I think that, we have, if we start with the acceptance that none of us can see and understand the whole. And that the life, our life is nothing but elephants. And we're all blind about the elephant. Then what we have to do is create systems in which we're set up for each of us to take our imperfect and incomplete understanding and have that synthesized together to a much better whole.
Conor Bronsdon: Look at every founder we talked to on this show every great leader. They talk about the importance of hiring great people and putting them in a position to succeed. And that's exactly what we're talking about at scale. And consistently. That's right. I'd love to dig in a bit more and say what are the other insights that people can expect when they read the book?
Steven J. Spear: Yeah. You mentioned founders and leaders and we create this this notion of the iconic leader who's All seeing and all understanding and that kind of thing. Remember many years ago I had a, there was a kid in our community who was a big fan of Bill Gates and he said, Oh, Bill Gates reads every line of code.
It's really? The boy's name was Alec, AJ. So AJ, let's think about this for a second. How many lines of code are in, and this is way back, right? So it was far less than today. How many lines of code are there? It's, X gigantic number. And it's alright, how long does it take to read one line of code?
Now let's do the math here. How long would it take them to read every line of code in just one package? It's like forever. How many packages do they have? A lot. So it would take a lot forever. Alright the thing is, whether it's Bill Gates, Steve Jobs and others, we've created this mythology about the leader who's it's their mind and it's the action through everyone else's hands.
But it can't be the case. Just like with Toyota having a 50 year dominance in its industry, you can't have a company like Microsoft, which has had such a massive presence on a worldwide scale for so long, or Apple, which has had such disproportionate impact on how we think and live and interact with each other.
It can't be one human brain acting through all these hands. It has to be, it has to be. That Bill Gates and Steve Jobs and some of these others where the organ and again, that's the point. The organization has endured way beyond their active involvement in it, right? So even if it was, let's entertain for a moment.
It was, oh Bill Gates or Steve Jobs was such a genius, right? He's not there anymore, though. And hasn't been for a long time. What they did was they were fantastic architects and yes, probably initially fantastic architects about the technical object, that's layer one thing, but fantastic architects of layer three systems and processes and culture inside those things that so much greatness could be produced with their influence.
Now, tying that back to, where does this matter is I think, unfortunately, a lot of people come into jobs. For their technical expertise, and they build up their technical expertise, and they display and express that technical expertise, and that's fantastic. At some point, though, their responsibilities migrate from level one and level two concerns, which is the technical expertise, to layer three ones, which is responsibility for other people.
And for that, they think, oh, my job now is to be the chief decider. I have to gather data. I have to do the analysis. And that doesn't scale. And the other thing is, if you start thinking about how we express our expertise, our technical expertise on Layer 1 and Layer 2, it's by solving problems. And no problem gets solved by, oh, I look at the situation and I generate an answer.
No, I look at a problem and I experiment and I have experience and I iterate and I do all these other things to converge on the answer. I think one of the things we want to accomplish with this book is say to leaders of technical organizations who used to be technologists themselves is the approaches you used before to get to good answers are exactly right.
You want to simplify the problems in front of you through modularization, incrementalization, we talk about that in the book. And you want to slow down the problem solving so it's easier to solve problems. You want to make it more obvious you have problems. Everything you've been doing... You want to keep doing.
The only thing you want to change is your focus from the technical system to the social technical system shift from layer one and layer two to layer three. But if you take the same behaviors, the same disciplines up to layer three, you're likely to succeed. On the other hand, if you think it requires a different set of behaviors and assumptions and approaches, then you may be setting yourself up for less than success.
Conor Bronsdon: So if I'm a leader I lead software engineering teams and I'm trying to apply these lessons to my own team. I should apply that same systems thinking that I've applied to my success as a technical leader and my growth into this role to the social circuitry of my team.
Steven J. Spear: Yes, that's absolutely right.
Conor Bronsdon: Are there key pieces of that social circuitry that are of that social circuitry that you should focus on first?
Steven J. Spear: Yeah. One of the temptations when people's focus moves from a layer one and layer two technical turn. Technical Concerns to Layer 3, Social Technical Concerns, is that all of a sudden now they have to worry about metrics and reports and meanings about the reports which would capture the metrics and this and that, and that's not actually how we engineer.
The way we engineer is we build something, and we run it, and when it glitches... We respect the first glitch, right? And it may be a local glitch, it may be a little glitch, but the fact that it glitched is a very strong indication that whatever we designed is behaving differently than we had expected or hoped.
The encouragement when we wrote the book is that leaders will have a similar sympathy, empathy, respect for the individual in their organization. That the person who's struggling because the materials they need, the information they need, the documentation, the paperwork whatever it is that's missing, where they're glitching.
And the evidence of glitching is they sit down to do work and then they have to start foraging for things. They sit down to do the work. And they have to work around, they have to firefight they're frustrated that the glitch the individual is experiencing is evidence, and loud enough evidence.
That the social circuitry is failing that individual, and if it's failing that individual, without doubt, it's failing other individuals. And you don't have to sit back, wait for the lag, the aggregated data, and the report, and this thing, and have a meeting, and a quarterly review, to know that the system is not working.
You can just go to the shop floor, go to the deck plate, go to the lab, go to the studio, wherever it happens to be. And if I see Conor struggling somehow... I don't have to look further. I know the system is failing Conor, and if the system is failing Conor, it's probably failing Adam and Brent and a whole bunch of other people too.
Conor Bronsdon: How do you differentiate between a system that's failing team members versus a team member that isn't the right fit?
Steven J. Spear: Yeah. So it's funny, I'm gonna route back to my Toyota thing, is that those are like system thinkers extraordinaire. . When they walk into a plant, let's say, and they see a, an associate go over to do, let's say install a seat.
And it's not easy to grab the four boats that bolts, that affix the seat to the frame, alright? The system failed the employee if they reach for a torque wrench. And the torque wrench is not easy. And ergonomically, safeToUse, etc. Alright, but here's what they'll also say. If they see an associate trying to put the seed in and the material is all there and everything is nicely presented, and they struggle, their first response is, Damn, the system that trained that person, it failed them.
Because it put them in a situation for which they're not yet competent. IN the extreme and the exemplars for them everything is a system problem. The fact that you're sitting there struggling, it's like who trained you? You know what system failed? And this is an interesting way, right?
What system which I as a leader was responsible for? What system failed you as an associate that you're put in a situation for which you're unprepared? What system didn't give you the adequate skills? What system gave you the wrong assignment, et cetera. Yeah, the one thing I'll just offer as generalizing this, is this notion of thinking through systems is actually unencumbers people, because, the setup for your question is, if I see someone failing if I don't think about systems, then I'm now in a situation where I have to blame the individual, and if I blame the individual, then I have to confront the individual.
And what it does is it inadvertently generates A culture of contest and disagreement and maybe victimization, objectification, blameification, however you want to call it. But if we're always thinking about systems, then we always come back to we have an engineering, we have an architectural problem to create the system in such a way it supports the individual.
Rather than blame the individual, we use the individual as the The early indicator that the system itself is inadequate to the tests assigned onto it.
Conor Bronsdon: So by that logic, if we eventually decide, actually we do have to let this individual go, the blame is likely on the hiring system.
Steven J. Spear: Yeah. It's really, again, it reminds me back of Toyota when We were at the oh, it was the plant in Indiana.
And I think I talk about it in that first book, The High Velocity Edge. They were screening people. And they were screening people to be trained to work on the assembly line. And what they had done is they had taken over the gym of a building that had been a high school at one point, and they had set up a mock assembly line, and it was truth in advertising.
People who wanted jobs who were new recruits, they'd come in, and they'd spend some number of hours working in this mock up of an assembly line, so they understood What it looked like and felt like and what the demands were and what the necessary skills were, etc. etc. And there are people who, halfway through one of these simulated virtual shifts, said, I don't want to do this.
They left. But there were people who not only made it through the shift, but they displayed a certain aptitude and acumen for this type of work. But it still turned out that even then going into the training, A surprising number of these people washed out, and what they realized is that it wasn't whether a recruit and a potential hire.
made it through one day of the simulation. It's whether after going through the first day, they came back on the second day. And what they did is they Kaizen, they redesigned this screening process from one 10 hour shift to two eight hour shifts. And what they found is that if, someone came back on the second day to do the second eight hours, that person had a much higher likelihood of then going through the training and being ready for the assembly line work but if they didn't come back on the second day, that was a good message both for the Potential employer and the potential employee that this was a bad fit.
Conor Bronsdon: Interesting. Steve, this has been fascinating. I've really enjoyed the insights from your book and I can't wait. I can't wait to read Wiring the Winning Organization by you and Gene Kim. It's going to be a really interesting read and I can tell there's a ton of insights in here. Do you have any closing thoughts you want to share with our audience before we wrap up?
Steven J. Spear: Yes, thank you. First of all, thanks for the time and being able to have this conversation. You invest, as much time in the field as I have to feed the ideas and then the, the intense collaboration to write this book. wHat we try to accomplish for this book is for people who have been or just maybe even just finding themselves right now responsible for other people.
There's a way to think about the problems in front of them. That the solutions are a matter of creative, creatively applying some simple principles. Recursively onto situations. To get to good outcomes. And that's actually a good, for those who studied engineering, that's actually very good, right?
Cause I remember when I was studying mechanical engineering. What does a mechanical engineer have to do? Look at all the things that are mechanically engineered. And so I said no, Steve, you got to understand solids. Will things move or spin or not? You have to understand heat. How quickly will something cool off?
And also understand that things that are liquid they're sticky, gooey, and want to get stuck in places. That's all you need to know. Now what you have to do is practice the application on the sophisticated things.
Conor Bronsdon: Build habits of this consistently. That's right. And that's what systems are, really, is they're solving for habits for us.
Steven J. Spear: That's right. And we, what we hope to accomplish with this book is take the mystery and the magic out of the design and operation of these complex Social technical systems and give a confidence and comfort to those responsible other people. There, there's some very simple basic ways to think about the problems and the issue is not mastering more and more concepts.
It's about gaining. Acumen in skill and speed and applying the same basic principles onto harder and more complex problems.
Conor Bronsdon: Steve, thank you so much for coming on. It's been a pleasure and a huge shout out to the IT Revolution Group. Thank you for having us here for DevOps Enterprise Summit, putting this dome together with us, and getting Steve on the show. It's been great doing it, and I've really enjoyed the conversation.
Steven J. Spear: Oh, absolutely. Thank you for the opportunity to have a discussion, I think, about ideas that are really quite important. My pleasure.