Our environment, abilities, beliefs and values  influence our behavior. Any action we take results from how these affect our thinking.

It seems to me changes resulting from/attributed to Agile should have values that parallel those in the Agile Manifesto. Without too much effort this results in:

In Agile Change we value:

Individuals and interactions over processes and tools

Learning and changes in behavior over new org charts and process documents

Participation and refinement over top down directives

Recognizing new opportunities over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Using the Stacy Matrix as a guide, it’s my observation that change falls into the “complex space”. This means mechanistic, Tayloristic, plan driven change will usually fail, and create multiple messes while doing so. These models do not map to a reality involving multiple concurrent paths and the ensuing change in decision making.

I get concerned about a change processes involving people and making statements like: ”Diagnose gaps and manage resistance.” and “Never letting up.”

I find applying Human Systems Dynamics creates better results during change.

HSD helps you see and influence patterns in human relationships. When people interact at work or play, complex patterns emerge. HSD tools help you cope with those patterns when:

• Resources are tight and demand is high
• Your old tools and techniques fall short
• Players are many, diverse, or constantly changing
• Culture and/or organizational habits are obsolete
• Too much or too little control makes people crazy
• There are so many moving parts you don’t know where to start

Contact me if you’d like to apply and experience Human Systems Dynamics during change.

I appreciate Esther Derby for helping with the Agile Change Values.

Three Types of Change

Human Systems Dynamics posits three types of change: Static, Dynamic, and Dynamical. 

I’ve summarized the differences in the types of change in this table. The descriptions come from HSD. I added the equations (for us math/engineer types) and the graphs of what the change might look like.

Name	Description	Equation(s)	Looks Like
Static	Static change is the simplest,being two-dimensional, it depends on direction and force. It is also predictable. Static change is about moving from Point A to Point B by applying force.	axn+axn-1+… + c
Dynamic	Dynamic change is more complicated, being multi-dimensional. It can best be described as moving along a smooth trajectory toward a predictable end point. Like water shooting out of a hose, if pressure and angle are known, you canpredict height and distance of the arc of water.	axnbym + ax(n-1)by(m-1) + … + c
Dynamical	Dynamical change is complex and results from multiple forces acting in unpredictable ways, generating surprising outcomes. Think about water dripping from a faucet. The rate of drops depend on too many factors to to predict, precisely, when each drop will fall. The amount of deposit in the pipes; the temperature, wind, and humidity in the room; and the amount of water in the pipe interact in unpredictable ways to determine when drops will fall—non-predictable and maddening in the middle of the night.	dx/dt = σ (y – x) dy/dt = x (ρ – z) – y dz/dt = x y – β z

Let The Mess Begin!

So what happens? Some executive, somewhere, decides things need to change! People get assigned to new departments or teams. A new reporting structure gets defined. The charts are drawn, powerpoint slides created, and “all hands” sessions scheduled. (Using the Organizations Change… post, what model is management using?) The mess starts shortly after the meetings.

In my experience managers usually expect static change behavior. Start here. Go there. Done. You’re in a new team. We moved your equipment and materials to the new space. What’s the problem? Other than everyone having to work through the Change Model?

Some people will work through the Change Model quickly. But

As Mike points out: “On many levels we are dealing with very personal deep seeded stuff… the stuff that anchors us as people and defines who we are in relation to the world.”

This means other people will respond in a Dynamical fashion.

And hence the mess.  The mismatch between the change response expected  and the change response in the domain.

Productivity goes lower than it needed to. People get labelled “resistors”. Malicious compliance might occur. Management pushes harder to make sure the change happens.

If the wheels don’t spin completely off the change, it could get sidetracked. Sometimes management declares success and moves to the next hot topic.

As a change artist, I’m pro-change. Change includes planning.

As a systems thinker, I’m pro-models. Models are neither naughty nor nice. They’re the simplification of the world we carry in our head that enable us to function.

As an engineer, I’m pro-reality. In this case I define reality as using data to determine if our models reflect what’s happening the domain.

What to Do?

If you’re planning or involved with a change:

• Remember everyone goes through the Change Model. At different rates, but everyone goes through.
• Be prepared for the Failure Paths.
• Check your assumptions on the type of change you’re working with.

If you’re not sure what’s happening, you can engage a change artist to help.

The equations for the Lorenz attractor (the picture for dynamical change) came from https://en.wikipedia.org/wiki/Lorenz_attractor. The picture of the Lorenz Attractor is from Wikimedia commons – Lorenz_Ro28-200px.png

Team Powerhouse had problems. The developers didn’t know how much work they could get done in a sprint. The testers received the code about a day before the sprint demo. About half the stories got pushed to the next sprint. All in all, it seemed normal to me. They had just formed, and some chaos seemed reasonable.

Say What?

When organizations change, the old way of working doesn’t work any more. Work flows change. People get put in new groups. Agreement hasn’t formed on what we’re going to do, much less on how we’re going to do it.

Chaos reigns. In a picture it looks like:

How Does This Apply to Software Development?

You can put almost any two inter-related labels on the axes. Common ones I use in software development include “Requirements/Technology” and “What/How“. The closer to agreement you can get, the less chaos exists.

While Chaos may seem bad, it can provide energy and freedom to innovate if the organization has created safety around the change.

It is important for people to understand and not be surprised by this neutral zone, for several reasons. First, if you don’t understand and expect it, you’re more likely to try to rush through or even bypass the neutral zone-and to be discouraged when you find that doesn’t work.

Second, you may be frightened in this no-man’s-land and try to escape. … To abandon the situation, however, is to abort a transition, both personally and organizationally-and to jeopardize the change.

Third, if you escape prematurely from the neutral zone, you’ll not only compromise the change but also lose a great opportunity. … so here let me simply say that the gap between the old and the new is the time when innovation is most possible and when the organization can most easily be revitalized

The neutral zone is thus both a dangerous and an opportune place, and it is the very core of the transition process.¹

So What to Do?

1. Understand your employees will experience some chaos during the neutral zone.
2. Chaos will initially lower productivity, even though the change will (hopefully) improve productivity in the future.
3. Create safety so employees can explore and innovate without fear during Chaos.
4. Work with a Change Artist like me to plan the change, and then follow on with helping people transition.

But that’s not what I usually experience in my work. Why does this gap exist?

A Handful of Change Models¹

My recent posts have centered around the Satir Change Model. This describes how people respond to change. But how do we change organizations?

• The Diffusion Model, which says change more or less happens. A common example of this would be communities of practice in an organization. People choose to meet and share ideas and how they accomplish their tasks. Attendees can choose or adopt new ideas and practices, or not.
• The Hole-in-the-Floor Model, which says change is dropped on changes by planners upstairs.  Process improvement committees and “You will now be Agile” mandates fall into this category.
• The Newtonian Model, which introduces the concept of external motivation to change. Often this takes the form of upper managers creating a sense of urgency, walking around with gantt charts checking to make sure every thing’s reported on schedule, blaming resistors and beating up the laggards.
• The Learning Curve Model, which considers the time to adapt to something new.  On the job training and mentoring fall into this category.

Other models exist, but often they fall into one of the above categories.

A Little More About Organizations

According to the Merriam-Webster dictionary “an administrative and functional structure (as a business or a political party)” describes what I mean when I say “organization”.

This means we change an organization by re-arranging its structure. We add a new department (Quality Control), insert a new role (Director of Quality), reassign people, update the HR manuals, and re-draw the development process. Implement the new structure and we’re done!  Sort of. If the change doesn’t seem to work fast enough, we can increase the pressure or put motivational posters on the wall.

But What About the People?

1. Ending - Letting go of the old ways and the old identity people had. This first phase of transition is an ending, and the time when you need to help people to deal with their losses.
2. Neutral Zone - Going to an in-between time when the old is gone, but the new isn’t fully operational. We call this time the “neutral zone”: it’s when critical psychological realignments and repatternings take place.
3. New Beginning - Coming out of transition and making a new beginning. This is when people develop the new identity, experience the new energy, and discover the new sense of purpose that make the change begin to work.

Using our previous example of moving a cross functional development team into a team room:

Moving to the team room represents the change. Make the announcement and move. I’ve seen teams pick up their computers, manuals and move. I’ve worked where “facilities” moved the equipment and books over the weekend. Either move has a discrete start and end. The change announcement starts the transition process.

When team members hear they’re  moving to a team room, they wonder: “What will it be like?”, “How will this affect my ability to concentrate?”, “If I play along, how long will it take before we move back into cubes?”

After the equipment arrives and they’re sitting in the team room, they start to adapt to their new surroundings. They may establish times when the team tries to stay quiet. Two or three may go to the whiteboard and have a conversation about a piece of code. They develop simple rules for handling interruptions.

Eventually the team room becomes the norm. Team members become comfortable with the change to the team room. I’ve seen those most opposed to moving become ardent supporters for the change.

Handy Reminders

Companies change.

People transition.

Not everyone in the organization completes the transition started by the change.

Those who do make the transition from ending to new beginning do so at different rates.

“You need all three phases, and in that order for a transition to work. The phases don’t happen separately; they often go on at the same time. … Perhaps it would be more accurate to think of them as three processes and to say that the transition cannot be completed until all three of taken place.”²

You can help people understand and transition quicker. Bring in a change artist like me who has domain experience and has helped other organizations and their employees through the change/transition process.

¹You can read more about these models in Quality Software Management Vol 4 Anticipating Change, © 1997 Gerald M. Weinberg, ISBN 0-932633-32-3 pp 3-14 If you prefer ebooks Becoming a Change Artist contains this material and more

²Managing Transitions, Making the Most of Change, ©2003 William Bridges and Associates, ISBN 978-0-7382-0824-4 page 9

After the first sprint, we finally moved to a common area. Still in cubes, but with short walls so everyone could see everyone else. Well, except for the two guys in the closet.

It took some influencing, but eventually they moved too. Some people just don’t seem to be in a hurry to change.

The team sat around the room. They struggled to find a way to refactor an object that had become a catch-all for the application’s bits and pieces. Every time they got close to a solution, Peter would chime in with another possibility. Finally Joy snapped, “This is how we’re going to do it!” stopping all conversation.

Youíve probably noticed people behave differently. Differences become pronounced during change. People start to act out in ways that don’t make sense to us. But if we look at peoples’ temperaments, we might have an idea what’s happening for them. Based on the Jungian psychological types, David Keirsey’s four temperaments allow us to understand weaknesses and strengths during change.

CHANGE AND TEMPERAMENT¹

The Visionary (NT) likes working with ideas. NT Visionaries are most interested in designing, rather than implementing, change. They like to provoke with ideas, even during Chaos when such provocation is inappropriate and may cause much pain and confusion.

The Catalyst (NF) likes working with people to help them grow, but is concerned that people should not suffer from change. They have a tendency not to let people experience their own pain, so they may short-circuit Integration by trying to be helpful. They are such team players that they may want everyone to do the same thing, even if their personalities are different. Also, they may want everyone to do something at the same time, even if people are at different stages of the change process.

The Organizer (SJ) likes order and system. The important thing to [them] is not just doing it, but doing it right. .. They are best at carrying the transformation into actual practice, long after the NT Visionaries have gotten bored. Although SJ Organizers tend to fear quick change, they may push for quick closure, like getting firm commitments during Chaos when it is inappropriate. They may also stifle all change by requiring that success be provable in advance.

The Troubleshooter (SP) likes getting the job done. [They] want quick fixes, not elaborate plans. They are the least likely to deny the foreign element, because they see it as an opportunity to swing into action. For SP Troubleshooters, change should be fast, so they don’t get stuck with something that’s boring. As a result, they are impatient with planning, and may provoke change for its own sake, piling one change on another, even during Chaos. Impatient with Integration and Practice, they may drop out if change seems too slow.

It’s important to notice that each temperament has both strengths and weaknesses during change. We can utilize different strengths to help achieve the desired New Status Quo. Knowing where the change currently resides on the Satir Change Model allows us to understand why team members act like they do.

These descriptions aren’t “one size fits all.” People have many facets so don’t expect all NTs to act the same way during change. At minimum these descriptions could be thought of as “tendencies”. Sometimes they’ll be dead on. While not truth, they can be useful.

In addition to Temperaments, different people process change at different rates, and other parts of our personality like survival rules, family background and self-esteem affect our responses to change.

Change can seem simple and straight forward when drawn and diagrammed with nice squares, straight lines, and check lists. But when we look at what actually happens, change is anything but straight forward. If youíre currently in a mess, contact me and letís clean up the mess together.

¹Quality Software Management Vol 4 Anticipating Change, © 1997 Gerald M. Weinberg, ISBN 0-932633-32-3 pp 60-61 If you prefer ebooks Becoming a Change Artist contains this material and more

What happens in these situations? Actually, many paths exist between starting a change, and ending back in the old status quo.  How many paths can you find in this figure that lead back to the old status quo?

Now you see what traps change initiatives and takes them off track, usually back to the old status quo.  If your change initiative has started its path back to the old status quo, contact me and let’s work together on helping the change succeed.

Late Status Quo – things humming along nicely. Everyone know what’s expected from them and how to do it. In a word – comfortable. Eventually along comes a

Foreign Element – this event shocks the system. It could be a manager forcing a team to move to a team room. It could be changing from gated to incremental and iterative development.

Chaos – means the systems now operates in ways we cannot predict. People no longer know exactly what’s expected, and if they have an idea, they don’t know how to do it. Team members may try many ideas to get a semblance of order.

Transforming Idea – the team discovers how the change benefits them. They discover osmotic communication. When they need quiet to focus, earbuds covered by noise canceling headsets! (I’ve seen it done)

Integration and Practice – the team experiments with their environment. Add mood lighting. Agree to periods of quiet time for focusing. Implementing whole team development.

New Status Quo – where the team has accepted the change to the team room and have become comfortable in it. They know what to do, and how to do it. Which eventually becomes the next Late Status Quo.

This represents the change “happy path”. The journey from Late to New Status Quo contains many hazards and opportunities to revert to the Late Status Quo.

Sometimes, it seems like people asking other people to change believe change happens like flipping a switch. When they see people holding on to what used to work, flailing, or trying out many new ideas they think somehting is wrong–either with the change or the people. But this process is normal, natural, inevitable.

If your organization is going through a change and you need help, give me a call or send an email.

© 2011 Don Gray

The agile training class for a newly formed team was almost complete. We’d covered values, practices, roles, the product backlog, done simulations teaching the Scrum process and I could see the end of  training. A little team building activity, and we could start tomorrow with building the backlog, story sizing, then start the first sprint.  Forging ahead, the team selected a name, came up with a list of team norms, and they became a team with me as their ScrumMaster.

Or did they?

Over  the next few weeks, I noticed cracks appearing. One member tried to find ways to avoid the daily standup. Another member only checked in code toward the end of the sprint. Yet another happily worked on what he was assigned, but never volunteered to take tasks from the task board. At times, the entire team struggled to understand how its  activities blended with and supported the activities of the other teams on the project.

There didn’t seem to be a unifying focus, something with which all the team members could identify. What could I have done differently?

Forming a Team

Over the years, I’ve seen teams formed many different ways. There’s the Five You process where the manager goes “You, you, you, you, and you. You’re now a team!”  Often, these team members were selected because they were between projects, they possessed approximately the right skills, and it was time to get a new project started.

Matrixed teams form somewhat differently. Team members get assigned by skill level to projects. The greater (or rarer) your skill, the more teams you get assigned to on a part-time basis. This way, everyone has 100 percent of his time assigned to project work. I once met a QA “resource” (which in itself says a lot about the company) assigned to three Scrum teams. For some reason, he didn’t seem to get much done but go to meetings. Matrixed team assignments guarantees all projects get delivered in the maximum amount of time possible, if at all.

In the case of the team I worked with, the developers became a team because they all worked in the same office. I believe in collocation, but being together, in itself, doesn’t provide impetus to become a team. So what might?

What Makes a Team?

In The Wisdom of Teams¹ we find the conditions needed to exist for teams to form:

• A compelling work goal
• Interdependent work
• Stable membership
• Shared history
• Five to nine members

Interestingly, a compelling work goal often gets overlooked. The team had work to do, but I don’t believe “We’re part of an project that will save the company a bunch of money” constitutes a compelling work goal. Don’t get me wrong, helping the company save money is a good thing, but does it call forth the urge to slay dragons or at remove impediments from the development process?

We did have interdependent work, both within the team and between the teams. Other than some members not checking code in regularly, a lot of thought and effort went into making sure the teams’ code didn’t break other parts of the application. The code management system and continuous integration worked quite well when developers did check in their code.

This team had sort of worked together prior to my arrival. The team members knew each other but divided the work so they had the minimum amount of interaction. So, while they had stable team membership, how they handled work created knowledge silos and prevented them from learning from each other.

Shared history initially seems to indicate the team has to work together for some time. I’ve learned since my work with this team to use experiential activities to actively start creating shared history instead of letting the shared history happen and hope for the best.

Teams generally need five members. This allows for sufficient skill, experience, and knowledge to generate good decisions and actions. When teams get more than nine members, the communications paths tend to become centralized and the larger group informally splits into two smaller groups, losing a coherent whole.

Creating a Team

Creating a team involves more than picking five to nine people then having them pick a name (although choosing a name for the team can be both fun and enlightening). Managers usually set the initial team membership and pick the project on which the team will work. This means managers need to align the team members’ skills so they can fulfill the project’s vision. If the project doesn’t have a vision statement how can the team coalesce around a compelling work goal? It doesn’t exist.

Team formation activities can range from creating a formal team charter to the Five You process. It may make sense for some teams to go through the formal process of documenting the purpose; summarizing their structure, customers, and stakeholders; listing the members; identifying roles; and defining the team’s authority—but I don’t usually see this in agile software development teams.

With the team members selected we can do specific activities to help create team identity, highlight the team’s purpose and establish ground rules.

Team Identity Activity—Design a Box

This activity lets the team define itself and create an identity to share with the rest of the organization.

Team members need to design a shrink-wrap box that represents their team.  They design the box front and back. This involves:

• Coming up with a team name
• A picture
• Three to four key bullet points on the front to “sell” the team
• A detailed feature description on the back
• Operating parameters

It also tends to be a lot of fun.

Team Purpose Activity—Team Elevator Statement

This activity focuses on the “compelling work.”It aligns the team’s actions with the product vision and corporate mission statement. It’s the team’s reason d’être.

Using the “elevator speech” format helps the team succinctly pull these ideas into a sentence they can share with others.

For [target customers]who wants/needs [solution to a problem] <your team> provides <what compelling reason to buy>. Unlike <competitors/other teams> <the team key differentiator>.

Working Agreements

Working agreements specify the team’s operating parameters. They list expectations between the team members. They serve as guide rails as the team builds its shared history. They might include meeting information, team norms, a definition of done, and other pertinent items.

When working with the team to create its working agreements, I use the expand-then-collapse facilitation process. After explaining the goal for the working agreements, I solicit suggestions from the team members about what they feel will be important to them. I use stickies for this. Then we post the stickies, having a conversation about what the words mean. After we have everyone’s input, we look for duplicates, suggestions that form part of another suggestion. We aim for seven to nine agreements. Anything more results in a list no one can remember.

I’d be lying if I told you these activities automatically create great teams. Nothing can automatically create great teams. But, by focusing on your team’s purpose, identity, and working agreements you can help team members answer the question “Why am I here?” and set the team up for success.

¹ The Wisdom of Teams, Katzenbach and Smith, Harper 2003, ISBN 978-0060522001 pp 43-64.

This article originally published on Project Management (http://manage.techwell.com) March 09, 2011

What Does Trust Mean?

I like to use the following four beliefs I learned from Esther Derby to define trust in the workplace.

1. I believe you have the ability to do the things you say you’ll do.
2. I believe you will do the things you agree to do  – or let me know when you need to renegotiate.
3. I believe you have good intentions towards me.
4. I believe that if you have an issue with me, you’ll bring it up directly with me, not talk behind my back.

Following these points makes trust building somewhat straight forward. I do what I say I’m going to do. If something happens and it looks like I won’t be able to meet my commitment, I say so. I’ll talk with you instead of talking with others about you.

Is It Always That Simple?

It can be that simple. Sometimes things get complicated when actions and information get interpreted differently. These complications often happen when we’re tired, in a hurry, don’t take time to process what’s happening here and now and resort to a “then and there” responses. “Then and there” responses come from our past and at some level remind us of the current situation. We not only respond as if the current situation exactly resembles the prior situation (it doesn’t) we can get the meta-response of “not this again!”

Here’s some ideas what to do:

1. Count to 10. This allows you a chance to focus on a breath or two and replay  what just happened.
2. Consider how your intake preferences might be influencing what you’re feeling.
3. Remember we’re all different.
   • I’ve had discussions where it turned out we both argued for the same point, but we used different words.
   • Different values motivate us. (see the Why Not Ask Why? sidebar )
   • We have different work styles.
   • We have different capabilities.
4. Allow for generous interpretations. Seek to understand the other person’s view point.

Having a shared history with your team members helps generate trust. You know their capabilities and how they’ve performed so far. If a team member hasn’t performed according to their commitments people remember and judge this commitment accordingly.

If the team has recently formed, take every opportunity to learn more about your new team mates, their similarities and differences. This can happen as part of both formal  (pair programming, lunch and learns) and informal (coffee breaks etc) activities.

Like safety, trust can come and go based on the context and what’s happening. You can unilaterally decide to trust a teammate. How their response fits the four beliefs determines how much you continue to trust them.

It all started with a tweet I posted:

“Why” questions trigger feelings bypassing data input and thinking. #dontdothat

As this got retweeted, interesting questions started coming my way:

• What about the Five Whys?
• Do you have data?
• What is your context?

All good questions.

“Why” questions have the ability to both gather data and to probe for underlying thoughts and decisions that lead to action. Other interrogatives (what, when, where, how) provide a better way to gather data since they focus on physical items or actions.

So when do “Why” questions work well? How might “Why” questions lead to unexpected results? What can we do about that?

Solving Problems: Toyota and the Five Whys

I was writing process control code for a living when I first heard about the Five Whys. It made sense for finding a problem’s root cause. The example went something like this:

1. Why did the line stop? Because the conveyor gear reduction box froze.
2. Why did the gear reduction box freeze? Because it didn’t get lubricated during the last preventive maintenance.
3. Why didn’t it get lubricated during the last maintenance? It’s a new piece of equipment and wasn’t on the preventive maintenance check list.
4. Why didn’t it get added to the maintenance check list when it was installed? Because we don’t have a standard way of adding items to the check list.
5. How can we create a standard way of adding items to the check list so this won’t happen again?

Asking why uncovers another layer of information that eventually leads to the problem’s root cause and allows us to craft a solution to (hopefully) prevent the problem. Since we’re starting with observable data, asking why works well here.

Gathering Data: Five-year-old Whys

Anyone who has spent time around children has probably experienced a period of incessant whys.

Why is the sky blue? Because air molecules scatter light from the sun.

Why do the air molecules scatter the light? Because they get in the way of the sun’s rays.

Why do they get in the way?

(And so on.)

Often, the question-and-answer process ends with “Because I said so, that’s why.”

Asking why provides children with new information, and data expands their knowledge, so why works well here—at least until “Because I said so.”

When Why Might Not Work Well

Your teammates, managers, and coworkers are neither mechanical processes, which don’t care if we talk about them, nor five-year-olds attempting to gather more information about their world. They come complete with experiences you don’t know about and ideas about how things should work. As such, your why questions may trigger in others an emotional response that catches you unaware. What might generate such a response?

An Interaction Model

The Satir Interaction Model [1] provides a framework for understanding how interactions proceed, as shown in figure 1.

Figure 1

Take Tony, for example. You’ve noticed the build server has been sending emails announcing that the build broke, and Tony usually makes the commit that occurred just before the build that broke. Wanting to be helpful, you head to Tony’s cube and ask, “Why do you keep breaking the build?” You’re looking for information. The message has been spoken and becomes the input.

Based on how Tony feels and his background, he can infer several different meanings. He may think you’re picking on him. He may think you mean “Tony, you’re incompetent.” He may interpret the question as a request for information.

The meaning Tony chooses determines his feelings about your message. If he thinks you’re picking on him, perhaps he will feel afraid or threatened. If he believes you think he’s incompetent, he might become defensive, or he might be relieved that you might help with the problems he’s having.

Tony also will have feelings about those feelings based on his background. Perhaps his father taught him not to back down when threatened, or to prove you’re right when challenged, or even that accepting help shows weakness. Tony may feel ashamed, angry, confused, or relieved.

Based on Tony’s life experiences, he may defend himself by:

• Blaming—“The stupid formatting rules take too long to check. If IT would buy us better computers, this would not happen.”
• Placating—“I’m so stupid. I should do better.”
• Being super-reasonable—“Has anyone checked the rules on the build server to make sure they agree with how the builds work on my workstation?”
• Feigning irrelevance—“It’s almost lunch. Where should I go today?”

After these steps, Tony will work on his response. What can he safely say? What do his family, social, and corporate cultures say about what he can say? Some comments can be career limiting. Does he have an “always be agreeable” rule? These commenting rules affect his verbal response.

Everything between the Intake and Response steps happen internally for Tony, but you can guess what happens based on his response. If Tony replies in a way congruent with your intention—“I’m having problems with formatting. Can you help me figure out what’s happening?”—the request for information succeeded. If Tony becomes bellicose, belligerent, or his answer bewilders you, the question triggered a meaning and feeling not related to your request for information.

The Interaction Model and Temperaments

Figure 2

In Congruent Action [2] Gerald M. (Jerry) Weinberg collapses the steps from Feelings through Defenses into a single step, which he calls Significance, and correlates how Keirsey’s Temperaments [3] (see the sidebar) tend to work through the Interaction Model:

• SJs stay in Intake mode too long.
• NTs tend to go instantly to Meaning.
• NFs tend to jump immediately to Significance.
• SPs go so fast it looks to others as if they jump instantly to Response.

More than half of IT professionals implicitly skip the Intake step based on their personality preference. You want to know “why” to collect data—41.6 percent will look for the meaning behind your question and another 12.1 percent think about how the question makes them feel.

Jerry offers the following suggestions:

• For NTs/NFs, ask, “What did you see or hear that led you to that conclusion?”
• For SJs, ask, “What can we conclude from the data we have so far?”
• For SPs, appeal to their desire to be clever and ask them to teach you how they did it.

Use Data Questions to Gather Data

Questions that start with other interrogative words, such as when, what, where, and how, help people focus on the data aspect of the question.

If we ask Tony a different question, we can help him focus on the data we would like to know—for example, “What steps do you take prior to committing to the build server?” or “How do you decide it’s time to commit your code?” Tony still traverses the Interaction Model, but we’ve explicitly asked for data.

Over the years, I’ve had some why questions bounce back to me with responses that left me wondering how what I said triggered that response. Using the Satir Interaction Model, I’ve learned to unravel the responses. I’ve also learned that if I want data, I should use data-oriented questions that start with how, what, when, and where, and use why as a last choice.

On the other hand, if you want practice unraveling communications, start with why as often as possible.

[SIDEBAR]

Temperaments

“There are two types of people: people who divide people into two types and those who don’t.” –Barth’s Distinction

Dividing people into groups is a time-honored tradition. Circa 340 BC, Plato divided people into four groups: Artisans, Guardians, Idealists, and Rationals. Since then, many others, including Aristotle, Galen, Paracelsus, Fromm, and Myers, have found ways to divide people into four groups.

In 1978, David Keirsey and Marilyn Bates “developed and described” the temperaments “in modern form.” They “found that selectively combining [N with T/F and S with J/P] produced a descriptive personality system similar to the four temperaments … described centuries earlier.” [4]

“When the only tool you have is a hammer, it is tempting to treat everything as if it were a nail.” –Abraham Maslow

I like to remind clients that temperaments represent one way of understanding people and how they interact.

References

1. The Satir Model: Family Therapy and Beyond, 1991, Science & Behavior Books, Inc., pp 121-129
2. Quality Software Management, Volume 3, Congruent Action, 1994, Gerald M. Weinberg, pp 108-109
3. Please Understand Me II, 1998, Prometheus Nemesis Book Company
4. MBTI Manual: A Guide to the Development and Use of the Myers-Briggs Type Indicator, 2003, Isabel Briggs Myers and Mary H. McCaulley
5. From What Type Am I? Discover Who You Really Are, 1998, Renee Baron
6. From the Myers-Briggs Type Indicator Atlas of Type Tables, Macdaid, McCaulley, and Kainz, CAPT, 1985

This article was originally posted on StickyMinds.com on January 28, 2011