Here's where change starts to go wrong

​Hey Reader,​

In my last newsletter of 2024, I gave readers a peek behind the content curtain and shared my newsletter's focus for 2025: helping leaders develop cultures of change readiness, build their organizations’ overall change capabilities, and expand their organizations’ capacities for change.

All year long, I’ll be sharing the key tools, methods, and areas to focus on when it comes to developing change readiness. More importantly, I hope to help leaders with their mindset, positioning change readiness as not just a thing to do but a way for an organization and its people to be.

I’m going to explore what skills and abilities help catalyze change and how leaders, employees, and teams can empower one another to build their capabilities when it comes to thinking about change, designing strategies, leading teams through change, implementing strategies, and sustaining change long-term.

My plan is to open up the vault to share everything I know that will help organizations get change ready, because I want the folks in my network – the ones out there doing the good work – to achieve their missions

In my first newsletter of the year, I dug into how vital it is for leaders to define the why for a change – its purpose. The real, dictionary definition of purpose: the reason for which something is done or created or for which something exists. Literally: why are you doing this? Why is this happening? Why is this changing?

I promised to show you how you can use that why to follow a “purpose pathway” to help a change strategy actually design itself.

But the responses to the first newsletter (and my ongoing conversations with leaders this year) made me want to take a step back, reiterate something, and unpack it a little first: when you state the purpose of a change, it has to be the real why, or the tactic of using the purpose to more easily design the change strategy won’t work.

So in my second newsletter, I tried to make it very clear that defining the purpose or why = telling the truth (not the "mission and vision" version of why – the real purpose of the decision or change).

Which made me think...I should still give a more detailed walkthrough of what happens when you design a change strategy based on a purpose or why that is not the real one, before I show you how to do it the more effective way.

Because change readiness is not about checklists, spreadsheets, tactics, assessments, or plans. It’s not even about best practices, because who defines what is best, and how is a leader supposed to apply those practices to their own organizations?

In the past fifteen years, I’ve found that the #1 thing a leader can do to be change-ready is to be open to leaving the status quo of how organizations change behind and trying something new – approaching change with honesty, humbleness, compassion, curiosity, and clarity. Mindset first. The strategy follows.

Which means that we really have to understand how change typically works and where it goes off the rails at organizations before we can do something differently.

So what happens when you design a change strategy based on a purpose or why that is not the real one? Here's an example:

Say the leadership team of organization decided to implement a new project management software. The idea came up when they recognized a key frustration they had in common: their middle managers could not give coherent updates about how employees on their teams were spending their time. Why were projects behind, deadlines shifted, and milestones missed? No one could really say. And yet, the teams were busy! And the managers were asking for more headcount!

One leader suggested that they start making everyone clock in and out. Meh. Not really their culture, and that wouldn’t tell them what they needed to know: what are people actually doing when they’re here? They wanted to create accountability and facilitate reporting. Another leader said that they should start to use project management software to track their work. Yes!

This leader was tasked with evaluating options and bringing the best few back to the team. They wanted one that created clear and engaging reports and dashboards that managers could use to show them what people were doing. They would not only be able to see when things were off-track, but they could see whose fault it was.

They also wanted the software to integrate with some of their other systems. They compared three options and chose the one in the middle of the price range because that’s what people do. They wanted to roll it out before the next quarter began, so they made an announcement to teams that they were going to begin using this new software right away.

They told employees that project management software helps users stay organized and focused on their work, that it facilitates communication and collaboration within and between teams, and that it helps projects stay on time and on track. All of those things would help the organization work toward its mission.

They began to implement the software, telling managers that it was essential that everyone was onboarded into their accounts and fully utilizing the software before the next quarter began.

HR scrambled to get trainings on calendars and reminded people to show up over and over. IT created accounts and grew frustrated as folks couldn’t sign on/signed on incorrectly/asked IT for help using the software before they even attended any training.

People complained, or said they were relieved to finally have a solution to project management at the company, or claimed that they had never heard the announcement because they ignore company emails, or continued using the project management system that they had created for their teams independently with other spreadsheets, whiteboards, and software.

The new quarter began and the leadership team set a deadline for managers to create dashboards and report on their teams’ productivity. Managers pleaded with teams and reminded them to track every single task in the software. Employees utilized the software in the ways that best suited their own needs, or in the ways that they could even figure out, or not at all.

When reporting time rolled around, managers created reports that made their teams look productive, or reported on what they could, or complained that they couldn’t create reports at all because there was too much data missing.

The leadership team was frustrated that they mostly didn’t get the information they had been after, and either said that the software had been a waste of resources, or claimed that it was fine and would take time to implement, or said they had gotten exactly what they needed, actually, because they had been the one to recommend the idea from the beginning and wouldn’t stop supporting something they had already decided was good.

Either way, the leaders would stay on top of the managers to stay on top of their teams and do more trainings and send more reminders and carry on and try again next quarter.

This is what I refer to as a “change fail”

Unfortunately, this happens time and time and time again at organizations everywhere, of every size, in every industry.

It might sound super familiar to you.

Why does change happen this way?

It’s not the communication strategy or the employee resistance or the managers or the timeline – at least not any one of those things on their own.

They’re all symptoms of a root problem: the purpose of the change and the strategy that was designed to implement the change were completely disconnected.

Why did this change happen? Because the leaders wanted visibility into what employees were actually doing with their time? Because they wanted to create accountability and facilitate reporting? Because projects were behind, deadlines were shifted, and milestones were missed?

Yes. And…

The leaders were frustrated that their middle managers could not give coherent updates about how employees on their teams were spending their time.

The leaders were frustrated with their middle managers.

The leaders were frustrated – that is why a change was made.

But that’s not the problem that they recognized, and it’s not the one they solved for. So when it came time to design a change strategy, the strategy did not match the purpose.

This disconnect between the purpose and the change strategy is what sabotaged the change’s success from the very start.

Why didn’t the senior leaders design a change strategy and create stakeholder communication rooted in the change’s real purpose?

There are three reasons I see most often in the real world:

• a combination of ego and fear
• they simply don’t know how, because the way they have learned to lead change is fundamentally broken
• their organization’s purpose – and therefore the purpose of every change at their organization – is to extract from and exploit employees (and other “resources” along the supply chain) for profit, and so they only make the decisions and attempt to implement what they decide based on what they think will result in the most profit (which doesn’t make for good marketing and PR)

And so – in Commcoterie’s next newsletter, it still won’t be time to to show you how you can use the why to follow a “purpose pathway” to help a change strategy actually design itself.

Before we get there, I’m going to explore the first two bullet points I mentioned above: how fear/ego and ignorance (systemic ignorance rather than individual ignorance) guide leaders’ decision-making when it comes to organizational change – and sabotage their organizations’ success in the process.

As for the third bullet point?

Well, as Kendrick Lamar says, they're "not like us."

I'll leave the full diss track for another day.

Talk soon,

Caitlin Harper
​Founder, Commcoterie

P.S. – Know someone who needs to read this? Forward them this issue or share this page on your socials – there folks can check out past issues and subscribe so that they never miss a new one.

​​