I noticed at the recent agile conference that there were lots of people who billed themselves as agile coaches, and several sessions on coaching. Seemed like more of both than in past years.

I consider myself a coach, too, though not with a capital C.  I usually coach managers or teams, and sometimes coaches. Mostly, I’m a consultant and coaching is part of the work I do in that role.  But some people lay claim to “coach” as their job description.  And some of those people have training from a coaching school.

All this, and a little story my friend Johanna told about an experience she had with a coach got me thinking about the different sorts of problems people bring to coaches, and the confusion that results when the coach is a “coaching process” type coach, and the problem is a skills-based problem (which requires content knowledge, in addition to process knowledge). Or a problem that calls not only for a coaching model, and a bunch of other models.

Back when she had a corporate job, my friend Johanna Rothman had the opportunity to work with a coach on a problem she was experiencing at work.  It must have been an enlightened work place, because they employed Johanna AND coaches, whom they dispatched when a manager needed a bit of help. Johanna’s hope was the the coach could help her with the specific problem, which she hadn’t been able to figure out on her own.

Johanna explained the problem to the coach.  The coach responded, “The answers are inside you.”

Johanna tried explaining the problem again.  The coach answered, “The answers are inside you.”

The answers were not inside Johanna (at that time…I bet they are now).  She needed specific information, direction and guidance to develop a new skill that would enable her to solve the problem.  The response Johanna received to the problem she described was woo woo nonsense. It was no help at all. The coach was trying to be helpful, I’m sure. And she was acting out of a coaching model, just not one that fit the situation.

The Range of Coaching Practice

If we’re talking about a skill—whether it’s TDD, interpersonal feedback, or object oriented design, influencing change across the organization—the answer is not inside you.  If you are shifting from a serial mental model of software development to a iterative/incremental mental model of software development, the answer is not inside you.  Willingness to learn is inside you. The desire to maintain a good working relationships is inside you.  The yearning for pride in work is inside you. The desire to see the organization improve is inside you.

The specific skill is not.

You need teaching, training, and  direction, along with coaching and feedback. A coach in this situations needs to have task-specific (content) knowledge, in addition to coaching skills. And those coaching skills are likely different from the skills a life coach or goal coach brings to the table—unless they worked in the content field prior to studying a coach curriculum or taking up the coach label.

Life coaching—finding the answer in side you— is useful when you have a life problem; when you need a skill, you need  skill coaching

Another friend, Don Gray, recently helped three people understand how an interaction blew up. As they unwound personalities and communication styles, two of them heard some information their default preference didn’t deal (well) with.  He helped them recognize how their communication preference helped them, and hindered them. He helped them see additional options. To do this, he needed a coaching model(s), plus content knowledge on communication, human interaction, personality and cognition. Rare indeed.  The answers may have been inside these people, but it took more than a coaching model to bring them out.

And of course, some times the answers are inside us.

Satir coaching assumes that each of us has the resources to be be happy and successful as a human—but may not be using all our resources to their full potential.  Jerry Weinberg’s fab book, More Secrets of Consulting: The Consultants Tool Kit, is inspired by Satir’s self-esteem toolkit, and the book is tremendously helpful.  I’ve studied the Satir model for many years, it informs much of the work I do with individuals and groups (and certainly how I live my life).

Likewise, the Solution-focused Coaching model assumes that the person being coached has some experience solving the problem for which they have sought coaching.  This model assumes that the coachee has all the competencies needed to come to a solution.  I had a little experience of this at the previous Retrospective Faciliator’s Gathering in Tisvilde, Denmark.  Josef Scherer offered a session on Solution Focused Coaching, and since I a little stuck in my writing practice, I volunteered to be coached.  It helped me  a lot—the answer was inside me.  But this sort of coaching wouldn’t have helped if my problem was that I didn’t know how to structure a coherent sentence.

There are other Coaching models:  GROW, Achieve, and many more. More than you can shake a stick at (just google “coaching models”).

When someone is stuck, they may need a jiggle, in the form or a reframe, or a prompt to remember what they do know about solving the problem. When someone is struggling with an interpersonal issue or a life issue, they answer may lie within, and need a little help from inner resources to come out.

But sometimes, the person needs context, information, demonstration, a straight answer, or a skill.

Related:  A Coaching Toolkit

Jurgen Appelo, the wildly popular Dutch blogger, makes lists, among other things. His latest is the Top 100 Agile Books. He’s worked out a formula that takes into account reviews, average ratings, and continued interest. Not perfect, but I’m not going to complain, because I made the list–twice!

Behind Closed Doors: Secrets of Great Management (co-authored with Johanna Rothman)

Agile Retrospectives: Making Good Teams Great (co-authored with Diana Larsen), was also picked by Amazon.com’s editors as one of the Top 10 Tech Books the year it came out.

In case you are wondering, I’ve got two books in the works now.  Team Traps (How to dig out if you are in one, and steer clear if you’re not) & an as-yet untitled book on shifting management out of command and control.

I’m a big believer in 1:1 meetings on manager-led teams. It’s a way to connect with people, stay in touch with progress, learn about problems early, coach, work on career goals, offer feedback.

But if you are the manager for a self-organizing team, you need to adjust the way you do 1:1 meetings.

First, unless you are coaching someone on task accomplishment, do not ask about progress and status of tasks. On self-organizing teams, team members organize the work and make commitments to each other. If you as a manager insert yourself into this, you are communicating the the commitment is still to you, not to other team members. If you want to know about task progress, walk into the team room and look at the task wall or burn down chart.

You will probably have less visibility into the day-to-day workings of the team and team members. That means you are less likely to have useful feedback to offer on a regular basis. Ideally, much of the feedback on a team should be peer-to-peer. You need to get involved when the team has tried (using effective feedback techniques, not hints, not vague general statements), there hasn’t been a change, and the behavior is impeding the team. Getting in the middle of a feedback between team members when you don’t need to only creates problems and erodes trust on the team. When someone comes to you hoping you’ll carry a message for them, coach them on how to offer effective feedback, so the situation gets handled where it lives, between the team members.

Don’t meet every week, unless you are coaching on a specific issue (that you are qualified to coach on), or unless there’s a “get well plan” that you need to manage. You do need to stay connected to people; there are lots of informal ways to do this with out meeting every week. Meeting every week sends the message that you still want people to look to you for answers, help, and guidance. You may want that, but consider the effect on the team and their growth and capability.

You may still have a role in approving vacation (work on changing that, since it implies that the company doesn’t trust people very much). Keep that to a formal sign-off role. The first negotiation needs to be with in the team. I talked to a manager who approved a vacation request right after a team had committed to work for an iteration. (Who knows why the person didn’t mention it to the team, but he didn’t. That’s a separate problem.) The manager approved the vacation, then asked the team to cover the guy’s commitments while he was sunning himself on the beach. The team rightly refused, and insisted on renegotiated with the product manager to reflect the fact that they weren’t going to be able to accomplish as much with one team member gone for the entire iteration. The manager realized much later that he’d set the team back in mutual trust and accountability by not sending the guy back to work it out with the team.

Work on professional development, but remember that the team member you are mentoring needs to negotiate tasks and roles with the team. For example, if someone wants to learn more about project management, you don’t get to say “start managing the iteration as a project.” That breaks down the work the team has done to organize their work and erodes shared commitment.

Ask about impediments and blocks outside the team, those that need management action to fix. You can’t fix everything, but you can investigate, look for patterns of blocks mentioned by multiple team members. You can create an impediment backlog and post your burndown to the team.

Ask about HR concerns. For many agile teams, traditional job descriptions, career paths, and other personnel systems don’t fit agile work very well, so you want to know when there’s dissatisfaction and understand when and how policies are getting in the way of teamwork and team work.

Your job with a self-organizing team is to establish conditions for success, make sure the team has appropriate resources and appropriate boundaries, to remove impediments and improve the work system. It’s not to give task direction and hold individuals to account (except as noted above) . The team is responsible for organizing their work, tracking progress, and communicating to you when there’s a problem. You job is not to inflict help–that keeps the team from learning, and keeps them dependent on their manager.

Hierarchy acts as an amplifier, and manager’s actions are always under scrutiny. If you want the team to self-organize and reach their potential, don’t send them a confusing message that they still need to turn to you for day-to-day task guidance, status reporting, and problem-solving.

Samuel Culbert interviewed on NPR.

Employee performance reviews should be eliminated, according to UCLA business professor Samuel Culbert. “First, they’re dishonest and fraudulent. And second, they’re just plain bad management,”

There’s also an excerpt from Culbert’s book, Get Rid of the Performance Review! He doesn’t pull any punches.

It’s time to finally put the performance review out of its misery.

This corporate sham is one of the most insidious, most damaging, and yet most ubiquitous of corporate activities. Everybody does it, and almost everyone who’s evaluated hates it. It’s a pretentious, bogus practice that produces absolutely nothing that any thinking executive should call a corporate plus.

And yet few people do anything to kill it.

How could that be? How could something so obviously destructive, so universally despised, continue to plague our workplaces?

In part it’s because the performance review is all executives have ever known, and they’re blind to the damage caused by it.

In part it’s because few managers are aware of their addiction to the fear that reviews create amongst staff, and too many lack the confidence that they can lead without that fear.

In part it’s because HR professionals exploit the performance review to provide them a power base they don’t deserve.

And in part it’s because few people know an alter-native for getting the control, accountability, and employee development that reviews supposedly produce—but never do…

They fail to realize the most essential tool they have in getting quality performances is a trusting relationship with the people who work for them. It’s really that simple. If they understood this, there never would be something as stupidly one-sided as a performance review that is defined by domination by the boss.

As you know, putting an end ratings, rankings, and annual evaluations has been one of my personal crusades for some time.  Glad to have some company.

I suspect many managers would be happy to dispense with reviews.  But reviews are inextricably tied to another damaging practice, so-called merit pay.  So if we want to get rid of performance reviews, we have to get rid of the illusion of merit-pay, too.

A few ideas about what to do instead in an article I wrote a couple of years ago.

We’ve long lived with the assumption that the people at the top of the organizations are the ones who understand the business.  They understand the market, the product, the customers.  They hold the financial information about how the company makes money and the current financial status.  Since they hold this info, they also know what the company should do—on a strategic and tactical level.

One assumption behind this model is that the brains are at the top of the organization and the brawn is at the bottom. Knowledge flows down, but mostly on a “need to know” basis.  So it filters down as a trickle, not a torrent.

At the same time, the hierarchy acts a filter from the bottom up.

Day-to-day knowledge about how things really work, who to talk to when you want to get something done, how to work the (doesn’t work as defined) process, work arounds, greasing the skids, what the status really is and other useful stuff is concentrated at the bottom of the organization.

The higher in the organization, the more the day-to-day reality of business is abstracted to numbers. And because the people at lower levels in the hierarchy don’t want to displease people at higher levels, they tend to minimize bad news—so the picture becomes rosier with each level it ascends.

One can argue that this model of knowledge concentration has worked. There are many companies that started this way, and they are still around.  But I think the days when it served us well are over. It doesn’t meet the needs of the our times or our industry.

For one thing, we aren’t pouring ingots. We do knowledge work. We need to know about the context, customers, and cash flow in order to make the right products.

We live in a time of fast change. The competitive environment and customer preferences can change on a dime.

This bifurcated concentration of knowledge does not serve us.  It makes companies slow as requests for approval work their way up the chain.  Worse, it makes companies stupid. Think about it.  How many times has a decision from top management looked silly, misguided, or malicious given the realities of implementation?  How many times has management countermanded a decision made close to the work because the people who made the decision were missing some piece of information about market context, customer needs, or how cash comes in the company door?

If we want our companies to succeed, we need to make the over-lap between contextual knowledge and implementation knowledge bigger.

Last summer I participated in a seminar.  The format included group discussion, and discuss we did.  But one member of the group, Bernard, didn’t discuss so much as pontificate…at length, and often on topics that were tenuously connected to the subject matter of the class.  And, when Bernard got to a pithy phrase, he repeated it three times:

Trust (pause) is the essence of change. (Meaningful look around the room).

Trust (pause) is the essence of change. (Meaningful look around the room).

Trust (pause) is the essence of change. (Meaningful look around the room).

Most of us in the group made our point in a minute or two.  Bernard went on for five or six.

I found myself feeling annoyed.

I also found myself waiting for the seminar leader to do something…redirect Bernard, bring him back on topic, give him feedback, something.  But the seminar leader just listened to Bernard, and nodded her head.

When we gave 5 minute presentations, Bernard’s presentation lasted 15.

I still found myself feeling annoyed.

I still found myself waiting for the seminar leader to do something…point out the time limit, give Bernard a sign he was over time, ask him to wind it up.  But the seminar leader just listened to Bernard, and nodded her head.

When I looked at my own motives, I realized that at first, I was giving space to Bernard, since I didn’t know him, and wanted to withhold judgement. But by the second meeting of the seminar, I was keeping quiet because I didn’t want to appear biased, since Bernard was from a different culture.

In short, I was participating in a situation where I felt annoyed (by Bernard), let down (by the seminar leaders), and put upon (by myself, for holding back). I was also withholding information from Bernard, and that was getting in the way of my having a constructive relationship with him. I wondered how many other people in the workshop were experiencing something similar.

Now, often our inclinations in such situations is to look at individual behavior, give feedback, and ask individuals to act differently. Sometimes that’s absolutely the right thing to do.  Other times, it’s more helpful to look behavior of the group as a whole.

One day, after Bernard went on a sententious ramble for the upmteenth time, I had a moment of recognition: we have a pattern here—repeated events that have meaning over time—and I am part of it.  I was colluding with the pattern, helping to hold it in place.

This time, when Bernard started his presentation by declaring he was going to play some music for us and announced “This is your time, I want you to get up and move to music,”  I decided not to participate in the pattern or wait for someone else to change it.

I took Bernard at his word (at least the first part of his sentence).  Rather than swaying to Bernard’s music for 10 minutes (as the rest of the group did), I checked my email.  I responded to a couple of items that needed quick attention.

When Bernard finished (15 minutes beyond the stated timebox) the entire group took a break.  During the course of the break half the group members talked to me about my action.  I was not the only one who was irritated by the way Bernard was interacting with the group—nor was I the only one colluding with the pattern. Bernard was taking up a lot of air time because we let him take up a lot of air time.  We had a choice. We could continue in the pattern, or we could shift it.

And we did.  When Bernard started down a topic that was unrelated, someone would gently remind him of the topic at hand. When he got close to the end of a presentation timebox, some one gave him a signal that he had two minutes left.  The first time it happened, Bernard looked shocked—a shift in the pattern can be disconcerting, especially when the previous pattern worked (at least for Bernard).

And we formed a different pattern. We stopped waiting for our “leaders” to solve all issues with the way our group handled disucssions. One of the people who had a closer relationship with him, spoke to him directly about how Bernard’s tendency to go on affected him personally. And we all started being more honest with each other.

This article first appeared on stickyminds.com.

Not long ago, I received a call from someone who wanted to hold a retrospective. “Tell me about your goals for the retrospective,” I prompted. The requestor proceeded to describe what amounted to a mini-witch hunt. If you really want to wreak havoc with a team, try having a retrospective for these reasons:

• To motivate another group to fix the way they do their work
• To make it eminently clear that Person X isn’t doing his/her job—in public
• To definitively assign blame for poor design, missed deadlines, injecting bugs, and other disappointing results
• To force two individuals to solve a long standing conflict—in public
• To provide feedback on Person Y’s poor performance—in public
• To prove that if those people had done better, everything would be fine

On the other hand, if you want to learn from experience, build on what works, gain perspective, and decide what to do differently, a retrospective can work for you. There are plenty of reasons in favor of well-run retrospectives, which help teams to:

• Take a “whole system” view of their methods and practices
• Discuss issues before they build up to a crisis
• Look at what’s working and build on successes
• Create experiments to evolve and improve practices
• Fix what’s within their own control, rather than waiting for management to take action
• Raise the visibility of impediments that managers need to work across the organization to fix

What follows is the outline of a successful retrospective.

Set the Stage

Lay the groundwork for the session by reviewing the goal and agenda. Create an environment for participation by checking in and establishing working agreements. Some people feel this preparation isn’t real work, but believe me—when you skip this part of a retrospective, you may save a little time, but you’ll pay for it later in the retrospective. Skip this part and people are less trusting and less likely to participate.

Gather Data

Review objective and subjective information to create a shared picture of the iteration. When the group members see the iteration from many points of view, they’ll have greater insight and will be more likely to move beyond their personal views to the see the big picture of how the team works.

Generate Insights

Step back, and look at the picture the team has created. Use activities that help people think together to delve beneath the surface. When people think together from shared data, they are more likely to arrive at ideas that the whole group supports.

Decide What to Do

Prioritize the team’s insights and choose a few improvements or experiments that will make a difference for the team. Be sure to identify concrete, small steps that the team can take in the next iteration—one colleague calls them “now actions.” And make sure that the action steps are folded into the overall work plan, not kept to the side in an “improvement plan.” When improvement is part of the regular plan, it’s seen as a normal part of work, not something extra that the team will get to if they have time.

Close the Retrospective

Summarize how the team will follow up on plans and commitments. Thank people for their hard work, and do a little retrospective on the retrospective so you can improve your retrospective process, too.

This may look like a lot to cover in one meeting; but each step plays an important part, and needn’t take a long time. For a two-week iteration, you can cover these steps in an hour or so. For a slightly longer project (a month or so) dedicate a half-day to deciding what to do better next time. For a project that lasted a year, you’ll want to spend more time. Short changing your retrospective means short changing your chance to do better next time. Improvement doesn’t happen by hoping; teams need to dedicate time thinking and learning.

Successful organizations know how to evolve to meet ever-changing expectations, rather than holding onto what used to work. Becoming comfortable with change, learning how to try something new, and measuring how well it works are critical business skills. And retrospectives are a great way to learn those skills on a team level.

So, you’re on a cross-functional team.

Great.  You’ve got people will different skills and different points of view.  That means conflict is not just likely, it’s inevitable.  Conflict can lead to increased trust and creativity–if you know how to recognize the source, understand your default conflict mode and have strategies to handle the conflict without confrontation.

Don’t let conflicts fester and brew.  Come learn the skills to turn conflict into complementary action.

Sign up now for Secrets of Agile Teamwork or email me if you’d like to learn more.

You’ll also learn how to:

Untangle communications gone awry–before they destroy working relationships

Offer interpersonal feedback to improve working relationships

Make your team leaderful, not leaderless

Recognize the visible and invisible structures that affect teams.

Secrets of Agile Teamwork

June 22-24 in Portland, OR

Too often, manager in organizations act as if changing behavior in an organization is a simple matter of “make it so.” Some changes are like that–but most significant changes are not.

Systems drive behavior. Therefore, if you want to change behavior in an organization–increase accountability or teamwork for example– you need to understand the factors that are driving the current pattern. Telling people to change the way they act (push) or talking about a vision (pull) isn’t sufficient. If you want to people to change their behavior, change the system that drives the behavior.

Let’s look at an example that I see show up quite a bit.

Say the managers in an organization have decided that they want the productivity and morale benefits of cross functional teams. So they put together a cross-functional team–a three developers, a UX/UI person, and a couple of testers.

The managers charter the team to work on the next release of a product. It’s a compelling goal, one that all the members of the team understand and support. It’s an exciting project both from a technology and a market perspective. The managers really want to support teamwork and collaboration, so they send the team to an team building offsite.

When the team comes back, they are enthusiastic. But after a while, the managers notice that the “team” part isn’t working. Their efforts are fragmented, their priorities are in conflict. No one is intentionally hoarding information, but somehow information that everyone on the team needs to know doesn’t spread to all memebers.

It’s pretty much the same pattern as existed before the initiative to form cross-functional teams.

How can this be? This group has a shared goal and interdependent work that requires all of their skills. They are all accountable for the success of the release. So why aren’t they acting like a team?

It might be something about the individuals. But it might be something about the visible and invisible structures in the organization that are holding the old pattern in place.

Containers, Differences and Exchanges: structures that drive patterns of behavior in organizations.

Containers hold the focus of the group. Containers can be

physical–a team room
organizational–a department
psychological or conceptual–a goal, a set of professional concerns

Some containers are obvious, others are not.

Differences are just that, differences among the people within a given container, or between containers. There are an infinite number of difference, but not all of them make a difference–hair color for one example. Differences hold the possibility for constructive complimentary action or for conflict. Some differences are negotiable and mutable (e.g., skills) others are not (e.g., gender).

Exchanges are the flow of value (information, money, energy, social connection) within and between containers. Exchanges might be allocated funds, salaries, policies, formal and informal communications.

Two of the developers report to the same manager. The third reports to a different manager. The testers report to the test manager, and the UI guy reports to the UI manager. These reporting relationships line up with departments within the organization, and they’ve been in place for a years.

Each of these managers has a different perspective. Each manager has been given different objectives by his/her manager. The people on the team know that they need to attend to their manager’s concerns–which don’t line up completely with the project goals.

The developers are on one floor of the building. The testers and are on another floor, but don’t sit close to each other.

The UI guy is working on five other projects.

Here’s a sketch of the containers for this team.

The dotted line circle represents the project container. But that’s not the only container and it’s certainly not the strongest.

The obvious solution is to put the team in a team room. That would probably help a lot. But it’s not the only possibility for action to shift the pattern.

I posed this question to the participants in my workshop at Agile France, and here’s what they came up with:

Container interventions

• Strengthen the shared picture and vision of the product
• Strengthen focus on common goal
• Move the team to a team room or at least to contiguous cubes
• Have all team members report to one manager who has responsibility for the project
• Remove roles, make everyone a team member rather having distinct roles such as developer, UI designer/developer, tester. (Obviously this won’t result in everyone having the same skills, but will reduce the strength of the role container)
• Make the project container stronger

Difference interventions

• Align management objectives
• Cross-train to create generalizing specialists vs. specialists

Exchange interventions

• Provide a facilitator
• Change the rhythm and content of meetings (meetings can also be thought of as a container)
• Have team members report their status to each other
• Hold a retrospective
• Have a social exchange
• Show and explain how the project and each person contributes to the company
• Change the bonus structure

An interesting list—and in my experience, a much longer list than the question “How can we get them to work together as a team” will generate.  And that’s the point.  Looking at Containers, Differences, and Exchanges shows possibilities for action that will shift the pattern.

(The concept of Containers, Differences, and Exchanges comes out of Glenda Eoyang’s work on Human Systems Dynamics.)

A while back, I sat in on a birds-of-a-feather session on organizational change.  The main theme was bemoaning the difficulty changing even mid-sized organizations.

When people talk about how hard it is to bring change there’s a tendency to blame:  people who don’t turn on a dime are labeled resisters, NoNos,  dinosaurs, laggards.

There certainly are people who don’t change as quickly and with as much enthusiasm as the people behind the change would like.

(I heard one agile evangelist  complaining about people who weren’t embracing scrum after a two-day workshop.   “I want them to drink the Kool Aid,” she declared in frustration.  Yikes!  I want people to consider and wrestle with a new idea, not accepted it as someone who has given up free will. I hope she was ignorant of  Jonestown.)

There are many reasons people don’t change as quickly as we’d like.  A few I cited in Seven Lessons for a Top Down Change:

they don’t know how to do what they’re being asked to do.

they don’t feel they have time to learn the new way and still meet existing goals and targets.

they believe the existing way is better.

they don’t think the new way will work.

they believe the new way will cause harm—to customers, the company, the employees, etc.

they don’t like or don’t respect the person requesting the change.

the new suggestion is counter-intuitive given people’s existing models of how the world works.

the new way runs counter to existing reward structures or other organizational systems.

When there’s been a failed change or a change that went badly, people may figure that they can simply wait out the change. I’ve certainly seen re-orgs done and undone within a year.  And not matter how good a change looks, it’s bad for someone, somewhere in the organization.

People have a valid reason not to change–from their own point of view.  Labeling them will not help.

Most change efforts take a deterministic approach to change.  Set the vision, establish a sense of urgency (usually through pep talks)  and then pull and push people towards the desired state.  That may work with a simple change.  But most change isn’t simple.

Entirely apart from the (normal) human responses to change, there are structural and systemic factors  that make change difficult in organizations of any size.

So sitting there in the BOF, I thought about the times that I’ve seen top down and bottom up changes grind to a halt.

Hierarchy acts as a filter. Change from the top can stumble when the desired change doesn’t mesh with realities on the ground. Other top down changes falter when there isn’t sufficient understanding of the gravity of the need for change–what’s self-evident at the top isn’t communicated to the people being asked to change. Some popular writers on change talk about creating a sense of urgency. One SVP attempted to generate some urgency  by declaring he wanted seven scrum team up and running by a certain date because it was his birthday–which generated cynicism.  Urgency doesn’t come from a “vision” or from pep talks. It comes from a clear understanding of the current reality and it’s implications for the organization (and the people in the organization).

Bottom up changes peter out when they run into systems, structures, policies, and procedures that hold the current pattern firmly in place.  For example, grass roots efforts to form teams can fail when HR mandates forced ranking.

From both directions, it’s critical to understand the visible and invisible structures and how they hold current patterns in place.

If you want to change patterns of behavior, you need to know something about the pattern you want to create.  You have to understand how the work works, see the system and change the system.  Pulling and pushing people won’t change the pattern (but it will result in the predictable responses that people have when they feel they are being pulled or pushed).