Resistance is in the Eye of the Beholder

Before I start, I have to give credit to Esther Derby for nearly 100% of the value of this post. She does a free (free!!) monthly Q& A conference call.  During one such call a little over a year ago (“Reframing Resistance for Positive Outcomes”), she opened my eyes on a critical point.  Here’s the very first sentence of Esther’s discussion that day (not verbatim, but close): What resistance really means, if you look beyond the frustration, is a person not going along with your suggestion as enthusiastically or quickly as you would like.

Just this sentence sparked a major perspective shift for me.  The last four words put attention on the part the initiator of the change plays in the feeling of resistance.   Think of it like Newton’s third law: if I punch someone in the face, their face pushes back on my hand.  My hand might really hurt, but would it be fair of me to think ill of them for pushing back on my knuckles with their cheek?  I’m obviously heightening my role as aggressor in this situation, but even in this extreme example, I might have good intentions (e.g., it looked to me like they were about to hurt my friend).  Regardless: I took part in creating the pain I felt in my hand.

While this analogy is silly in some ways, I really like that it highlights something huge that I used to overlook when complaining about resistance: how does the other person feel about it?  Just as focusing on the pain in my hand is unfairly ignoring the pain in the other person’s cheek, complaining of resistance is ignoring the position that I have put the other person in.  They very likely don’t like pushing back, but I am forcing them to do so.  (Of course, they have the option of just giving in, but neither of us does well in that outcome.)

Esther went on to cover some very useful techniques for working through how to approach perceived resistance.  These techniques both involved shifting ones perspective: in one case re-framing the perceived resistance to find its potentially positive components, in the other case seeking an understanding of the other person’s perspective.  Doing the exercises really drove home the truth of her opening statement. Every example of resistance I could think of fit that definition.

One might consider this massive self-deception: if I always slide around to the other person’s perspective, am I simply explaining away resistance that actually exists?  Well, if my interest lies with progress that respects people for who they are, and if understanding their view helps me achieve progress, I don’t think I really care.  Regardless, I truly have come to believe that–in all but very rare cases (e.g., deep personal animus)–resistance is just one’s own view of the feelings one creates by pushing on someone else too fast, too hard, or too insensitively.

The tools Esther shared that day are great, but the really cool thing she did was helping me see the futility in fussing over so-called resistance.  Since then, I’ve stopped using the word in this context.  That’s a pretty damned good result for a free Q&A call.  Thank you, Esther!!

Re-Organizational Agility

At the beginning of this year, I had a discussion with some folks at various companies about organizational issues at scale. At one point we touched on our individual experiences with high-level company re-organizations. As we went around the circle talking about frequency of change, we learned that the represented companies re-organized about once every 18 to 36 months. This struck me as interesting because the language typically used to communicate such changes not only fails to communicate predictable fluidity, but on the contrary implies permanence. I don’t recall explicit claims of permanence, but the old ways are usually cast as simply wrong, the new ways as the solution to a problem. Not one of the many re-orgs I’ve been through is billed as what it truly is: an approach aimed at solving current problems, which is therefore likely to cease being useful when the primary problems change.

In the call, I suggested the idea that the architects of such re-orgs might recognize this and take a different approach. I’ve thought about it a lot since then, in part sparking my thoughts on all management as a support function. If you accept that management serves a support function, it follows that management should constantly adjust to the needs of the org it supports. How would this in turn change the periodic re-org?

I imagine that announcements would make clear that re-orgs are explicitly temporary attempts to respond to the current set of support needs. To prepare for future re-orgs, management could establish an ongoing process to assess the fit of management structure to needs. I think of this as a sort of product in development. Just as the Product Owner attempts to fit a product to the needs of their customers, the Re-Org Owner would attempt to fit their product (management) to the needs of their customers (development teams). As with product release, you could then adjust the frequency and breadth of release to get the appropriate level of feedback on your changes. In any event, you would work to move away from the typical pattern: big announcement, months of figuring out what it means, months of learning to do it, months of learning the problems with it, months of attempting to fix those problems, and finally abandonment for the next approach. This would help de-emphasize any sense of permanence in the re-org. In turn, this would hopefully help defuse a typical response to many of these re-org announcements: “Humpph. More management bullshit.”

It’s possible that this thinking just flows from my bias towards typical Agile team structure. What I’ve observed, though, is that the structure of those teams rarely seems to change based on the high-level re-orgs. In short: the small team structure seems to work more or less indefinitely; you just need to modify the support structure around it to adjust to changes over time.

Regardless, there doesn’t seem to be much here that is too controversial: Why not just be honest that things are going to change again? Why not be thinking ahead about the next re-org to avoid waiting too long and starting too jarringly? Why not try out those changes in smaller measure to validate your decisions?

Thanks to Simon Marcus, Anders Ivarsson, Mac Fowler, and Erik Schon for the very interesting conversation that inspired this thinking!