What Is Protected in Your Organization?

More importantly, what does that tell you? 

It’s a simple question—and one of the most powerful ones you can ask.  

Are some of your teams not producing like you think they should? Ask what the members are protecting.  

Are some of your change initiatives halted? Ask what is being protected in the status quo.  

Are you finding that your projects are grinding to a halt? That the competition is beating you to the market with new products and services? That there is misalignment between teams? Chances are, all these things are being sacrificed to protect something. What is it?  

OK, all of that might sound a little dramatic…but it’s not wrong. We protect what we value, consciously or unconsciously. And when values are not aligned, that’s when organizational problems emerge.  

In short, if you want to know what a person, a team, or even an organization as a whole really values, see what it protects. Only then can you make progress. 

What Often Gets Protected in Organizations 

What does that mean, exactly? In business, for example, we don’t often think in terms of protection. We think in terms of things like profit, value, return, and so on. But everyone is also trying to do a job and preserve some part of the status quo.  

Here are some examples of things people protect:  

Budgets. Team leaders and department heads often have to fight for budget dollars and are very much afraid of losing them quarter to quarter and year to year. Some will protect their budgets by spending cautiously, seeking justification for every penny. Some will protect them by going on spending sprees to “use up” budget so that their line items are not cut next year. Protecting budgets can slow down innovation even as it encourages reckless spending.  

Titles and reporting structures. Some people, having worked their way up the corporate hierarchy, are loath to implement any changes that might shift their position. Offer them a new, better title and they are on board; suggest that they will play a support role, and they balk. (Quite a few middle managers feel this way when transitioning to agile teams where they now have to report to, and support, the team, rather than vice versa.)  

The power to assign work. Some people don’t necessarily want titles, but they want a large say in what gets done. Again, managers often struggle when their roles change from someone who assigns work to someone who sits back and watches a project owner prioritize what gets done. Likewise, many smaller organizations and agencies build in extra layers between the client and internal producers precisely because they don’t want to cede the power to say what work gets done.  

Client access. Who can call on a client? Ask questions? Provide status updates? In some organizations, client access is hoarded because it is seen as leverage. In others, it is assigned to those lowest on the org chart because the perception is that dealing with clients takes time (and so managers’ time is really what is being protected). This can even be true with internal stakeholders. I remember being a developer on a new team and being told that the analyst will talk to the business and as a developer I’ll get my requirements from the analyst. It felt like I was in the movie Office Space.  

Projects. Who decides what the next project or initiative is? Whoever decides that has a hand on the reins of the organization. Many people will protect that privilege.  

Job security. When people fear they might not keep their current positions, they will avoid anything that might draw negative attention to themselves. Thus risky-but-profitable projects will be shunned, and feedback will be minimized so that no one gets “shown up.”  

Knowledge. Knowledge is power. Some people believe that if they know something others don’t that makes them important. This could be knowledge of a business process, knowledge of a technical process, or anything else. I’ve seen people and organizations horde knowledge because they believe its “job security.”  

There could be more things, of course. The main idea is that individuals and teams will often protect things having to do with their power, status, autonomy, decision-making, and job security. Problems arise when these things are protected at the level of the individual or the team, counter to what needs to be done for the good of the organization. 

Defensive Maneuvers: How These Things Get Protected 

It is OK to protect something. Protection, by itself, is a good thing—noble, even. Protecting something only becomes a problem when people react defensively, and in a way that impedes further progress. Just as a defensive person might make it hard to have a difficult but necessary conversation, defensiveness like the kind we’re describing can derail an entire strategy or initiative.  

Here are some behaviors we’ve seen that point toward defensive protection:  

• Micromanaging the work that teams do 
• Insisting on assigning work, sometimes at the drop of a hat 
• Coming up with “special projects” 
• Sticking with older workflows or processes 
• Demanding justifications for every little change 
• Blocking access: To resources, clients, other teams, anything 
• Not seeking, nor listening to, feedback 
• Delegating any and all steps involved in change to someone else

Understanding How Hard Transformation Is, Given What’s Protected 

Why all this talk about protection? Simple: Once you understand what is protected, you can see exactly when and why change will be hard.  

Take, for example, a medium-sized organization that wants to start using agile teams. Once all the stakeholders are on board and everyone is sufficiently trained, this should be easy, right?  

We’ve found that this is not always the case. We strive to construct our agile teams in way that provides the most value; when organizations are protecting the wrong things, this typically restricts the “flow” of that value. For example, most organizations like to have core competence in shared services like database, infrastructure, and quality assurance. To reduce handoffs, we try to build cross functional teams that can, ideally, deliver something end to end without needing to go to an outside team. In the ideal case, these people would directly be on delivery teams…but that could make a QA manager feel like they are “losing” their team. And that will make them, in turn, want to fight to keep people in their silos.  

Of course, this principle goes well beyond agile transformation. Any sort of organizational change—entering a new market or territory, producing a new product, acquiring a new company, adding a new leader—will trigger some defensiveness. When the change happens at a pace slower than you want or anticipated, begin asking yourself: What is being protected? And by whom?