Don't lose touch

You're coming off kinda
Contrived and pretentious
You're not saying anything
We haven't heard before
You're caught up in an argument
—Against Me! (Don't Lose Touch)

Chris,

The job is going through yet another reorg. I think this makes the first one since you left two months ago. That doesn't bode well. This isn't surprising. The larger the company, the more churn I've found. Always reinventing yourself for modern times. That's what I keep hearing on the stockholder calls, at least.

Reorgs are weird. Jobs are lost. New hires bring new ideas. It's a time of pivoting and learning new things.

Well. It's a time for new things to be thrust upon the people further down shit storm mountain.

I had a boss who wanted to overhaul the way we used Jira. There was a specific type of story he wanted to get rid of. He was sure it wasn't needed anymore. Got the team's buy-in. When he put in the change request, the business told him they wouldn't do it.

He was furious about this cruft in his Jira instance. He'd checked with everyone. It took a public meeting for him to learn that accounting used those stories to check time allocations and determine which budget to assign the hours to.

He didn't check with all his stakeholders. Just the ones he thought he had. He was so dead set on getting his way that it cost him political clout and got him reprimanded. Really publicly.

There's a thought experiment called Chesterton's Fence.

The basics: a guy is traveling through a field on the estate he just bought when he comes across a fence running right through his property. He asks the groundskeeper what the fence is for. The groundskeeper says they don't know. They'll have it torn down.

Chesterton says, "No. Don't do that until you understand what the fence was for."

One of the transformation tragedies I've seen repeated again and again is this lack of consideration. New people come in with brand new ideas and implement them before realizing why the old practices were the way they were.

This inevitably fails.

You can't change the process without the culture allowing it. The culture had that fence there for a reason. You need to figure out what that reason was. Then you can alter things.

There is rarely, if ever, enough due diligence paid to this.

I'd love to say it's just managers doing this.

It's not.

I've seen developers rewrite entire programs because of one flaw instead of patching or expanding on the old one. It breaks my heart every time I hear "what if we just rewrote it in X language." So you're going to do nothing but change it so we all have to learn another language to understand this implementation? The computer doesn't care what language it's in. This is a vanity project.

Until there's solid business value for changing the language—deprecation of the language, difficulty finding developers who understand it—don't remove the fence.

Of all the Agile frameworks, Scrum does this the most.

It completely upends what was there before. Forces teams to be formed. Backlogs to be created. Ceremonies to be held. All without caring about what was there before.

It's a hard reset on how your company operates.

And the people above those who are transforming don't understand that they need to change too. So the culture hasn't changed, but the process has. It's doomed to fail from the get-go.

The way they combat this is by having an advocate for it on every team. Someone saying "No, no, you need to have faith." Witnessing to the company about the intended outcomes.

No wonder Scrum Masters are seen as annoying and useless.

The universal problem with changes like these is a lack of understanding. Why are we changing? What's the goal of the change?

Most transformations start with the answer instead of the question.

"We're doing Scrum now."

Okay. Why?

"Because we need to be more agile."

What does that mean?

"We need to deliver faster."

Why aren't we delivering faster now?

And that's where the conversation usually dies. Because nobody did the work to understand what fence they're tearing down. They just know there's a fence and it's in the way of the thing they read about in a book.

The problem shows up everywhere. Sales wants a feature by next quarter but nobody asked why the feature matters or what problem it's solving. Marketing launches a campaign before checking if the product can actually deliver what's being promised. Leadership mandates return-to-office without understanding what's actually broken about remote work.

Every time, it's the same pattern. Solution first. Understanding never.

I know the book is on your to-read list, Chris, but I can't stress this enough: you should check out Esther Derby's 7 Rules for Positive, Productive Change.

It's a beautiful deep dive on how to get out of this rut that companies, teams, and developers keep falling into. Derby walks through why changes fail and what you can do differently. Not just theory. Actual practices.

The core of it? Understand the fence before you tear it down. Figure out what problem you're actually trying to solve. Make sure the people affected by the change understand why it matters. Create the conditions for change to stick instead of mandating it and hoping for the best.

It's the kind of book that makes you realize how much damage we do when we move fast and break things that were actually holding the whole mess together.

I hope that helps.