Mix-in Constraints

August 20, 2019

I just got done introducing another group to the the idea of agile mix-ins. The conversation was a lot of fun. There were a few takeaways for me that I think made the conversation particularly interesting: When it comes to applying mix-ins, you control how much or how little you do, and you also work within the context of the organization.

Let me back that up a little bit. First, before you try and apply mix-ins, I think it’s important to have established a baseline of working practices. This means that if you have just rolled out SAFe, for example, you should probably give yourself a PI or two to really establish a baseline of performance before trying to muck with the system. Otherwise, you just run the risk of creating a never-ending storm of change. That won’t serve you well. So allow yourself to establish a baseline before introducing a lot of new changes.

Second, Scale the change to the level of of organizational permission or tolerance that you believe exists. In other words, if the management team isn’t really on board with the change, then you probably won’t be able to introduce it much farther than the team itself. On the other hand, if the management team does buy in, then you can apply more global change at the program or portfolio levels. It’s a judgement call. Scale your efforts accordingly.

Risk and Compliance

July 29, 2019

What if you were asked to put risk into some sort of framework in a scaled agile system? How would that work? Well, in many cases, you might start with an existing framework. let’s take SAFe for example, the answer might be that we do roaming in PI planning. So as far as most folks are concerned, all risk is taken care of there. That’s it. That’s all we do for risk. The problem is that in many organizations that are audited for risk management that doesn’t even come close to what an auditor is looking for. 

Why is that? Well, if we look at the rules that many large companies have to operate under, they were written on stone tablets with a chisel sometime back in the 1980’s. Those rules typically specify that an organization should use risk management practices that were originally defined by project management practices at the time, long before agile was commonly accepted. 

Now there’s nothing wrong with risk management per se. It’s really just a fact of life. All projects and products have risk. The question is, are the risk management practices managed in a lightweight and iterative fashion? Those risk management methods from the 1980s are typically heavyweight, if not outright overweight, and require a great deal of overhead and centralized management which I’m not sure anyone wants to do. So if you’re going to provide a system of risk management for a company that has to deal with compliance and that has to deal with auditors, then you’re going to have to put together a system that manages risk, tracks risk, and insure that risk is not idly disposed of, thrown away, or magically disappears. Risk needs to be taken seriously as a first-class artifact and a first-class citizen in these contexts. If you are a smaller company, if you don’t have to deal with audit and compliance, then there’s no reason we would ever do these sorts of things. However, if you are in a financially regulated or government regulated business like healthcare or financial services, then it’s very likely at some point that you will find yourself in a situation where you are asked to show a structured set of risk management practices that are used and have controls so that they can be validated within your organization. The question is, what do you do then?

Just Go Touch the Boat

February 23, 2019

A few years ago, I set out to build a boat in my garage. It was a pretty substantial project. Frankly, it was a lot more than I think I was really prepared for. Nevertheless, I did it. It took me about three years to get done, but I finally realized that particular dream and went sailing on a boat I had built myself. Pretty cool, right?

Well, one of my biggest frustrations was this weird phenomenon that happened right before I got started on the work. I can remember it happening in a very specific place: in the garage doorway. Full of good intentions, and ready to get down to cutting some wood, I would pause at the entry to the garage. There was this moment of uncertainty. Often it wasn’t just a moment though, this could turn into a 10-minute-long, what-in-the-hell-was-I-thinking pause. Often it could completely derail me. I’d spin right on my heels and head back to the couch where a beer and Netflix (and blissful determinism) awaited me. It got so bad that I had a rule: just go touch the boat. I figured doing that much would get me close enough to the problem to create the momentum to figure out the next step.

That pause…what was that?

It was a real killer. Here’s what I think it was: it was realizing that I really didn’t know what I was going to do next. At a high level, I knew I wanted to work on the boat. But the specifics – what part of the boat was I going to work on, what did I need to do specifically? That often wasn’t fully thought out. I had an instruction manual, but that really only described the high-level activities that I had to do. The devil was in the details. I suspect that the delays came down to a few different categories of problem:

  • Setup– Are the requisite materials, tools and plans ready for the next step in the process. Are these preparations in a state where I can easily get started or is there some work I need to do before I can even touch the boat. Often this would be cleanup activities. Often, I had left my workspace a mess after the last session, so I couldn’t get started or find tools until I cleaned up the place. Or perhaps my wife had the audacity to park the car in the garage, thereby blocking my access to my precious…sorry…my boat. 
  • Comprehension– Do I really understand how to solve the problem at hand? I’ve learned that much of woodworking is a series of problems. At a macro level, the work is straightforward, but when you get right down to it, you discover that the tools you have don’t work right. Or you are missing a tool. Or you have no clue how to get the geometry of two pieces right in advance.
  • Drive– There were times when I had things set up, and I knew what to do, but…I didn’t want to. Sometimes the prospect of turning on the table saw, braving the spinning blade of death, and filling the garage with a fine layer of sawdust (over absolutely EVERYTHING) was just too much. Huh…there, I said it. There were these moments when I just couldn’t face the effort after a long day at the office or sometimes even on a Saturday.

I mention all of this because I find myself in a similar position now. I’m not building a boat. Instead, I’m building a business. Just like a boat, there are plenty of instruction manuals. The problem is, just like with the boat, the details are often different from what they describe in the books. And I find myself eager to get started. And yet I pause…

So, I’m re-using a mantra that served me well when building the boat: just go touch the boat. I’m not sure what to call this pause. This moment of uncertainty before committing. But I’m willing to bet big money I’m not alone. 

Dev + Friends

February 15, 2019

I was introduced to a new concept a while ago: Dev + Friends

Apparently it works like this: the only truly productive people in an organization are developers. They are the only people who actually put hands on code. Everyone else in the org is just overhead…ahem, friends. Managers, release engineers, Admins, QA, Project managers, in short anyone who doesn’t write code. Full stop.

I’d like to pause for just a second to express my utter horror at this concept. I think I get where it comes from. Organizations, especially large organizations, can become bloated. Executives looking at the composition of teams see that some teams are less than 50% developers and…Oh jesus I can’t even begin to paraphrase this bullshit. It hurts just repeating it. Well, I’m going to grit my teeth and try anyway.

I was part of an organization where the CTO introduced this concept. I suspect he felt that the developers didn’t have enough voice in the organization, so his answer was to make them the most important role in the organization. Everyone serves the developer. There is a certain justice in this. Teams had indeed become bloated with required roles that increased expense without necessarily increasing productivity. One particularly suspect role was the scrum master. To some degree this was a backlash against introducing agile to teams that wanted nothing to do with it (and were given no choice). Then there were product owners, who were often new, and had no domain knowledge. In fact the teams often knew more about the domain than the product owners. On a team with 7 people you just introduced 20-30% overhead without writing a single new line of code. And those scrum masters and product owners don’t come cheap.

So, apparently to combat those issues the CTO told everyone in the organization that the only valuable people are developers. Everyone else only exists in service to development. He called it Developers+Friends. Coders are the only people who are valuable to the organization. I remember feeling like a third class citizen almost immediately when this was announced. It was the most demeaning thing I’d heard in my professional life. Apparently, the work I did wasn’t important because I didn’t write code.

Just in case you’ve missed it, the fallacy lies here: developers aren’t the only people in the organization who contribute value. Part of the problem lies in the explosion of job types in larger organizations. This rarely comes up in small organizations for the simple reason that in a small organization, everyone contributes no matter what their job description is. In fact, their job descriptions in small organizations are almost irrelevant. Everyone is scrambling to help out so frantically, that the question of strict role responsibility never even comes up.

For the record, there are constructive ways to deal with these issues that don’t involve demeaning everyone who isn’t a developer. Involving the teams in the selection of their roles and processes. Insuring adequate training for people filling key roles. Focusing on flexible roles that don’t map directly to job descriptions. It’s really not that hard. You just have to treat people with respect.

Want More?

I provide innovative agile coaching, training, and facilitation to help organizations transform to deliver breakthrough products and performance. I do this by achieving a deep understanding of the business and by enabling the emergence of self-organizing teams and unleashing individual passion.

To learn more about the services that I offer or to arrange for an initial consultation, please see thomasperryllc.com

The Living Organization

November 19, 2018


I should begin this with a brief explanation: I read a book recently called “Design in Nature” by Adrian Bejan. It’s a physics book – he’s a thermodynamics guy. I don’t know much about physics, but one of the things that intrigued me about this book, was that it started with a definition of what life is from a pure physics perspective. That beginning, starting from first principles, was enough to get me thinking. I started to wonder, what would it be like to start with a definition of organizational life? Would that uncover some interesting insights into how organizations work? So I took Adrian’s definition of life and I hacked it a bit to work for organizations. Something like this:

For an organization to live, its structure must evolve so that it provides easier access to the work/ideas that flow through it.
-Derived from Adrian Bejan’s Constructal Law, Design in Nature [1]

Let’s take that statement and break it down step by step. First, all organizations are living systems. Living elements, namely people, make up organizations and they have some sort of discernible life-cycle of birth, life, and death [2]. For example, most organizations have some sort of entrepreneurial origins or birth. Some never get any further than that. They never find a foothold in the business ecosystem and as a result, they never reach a viable, sustainable state. A lucky few find their way to reach a profitable niche. These businesses are able to form a stable enterprise that capitalizes on this success. These businesses often optimize for their domain, transforming from groping for opportunity to maximizing the profit they can make from that opportunity. In essence, they evolve to maximize the benefit they receive from the success they have found. However, markets, like any living ecosystem, are subject to change and disruption. As these changes take place, the profit that once made the company thrive may disappear. At this point, to survive, the organization needs to evolve again. It needs to find a new niche in its ecosystem where it can thrive. Otherwise, the only alternative is death.

So, every organization is a living system that is changing or evolving to survive within an ecosystem [3]. It follows that the organizations that are fastest to evolve are most likely the organizations that survive in any ecosystem that is subject to ongoing change and disruption. All living systems require the capacity to change, potentially very rapidly, in the face of new threats. If we change too slowly, we can’t keep up with disruptions in our environment and subsequently die. So the advantage goes to the swift when it comes to change.

This brings us to the third and final attribute of living systems: flow [4]. The thing that all living systems have in common is flow. It is the flow of water, or blood, or even information. In its most abstract sense, flow is the fundamental characteristic of any living system. Systems with better flow change faster than systems with poorer flow. So the ability to change or evolve is directly dependent on the efficiency of the organization’s flow.

So if organizations are living systems, and living systems have flow, and the system that evolves to the best flow wins, how we structure our organizations to optimize flow is the most important question we can ask.


[1]”For a finite-size flow system to persist in time (to live), its configuration must evolve in such a way that provides easier access to the currents that flow through it.” Adrian Bejan, Design in Nature
[2]Koshland, Jr., Daniel E. (22 March 2002). “The Seven Pillars of Life”. Science. 295 (5563): 2215–16. doi:10.1126/science.1068489. PMID 11910092. Archived from the original on 28 February 2009. Retrieved 25 May 2009.
[3]Futuyma, Douglas J.; Kirkpatrick, Mark (2017). “Mutation and variation”. Evolution (Fourth ed.). Sunderland, Massachusetts: Sinauer Associates, Inc. pp. 79–102. ISBN 160-5-35605-0.
[4]Mihaly Csikszentmihályi (1990). Flow: The Psychology of Optimal Experience. Harper & Row. ISBN 978-0-06-016253-5.

Agile Management Northwest 2018

September 15, 2018


We held the second Agile Management Northwest Conference yesterday. We had a small, but diverse group of people attending. Of course, there were managers from various software and non-software disciplines. But there was also a district attorney, A dance teacher, a Gregorian chant singer, and a few consultants for good measure. As I opened the space as the facilitator, I was thinking to myself, “Prepare to be surprised.”

I wasn’t disappointed. Linda Merrick hosted the first session of the morning. The topic was “Organizing for Scale” and she used a lean coffee format to structure our conversation. We discussed customer value streams, shared services, tribes, and the fear of restructuring. The topics were wide-ranging and everyone was engaged.


After that, I joined a session hosted by Brent Barton. Brent shared his recent experience as part of a jury in a large civil construction lawsuit. He spent months sitting through this trial learning more than he ever wanted to know about the legal system and the intricacies of construction contracts. However, he also came away with some interesting parallels and insights into the similarities of the practices we preach in agile and the work done in construction. Where we often use (or misuse) construction metaphors as classic waterfall examples of fixed planning, Brent offered that there were ideas like Value Engineering, and Fast Track Construction that were rather agile in their intent and orientation. I came away with the sense that construction is far more uncertain than most people give it credit for.


This conversation also left me with my first surprising insight for the day – having teams evaluated by a “jury of their peers” as part of promoting a form of self-organizing governance for large programs. Rather than having managers externally assessing performance and handing down changes (or punishment), the teams should appoint individuals to a group responsible for self-assessment of the program and capable of levying changes to teams that are performing poorly. It’s a pretty good idea and something that deserves a little further consideration.

Then we had lunch. Folks gathered around the fireplace in the common room to eat together. It was a typical cold, rainy northwest day outside, and sitting by a fire was a cozy way to hang out and share a lunch. I absolutely loved the space we had for the conference. The Brightwater Center building has wooden floors, a fireplace, a pretty stained glass-style window, big bay windows that look out over a nature preserve, and breakout rooms. With plenty of natural light and room to expand as we saw fit, it was a truly delightful place to hold a conference.

After lunch we jumped into our next session. I attended a session called, “What does Music-Making Teach us about Team Dynamics?” Joe Alexander, who has rich experience with singing Gregorian chants, led the discussion. And that’s exactly what he asked us to do! Chant. Our small group stood up, and he led us through a series of exercises, each adding subtly to the next, where we sang a chant together as a group. It was a little challenging, but the group sounded surprisingly good. And Joe used the singing to give everyone a visceral feel for what chanting together can do to create a feeling of alignment and focus. It was a pretty intense session. I’m not sure how I will use that experience in practice, but it led to my second surprise of the day – I never would have dreamed I would be singing Gregorian chants at this conference.


After that, I hosted a session myself to share some of my recent ideas about using organizational batteries as a metaphor for understanding how work is stored and flows through organizations. I’m still playing with the ideas, and I got some good feedback from folks. It was interesting to see how they reacted to the ideas – it definitely makes folks a little uncomfortable. That’s probably a good sign.

Finally, the last session of the day was one that I co-hosted with Skip Angel. The subject was about “Team Toxins and Antidotes.” It was a lively conversation about the things that tend to poison teams and what we can do to remedy that.


After this, we wrapped up the conference with some appreciations and a quick retrospective. Everyone was pretty energized and happy with the outcome of the conference. They all agreed that they loved the space and the food. Some of the conversations had been pretty esoteric, but everyone felt like they were interesting and engaging. I’m looking forward to doing it again next year.

Silos & Value Streams

September 12, 2018


Last night I did a repeat of a talk for a local agile group that I had first done about 5 years ago. The topic was “Silo Busting” and it was all about the nature of organizational silos and how to deal with them. The first time around it had been pretty popular and well received. Like many of the talks that I have done over the years, eventually I put it down to pursue other ideas.

But recently it occurred to me that perhaps I wasn’t done with this topic yet. I went back and looked at the original presentation. My understanding of things may have matured a bit since I had originally delivered the topic, but the fundamental ideas still held up well. In fact, if anything, I felt that organizational silos are perhaps more relevant today than they ever have been before.

So I decided to blow the dust off this particular presentation and try it out with a small audience again. In this case it was the local SEASpin group. They were a great group to talk with. I found myself relaxed and able to cover the material with comfortable pauses for discussion. And I suppose it was no great shock to find that folks had a lot to say about the silos in their organizations. That by itself was gratifying, but as we continued to talk, there were some new ideas that I hadn’t considered before.

For instance, five years ago, there wasn’t a whole lot of conversation about value streams and the dynamics of how they work. In some cases, value streams are organizational silos (or vice versa). Our collective understanding, largely due to the evolution of scaling frameworks, has matured considerably in the last few years. Now we talk about dependencies, optimal sizes, and the correct composition of value streams. These exact same concepts can also be applied to organizational silos.

The other thing that I realized was that we have a lot more ways to understand what is happening in silos than perhaps we used to. This is a bit more speculative, but given some of the recent ideas about emotions and thermodynamics I’ve shared, perhaps these offer us additional ways of thinking about how silos interact. When you look at examples from sociology like the Sherif experiment, it’s quite clear that emotions play a primary role in the creation and interaction of silos. Maybe it’s time we gave the emotional roots of silos more thought.

Some Further Ideas on the Thermodynamics of Emotion

September 10, 2018


Over the last week or two I’ve spent some time writing about the ideas that arose after attending the first Thermodynamics of Emotion conference last year. I have a confession to make: It took me a long time to get around to writing about it. I think it took me a while to write because I was struggling to make some sense of the many diverse ideas I encountered. I’ve written about a few so far, but there are more.

Here is a brief summary of some of the other ideas that occurred to me after the conference. Many are expressed in the form of experiments:

  1. Use a Ratio of Perceived Exertion to measure tension and release prior to and after deployment/planning and other key ceremonies. The build up of tension and its subsequent release are essential elements of the emotional flow of an organization. We should be able to use a subjective measure to detect it within teams and programs. We could use this information map the waves of tension that flow through an organization. Do different organizational structures reflect these emotional waves differently?
  2. Measure capillary action in requirements flow to demonstrate speed differences in work flow by requirements size. Capillary action refers to the ability of a substance to flow through a system with little or no resistance (or even against forces like gravity). I suspect, that we could observe organizational systems with small, evenly sized units of work that flow more smoothly and rapidly than larger sized requirements.
  3. The impact Feedback on fast and slow transmission of emotions through organizations. Does feedback accelerate or dampen the flow of emotions through an organization?
  4. Psychological Studies that support the Thermodynamics of Emotion. There should be some supporting work in the psychological literature for these theories of emotion. The study of emotion in psychology is relatively new, but there should be some material that would be helpful.
  5. Thermodynamics of Emotion and Organizational Silos? Adrian Bejan gives a great example of the fast and slow movement of systems using the Denver airport (a fast central connector between slower stations). It makes me wonder if there is an organizational relationship between the existence of silos and the fast and slow transmission of information across an organization.
  6. Compare traditional hierarchical management information flow with dynamically managed team information flow. Again, Bejan points out that the hierarchical organization structure may have been a natural evolution of the most efficient way to organize large groups. However, I think there are many counter examples to this in nature. I’d like to use information flow as a means of testing more organic teaming versus hierarchy.
  7. Organizational Patterns of flow and energy – Startup, Dynamic, Fixed, and Rigid. This actually comes from an article in Forbes by Peter Hinnsen. He uses a different thermodynamic model to explain how organizations move through different states, just like some substances. They can move back and forth easily between gaseous, liquid, and solid states. But there are some state transitions that are one directional – once you make glass, you can’t get sand back out of it. So does the same sort of rules apply to our organizations? Once you move from a fluid startup to a rigid hierarchy, can you really go back to fluid again?
  8. Measuring the Pulse and Blood Pressure of your Organization. This last idea was just a lark. I wondered if we couldn’t have some diagnostic measures of an organization the same as we do for people. Can I measure the pulse of your organization by the number of deliveries per a fixed time period? Can I measure the pressure of your organization by a ratio of the size of your backlog divided by the batch size of each release? And would this be a useful comparison across companies?

Some of those ideas look pretty good. Others, perhaps not. Using models that cross different domains is risky business. I guarantee you some of this stuff won’t pan out. I still find these ideas exciting. They hold the potential for us to discover new ways to improve the way we work together. To me, that’s worth making a few mistakes.

Thermodynamics & Organizational Assessment

September 8, 2018


The Constructal Law, as described by Adrian Bejan in Design in Nature, is really about answering three key questions about living systems:

  1. Where are the flows?
  2. Where are the waves?
  3. Where is the resistance?

The premise is this: answer these questions and you are closer to understanding the design of living systems. What if the system in question is a business? Can we use these same questions to help understand how a company works?

As a consultant, when I start work with a company there is a period early in the engagement where I’m working furiously to understand as much about the company and their business as I can. This activity typically goes by different names: Assessment, Discovery, Research. The point is that in order to provide useful advice, I need to understand the customer and the business domain well. There are some very conventional tools that are often used when doing an assessment: surveys, interviews, observation, to just name a few. But after reading Bejan’s book, I’m wondering if I could use his three questions about thermodynamics to help me understand organizations better?

Let’s start with the first question: where are the flows in a business? Well, all sorts of things flow through organizations such as money, emotions, product, and information. Starting with money, understanding how money comes into an organization is very relevant to understanding how the business works. This includes everything from basic flows into and out of the company to how the money is translated into product orders within the company. Is funding allocated annually or more frequently? Any limitations in the funding process (i.e. when we can obtain funding for new work) can create resistance within the organization that make it hard for money to flow smoothly to critical products or initiatives therein. If you are responsible for improving the flow of work, you can’t do that without corresponding improvements in the flow of money or funding.

Next, have a look at the flow of product through the organization. How frequently can product be delivered? Once a year? Quarterly? Monthly? Daily? Hourly? Again, often we will find that the flow of product is held up because a company is incapable of releasing more frequently than once every 6 months. Impeded product flow is going to have all sorts of ripple effects on your ability to get other work flowing in the organization.

How about information flow? How long do requirements sit in a queue prior to ever being worked on by a team? How large is that queue and what is the throughput for something in that queue? All of this can have a profound impact on the ability to improve flow within a company.

Lastly, can we identify the flow of emotion through a company? I’m not sure about this. Those other examples were easy to find nice clean objective measures for. How would we observe emotions flowing within a company? Well, I know passion and energy when I see it. I also know when passion and energy are absent. I’ve tried using a rating system based on criteria like are people sitting forward in their seats or leaning back. Frankly these kinds of ratings didn’t lead to any startling insights (except perhaps that the chairs are exceedingly uncomfortable). However, there may be one place where I have seen energy obviously flowing through an organization: in large collaborative meetings like big room planning. I’ve seen teams come to these collaborative planning sessions with some anxiety and trepidation and I’ve seen them afterwards, virtually spinning with energy, as they leave with a coherent plan that they all believe in.

Perhaps the mention of this pulse of emotional energy is a good place to also ask about waves in an organization. After all, emotional energy is certainly not a steady state. Emotions ebb and flow and definitely come in waves. We may not understand the composition of the wave (is it anger, joy, etc.) but we can often detect the change in energy. The company that I work for is being acquired and it is no simple cliche to say that the news of the acquisition has sent emotional shockwaves through the organization. These waves are often preceded by rumors and gossip, so perhaps that’s a clue to where to look for the flow of emotion in an organization?

There are corresponding waves of work, product and information that flow through an organization. You can see that flow or rhythm in organizations that have adopted scaling frameworks like SAFe or LeSS or Nexus. Everything rolls through on a quarterly basis. Work builds up in queues prior to the quarter and work is released after the quarter. This is a manifestation of quarterly waves flowing through the organization. Of course, this applies to the examples of funding and other flows that I’ve already mentioned.

Finally, what does resistance to a flow look like for each of the attributes we have been examining? Is there somewhere in the organization where there is resistance to money flowing? Curiously, I have encountered organizations with really poor billing and collections processes that have made the flow of money into and out of the organization excruciatingly painful. Often you see people within organizations like this doing all they can to go around or circumvent the afflicting process or system. If you are wondering where resistance lies, I’d recommend looking at what tools they use first. Tools are a common manifestation of organizational resistance. Then I’d take a look at documented policies. There are other undocumented kinds of resistance including emotional resistance too (again, gossip and rumors).

When you take a minute to step back and think about it, using these perspectives reveals the typical organization to be a very dynamic creature. It is constantly ebbing and flowing with information, money and product. There are waves of various kinds of change pulsing through it. There are places where the smooth flow of information encounters resistance and blockages. When you use this language, it starts to sound very much like a living system. It surges and heaves, ripples and flows, and struggles in ways that are almost peristaltic in nature. As we deal with these systems, we are diagnosing a large and quite complex living system.

To wrap up, we have explored how we can use questions used to evaluate physical systems in thermodynamics:

  1. Where are the flows?
  2. Where are the waves?
  3. Where is the resistance?

And we have applied them to the evaluation and assessment of organizations. It seems that using these questions has a great deal to offer us in terms of understanding the mechanics and underlying issues that a company may face. So, the next time that you are assessing an organization, try using these questions to understand the thermodynamics of the organization.

The Preyful Manager

September 4, 2018


In Kevin Behan’s book, Your Dog is Your Mirror, he has a lot to say about emotions and how our relationship with man’s age-old canine companion tells us a lot about us as emotional creatures. Behan makes many bold assertions that upend many of the conventional schools of thinking about animal behavior. For instance, he rejects the language of dominance and submissive behavior outright and instead replaces it with his own model of predator and prey behavior (The Immediate Moment Theory).

The predatory aspects of behavior are things that you may already be familiar with, such as a predatory look (hard focus), with eyes locked on a target, using height and size to establish advantage, being very still and coiled, ready for attack. These are all physical manifestations reflecting the emotional state recognized as predatory. Think of a traditional predator like a wolf or a lion just prior to attack. They are locked on to their target, frozen, waiting for the moment to strike.


On the flip side we have what Behan describes as the Preyful attitude. The preyful aspects include a soft focus, rhythmic, meandering movement, a relaxed attitude, small/slow approach. These are the common aspects of prey as you typically see it in nature.


Behan makes a rather astonishing assertion that the predatory and preyful are different poles of emotional behavior and that they can be flipped or switched on and off in the same individual. This means that what you typically see as a predator does not have to behave in exclusively predatory ways. In fact, a predator can exhibit behavior that is actually preyful in nature. Neither state is good or bad, they are simply assigned opposite polarity: positive and negative.

In the same way that we might see dominant and submissive behavior in human interaction, we can look for these two emotional aspects of behavior in our day to day interactions as well.

Where I might describe a manager who is prone to controlling behavior as dominant, I might now use a metaphor like predatory. And where I might describe someone on the team as submissive, I might replace that with the term preyful. So people can have predatory and preyful aspects to them. The clever thing that Bejan does is to allow these two aspects or polarities to switch freely between the two parties. A person who often tends to behave in a preyful way can switch their behavior to a predatory mode. This switch in polarity may happen in response to different contexts or stimuli in the environment. When it happens, it can be very confusing for those who are predatory. The prey is no longer acting as prey. So it’s a dynamic between two parties.

So how do we use these notions of Predatory and Preyful in a fashion that is helpful to us in an organizational transformation? I think it might apply to how we are asking managers to change their own roles during an agile transformation. Typically we don’t address the emotional side of the change, and this is perhaps a big mistake. Emotions count much more heavily in our assessment of the impact of change than just about anything else.

We are looking for managers to change from a position on high, where they are watching workers, looking to jump on mistakes, to a very different role or polarity. We want them to be open and inviting, to be expressing a much softer aspect where they are nurturing and engaging the team rather monitoring and preying on it.

Now to be perfectly clear, there are no absolutes in this model. I don’t think anyone is 100% preyful or 100% predatory. It’s a spectrum and on any given day, we are somewhere in-between those two extremes. Furthermore, I think we move on that spectrum based on mood, context and other variables. What I think we are actually attempting to do is to get managers to explore moving about on this spectrum more readily. There is a time and a place for predatory, aggressive behavior. And there is also a time and a place for preyful behavior. I think it’s our ability to move fluidly and appropriately on this behavior spectrum that makes us better managers.