Transactional vs. Developmental Leadership

This post is adapted from Wiring the Winning Organization: Liberating Our Collective Greatness Through Slowification, Simplification, and Amplification.

To better see the contrast between transactional and developmental leadership mindsets, let’s revisit NASA’s experience with the Apollo 11 landing (and the missions that preceded it) and that of Boston’s medical community on the day of the marathon bombing.

When asked about what limitations hinder their ability to create and deliver value, transactional leaders will likely be concerned about constraints (row a in Table A.1). They will point out that they have limited resources, which restrict the alternatives available to which those resources can be put to use. For them, the corrective action is to improve resource allocation, either by transactions in a market to get more or better people and more or better resources or by some algorithm (e.g., assign them better for more productive uses), (row c), to achieve some “optimal” outcome as measured by productivity, efficiency, profitability, utility, and so forth, (row d in Table A.1).

 The result is that they are stuck operating within a frontier, constantly weighing what to do with what they have, and why to do it, based on costs and benefits. That is also reflected in Figure A.1. Those with a transactional mindset are constantly doing cost-benefit analysis, trying to determine how much of Need 1 to satisfy at the expense of not meeting all of Need 2, and vice versa. For transactional leaders, their only relief is to add more resources.

We must acknowledge that almost everyone, at some point, is forced into transactional cost-benefit analyses. However, those with a developmental mindset are able to create much better alternatives to choose from than they would have had otherwise. In contrast to transactional leaders, developmental leaders constantly expand the frontier to expand the possibilities (i.e., possible choices) available to them and their colleagues.

Consider how developmental leaders responded to the following danger zone situations of fast-moving, unforgiving, uncontrollable, high-stakes, and nonrepeatable conditions in which they simply had to do the best that they could with the resources that were immediately available. On July 20, 1969, Neil Armstrong and Buzz Aldrin had a limited set of backup alternatives from which to choose (including aborting their mission) when they discovered that the designated lunar landing zone was strewn with boulders. On Patriots’ Day 2013, Boston-area hospitals had limited alternatives as to what to do with patients already in their emergency departments when they found that trauma patients from the marathon bombing were on the way, who would need half or more of the capacity typically available.

In those situations, developmental leaders were able to create far better choices in those danger zone situations. Aldrin and Armstrong had an alternative landing spot and a way to land safely because NASA had invested so heavily in preparatory, feedback-rich planning and practice that tested people, systems, and processes. NASA had created winning zone conditions of greater simplicity, lower risk, more controllability, and repeatability to build a repertoire of possibilities. NASA invested in building the skills to solve the difficult problems that might have imperiled the successful lunar landing of Apollo 11‘s crew and expanded the number of possible alternatives available to the crew. In doing so, they were using the same developmental mindset that characterized NASA’s management of itself and its university and corporate partners from the early days of the Mercury program, through the Gemini missions, and those Apollo flights that had preceded Apollo 11. 

On the day of the marathon bombing, Boston-area emergency departments had routines they could employ to get patients already in the emergency department admitted into other units of the hospital (or quickly discharged) to clear space and allow attention to the trauma casualties. This was because they’d done so many drills and other rehearsals to expand their set of alternatives.

Similarly, leaders at Amazon were faced with thousands of software engineers with little independence of action, having increasing difficulties making changes within a tightly coupled software system, often resulting in global outages. Instead of hiring more managers to coordinate the work being done on Layer 1 and Layer 2 problems, Amazon focused instead on creating winning zone conditions by re-architecting their Layer 3 wiring, which brought back independence of action to software teams. This enabled them to push the frontiers of performance, from twenty risky software deployments per year in 2011 to doing 136,000 routine deployments per day in 2015.

Those specific examples highlight the mindset that distinguishes developmental leaders from ones who are always transactional. For developmental leaders, the limitations are not resources but useful knowledge about what to do with the resources that are available and how and why to get it done. In other words, the limitation is lack of knowledge (ignorance), (row a in Table A.1), for which the corrective action is creating and utilizing conditions in which it’s far easier for people individually and collaboratively to solve difficult problems quicker, easier, and better (row b). 

The objective for them is not finding an optimal solution along a fixed frontier. It is advancing the frontier of what solutions are possible (row c). And that leads them in the direction of creating systems in which people can succeed, so that they can generate great solutions to difficult problems, and then bring those ideas into action (row d). In the longer term, the developmental leader is not constantly lobbying for more resources, which would otherwise be used in much the same fashion for the same purposes as the resources that are already available. Instead, developmental leaders are always trying to figure out how to improve the problem-solving capabilities of the people for whom they are responsible.

Therefore, as shown in the Figure A.1, developmental leaders’ concerns are different from transactional ones. They are not constantly recalculating how much of Need 1 to satisfy at the expense of Need 2 or how much of Need 2 to satisfy in trade-off with Need 1. Rather, they’re trying to figure out how to engage the minds of more people pushing together to advance the frontier of what is possible.

We’ve seen distinctions between the transactional and developmental mindset throughout the various cases. The developmental mindset is one of relentless and iterative experimentation. That is why designers in any field, who have such a developmental mindset, are always looking to increase the number and speed of iterations from which we might learn. Their desks will be covered by (the equivalent of) drawings and they are marked by mock-ups and prototypes. Then they will construct scale models and increasingly realistic models before committing to the final design, which can be constructed and released. 

Table A.1 Contrasting Transactional and Developmental Leadership 

Literally or figuratively, projects for them are crumpled-up sketches overflowing from a wastebasket, foam-core models scattered on a desk, and drawing sets that are numbered by their double-digit revisions. Of course, if not for those iterations, subject to strong (self-)critical review, code wouldn’t run, medications wouldn’t work, planes wouldn’t fly, cars would underperform, articles and books would be unreadable, and buildings would leak and be poorly lit.

Transactional vs. Developmental Mindset in Improving Layer 3 Processes

We see such a developmental mindset come into play when it comes to designing new or improving existing processes. Transactional leaders focus on the process itself. They believe that by carefully calculating and developing a solution, they can effectively impose it on the individuals responsible for executing it. This approach stems from the belief that limited resources are the primary constraint and the appropriate course of action is to allocate them optimally.

Contrast that to leaders with a developmental mindset. Their starting assumption is that their limitation is insufficient understanding about how to use the resources available to them; that better understanding has to be discovered. So, they don’t try to fix everything all at once. They partition a microcosm model line from the larger whole of the enterprise. 

This presents an opportunity for individuals to collaborate with their colleagues, identify areas that are not functioning effectively, propose new approaches, rapidly test them in real-world scenarios, learn from the outcomes, and iterate for further discoveries. In practice, the model line serves as the practical equivalent of sketches and scale models used by designers, who are focused on continuous development.

How We Teach Layer 3 Skills: Model Lines and Developmental Leadership

The model line can be used to build Layer 3 skills in much the same way that it can be used for problems in Layers 1 and 2. It facilitates a rapid comprehension of processes, but it also becomes a platform in which more people can build the skills for being great Layer 3 designers, operators, and improvers. The model line is a small piece of the larger whole. It is more controllable; fewer people are involved, so coordination is easier, less disruptive, and less costly; and the consequences of it not working are manageable. Furthermore, there’s more opportunity to pause, plan again, and practice anew.

When learning how to solve problems in Layers 1 and 2, professionals are first trained to understand the underlying principles and science of their domains. As first principles are being introduced, small problems are being offered—preferably with feedback and coaching—and work is often completed on paper. Then they explore and iterate to solve increasingly larger problems. As skill is demonstrated, less work is on paper and more is practical problem-solving with small projects. If successful, they then become responsible for increasingly larger, more complex, and more consequential projects that might require more collaboration.

So too with building great Layer 3 skills. The model line can not only serve as the platform for piloting and validating new ideas of social circuitry, but it can also be the training ground for those who need exposure to, practice with, and mastery of the mechanisms of slowification, simplification, and amplification.

The model line yields multiple outputs. It generates lessons learned about problems in Layers 1 and 2. It identifies how to better use the technical and administrative apparatuses available to create the products and services for which the enterprise is responsible. It yields insights into better Layer 3 designs for processes, procedures, and routines. And, model lines increase the number of people creating better conditions for themselves and for those for whom they are directly responsible.

In organizations, we are all likely, at some point, to be responsible for teaching someone something that is important. The transactional mindset is to focus on grading the learner, whereas the developmental mindset will be focused on building capability.

Transactional and developmental mindsets are also found throughout education, from primary school through professional training. For instance, we can see this with how a high school teacher might handle a quiz. A transactional teacher might focus on the graded outcomes without allowing for opportunities to learn from the wrong answers. A developmental teacher might focus on the opportunity wrong answers give for more practice and learning. 

Those wrong answers might be recognized as amplification of what students didn’t yet know and what they still needed to learn. The response to those signals would be to focus on teaching students how to correctly do problems of the types that each had gotten wrong.

- About The Authors

Gene Kim

Gene Kim is a Wall Street Journal bestselling author, researcher, and multiple award-winning CTO. He has been studying high-performing technology organizations since 1999 and was the founder and CTO of Tripwire for 13 years. He is the author of six books, The Unicorn Project (2019), and co-author of the Shingo Publication Award winning Accelerate (2018), The DevOps Handbook (2016), and The Phoenix Project (2013). Since 2014, he has been the founder and organizer of DevOps Enterprise Summit, studying the technology transformations of large, complex organizations.

Follow Gene on Social Media

• 
• 

Dr. Steven J. Spear

Dr. Steven J. Spear (DBA MS MS) is principal for HVE LLC, the award-winning author of The High-Velocity Edge, and patent holder for the See to Solve Real Time Alert System. A Senior Lecturer at MIT’s Sloan School and a Senior Fellow at the Institute, Dr. Spear’s work focuses on accelerating learning dynamics within organizations so that they know better and faster what to do and how to do it. This has been informed and tested in practice in multiple industries including heavy industry, high tech design, biopharm R&D, healthcare delivery and other social services, US Army rapid equipping, and US Navy readiness.

Follow Steven on Social Media

• 
•