July 2022 – Bobbie Conti

Following up on the earlier post, as I have had Spare Time ^TM courtesy of a bout of COVID.

The Ripple Effect

I failed to mention previously that Big Changes tend to have ripples, and much like when you throw a rock into a pond and then another rock shortly after it the ripples sort of crash into each other, creating other ripples, is how post-major-change ripples go. For example: you have broad reorganization A – let’s say whole departments move, charters move, Big Changes happen. That’s the first rock.

As the ripples from the first rock stretch out to other parts of the water, things in that part of the water get impacted — in this case, there’s the tactics of administrating to a reorganization (changing of cost centers, migrating of resources, identifying process or people gaps, revising projections, etc.) and then there’s the tactics of reacting to a reorganization (I had guaranteed funding from your team to do X, you have gone through a reorganization, is my dependency on you at risk). After enough buildup of these ripples, it often comes to management’s (correct) mind that another reorganization is needed, to account for the things that weren’t immediately derived or attended to with the first one. This “aftershock” reorganization is typically smaller, more nuanced, and often has better details worked out (direct reporting lines, accounts for previously identified gaps, etc.). Perhaps pedantically, this aftershock can breed additional, smaller aftershocks (or, additional, smaller ripples) that eventually calm down as they extend through the system. Depending on what time of year The Big One hit, the Little Ones can extend 3 to 6 months afterwards.

Driving To Clarity

The unloved but absolutely necessary job of the shitbird.

I’m sorry, there’s no better way to put it, although LinkedIn me wants to change “shitbird” to “change facilitator” or something; the bottom line is that oftentimes the people who have to drive through the stickier parts of the ambiguity pursuant to a reorg (particularly when we are talking about things like charter, support, keeping programs running, transfer of knowledge, transfer of understanding (those are indeed two different things), and so forth) are incredibly unpopular because we are often the ones pointing out the un-fun things to be done. For example, if the reorganization of people and charter does not equate to a clean reorganization of resources, there’s typically a lot of tedious work in identifying which resources go where, which ones can’t move until they’ve been reviewed, etc. In a world where development teams are already stacked with features and fundamentals work, the tactics of a reorg often present an unfunded mandate and are not usually expressed in cost of hours (e.g., this reorganization equates to N developer hours spent on the tactics of the reorg).

Note I do not say “wasted”. The time spent inspecting and enabling a reorganization to be successful is *not a waste* if done transparently, with understanding of the purpose of the reorganization, and in good faith. Like any effort, there are costs to that effort; the overall reorganization ostensibly results in greater long-term efficiencies, development or productivity. There is a short-term cost, however, and I’ve yet to see any reorganization actually attempt to size the cost and get better at sizing and predetermining the costs associated.

Tactics vs Strategy

Thus far all of my conversation here has been about “tactics” because the reorganization itself is the output of a strategy decision, and the implementation and administration of the reorganization is all tactics. But should it be?

I’m fairly certain that my company is not the only company to regularly shift resources, assets and charter in a near-constant effort to get better: we are a for-profit company and like sharks you either swim or die. We spend money on things, we want to be as efficient as possible for the best possible outcome, and ostensibly every reorganization is made with that goal in mind.

In a world where this is the case then it occurs to me that, by now, there should be a playbook for these things: how to determine the lines of the reorganization, how to pre-identify some of the impacts (both proactive and reactive), and most of all size the costs associated. Those costs need to be juxtaposed with the previous planned expenditures and weighed accordingly – you cannot absorb the impact of moving a thousand people around with no delay in production or productivity; to do so is either specious or obtuse.

One could argue that we cannot get to the impacts of the proactive/reactive tactics to a reorganization because the people who tend to understand these pieces best are too close to the ground – they cannot be trusted, in advance, with the knowledge of the pending changes enough to provide sizing of impact, and so it’s better to let the reorg roll and then “just deal with it”.

If you cannot trust your team to size things in advance, that’s probably a signal to pay attention to. Let’s ignore that for now, because that’s not what we’re talking about here (but we will, later).

You can have some aspect of both worlds.

The Strategy of Shuffle

Working with the fait accompli that a reorg is coming, you cannot (for whatever reason) pre-plan the reorg transparently with your organization, and you have to land the message and then pick up the pieces: approach it as strategy.

Because this isn’t the first one of these you’ve done, and it won’t be the last.

Playbook

If you don’t have a playbook, build one. Literally start building one by capturing the experience of the pain of the tactics of this reorg:

What were the hardest parts of the implementation?
What were the things you didn’t plan for?
What were the things you planned for that didn’t actually happen? Or didn’t turn out the way you thought?
How much time did your team actually spend implementing the reorganization?
What projects for that period ended up being delayed (either directly or indirectly)?
Did any of your KPI’s suffer?
Did your OKR’s have to change?
How did your employee satisfaction scores change before/after/6months after 12 months after (for those who were part of the cohort before and after)?
What volume of attrition could you directly or indirectly tie to the reorg?

You’re already having to absorb the tactics of the specific reorg you’re undergoing right now, you may as well track this while you’re at it.

Sharing

As you’ve captured all this information, be transparent with it – share it with your team, share it with your management, share it with your impacted peers, share it with your leadership. None of these things should be sensitive and every single one of them is useful.

“None of these should be sensitive? What if my KPI’s suffered? What if our employee satisfaction scores suffered?”

I would argue that it’s likely anyone seeing this data already has access to it — it’s not unusual for employee health scores to be shared out semi-or-annually, OKR’s and KPI’s by their very nature are shared in a Measure What Matters context, and I guarantee that regardless of what they wrote on their “going away/changing roles” email everyone knows why someone left the team or company.

The transparency and sharing of the data facilitate conversation, they facilitate awareness, and most of all they facilitate the ability to identify areas to improve *next time* — because there will be a next time.

Benchmarking

If you’re thinking, “hey it looks like you’re gearing up to say now that I’ve measured all this and documented it, I should benchmark and improve” then ding! go to the head of the class. Because that is exactly what you (I, anyone in this) should do. If for no other purpose than your own for the next time you go through one of these, to better set expectations and understand the volume of work, and to better approach the tactics of *that* reorg, record what it took last time and use it to inform your experience the next time.

Forecasting

Obviously if every impacted team did exactly this then that would be a heck of a conversation with leadership about (and accrued body of data to inform) the strategy of reorganizing. Armed with the data of the costs pursuant to a reorganization (in time, developer productivity, attrition) vs. the benefits (in strategic pursuit, overarching delivery, etc.) leadership can make better informed and more surgical reorganization decisions. Specifically, armed with data about implementation times — e.g., if Reorg A took a really long time to implement because the volume of entrenched and shared resources was particularly gnarly to tease apart — then when approaching the next reorganization leadership can cast an eye in that direction and ask their middle management (who will be better informed on this aspect but also ostensibly in the Circle of Trust, or at least enough to help message the reorg) to size the effort for this bout and/or adjust their reorganization plans accordingly (move more/fewer people, move more/less charter, etc.).

In turn, much like any development effort, the management team can identify predictive costs of the reorg (if we do X, it will use up about Y productivity, and potentially impact Z project, to N degrees), avoiding many of those unpleasant conversations (or worse, handwavy conversations without any actual data attribution) that happen 6, 8, or 12 months down the line when we’re collectively trying to figure out why something did or did not happen.

Perfect vs Good

A quick note here about perfectionism: it’s good in small doses to get you directionally better at things. It is not a good management philosophy or philosophy to apply to any sort of “benchmarking and improvement” endeavor, which I would posit the Strategy of Reorgs as. Which is to say:

Your first round of reorganization benchmarking will not solve for All the Cases.
Your first or even second set of impact metrics will not be enough data to create a predictive model, but will be enough potentially to suggest correlation.
The practical upshot of this exercise is to fractionally minimize the pain and/or volume of expense with each go.

It’s not going to be perfect, ever. You are welcome to aim for perfection; understand you will oft settle for good.

Which is better than settling for nothing at all.