As a kid, I was great at taking things apart, and not so great at putting them back together. This taught me about cascade failures. No one tells you, as a child, that you can have a career that involves breaking things, and a lot of career professionals wouldn’t describe their jobs that way. However, most things can be broken, and problems are especially vulnerable to breakage. Thus, I describe part of my job as breaking problems.

My take: Don’t fix problems; hack into them instead. Be a system breaker. Then, create a functional system; your desired end state. Here’s a handy interactive decision tree built with Mermaid JS to guide you through how I do things.

Build or break?

Click any box for explanatory deets in the context box.

flowchart TD
    A["New thing or old thing?"]
    B["New"]
    C["New strategy"]
    D["Old"]
    E["Is there a problem?"]
    F["Yes"]
    G["Reverse engineer
 the problem"]
    I["No"]
    J["Revise
 strategy"]
    K["Not yet"]
    L["Target the
 weakest link"]
    M["Deploy"]

    A --> B
    A --> D
    B -----> C
    D --> E
    E --> I
    E --> F
    E --> K
    K --> G
    F --> G
    G --> L
    I ---> J
    L --> M
    C --> M
    J --> M

    classDef decision fill:#ede9fe,stroke:#7c3aed,color:#4c1d95,stroke-width:2px;
    classDef branch fill:#fef9c3,stroke:#ca8a04,color:#713f12,stroke-width:1.5px;
    classDef method fill:#ffedd5,stroke:#ea580c,color:#7c2d12,stroke-width:2px;
    classDef newOutcome fill:#dbeafe,stroke:#2563eb,color:#1e3a8a,stroke-width:2px;
    classDef deconstructOutcome fill:#fee2e2,stroke:#dc2626,color:#7f1d1d,stroke-width:2px;
    classDef reviseOutcome fill:#dcfce7,stroke:#16a34a,color:#14532d,stroke-width:2px;

    class A,E decision;
    class B,D,F,I,K branch;
    class L method;
    class C,J,G newOutcome;
    class H deconstructOutcome;
    class M reviseOutcome;

New thing or old thing?

New things - product launches, brand new campaigns, or anything that hasn't been done before.
Old things - something that has been done before, whether it works or doesn't work. This includes projects that didn't get off the ground and implementations that ran into issues.

Break the problem, then replace

The key behind this whole idea is that finding a way to destabilize a problem system, and then implementing your ideal state, is simpler and more stable than attempting to find a way to solve an entire problem at once.

Example: no bike in the gym

For a mental experiment; we work at an office which has a gym. There's no bike in the employee gym because the gym manager ran out of budget while purchasing equipment, probably due to the volatility of the cost of steel (the pandemic, high oil cost, tarriffs, etc; many factors, but the end result is that weights are expensive, so less budget for cardio). We, the employees, want an exercise bike.

Is this a communications problem? Nope. It's an ordinary, everyday office problem. Hacking problems is a pretty versatile method. But you can apply some comms methodologies to it.

You can make a problem statement, and reverse engineer the problem, in simple cases like this, by just looking at the statement and picking out the bits that stick up. Follow those along to find the causative factors, and you've got a simple system, defined in components.

Problem statement: There's no bike in the employee gym because the gym manager ran out of budget while purchasing equipment.

The components of this are;
  • No bike
  • Gym
  • Gym manager
  • Budget
  • Purchasing
  • Employees
  • Negative satisfaction
  • Budget manager
The problem of the missing bicycle as a system

Illustration

A way to envision the no-bike problem. Layers that support other layers are lower in the tower. More accurately, each of these exerts dynamic force on the others, so simulating these as interconnected forces would be more accurate, but this is just an example.

Benjamin Wilson via figjam

There are several parts of this system that would cause a cascade failure of the problem state. This is an important time to mention something;

Some solutions are worse than the problem.

What does this mean? Looking at the problem system, there are some ways that you could 'fix' the entire system that would ruin everything for everyone involved;

  • Remove the employees
  • Remove the gym
  • Remove the budget
  • Remove the gym manager

In each case, those solutions, while interconnected and reinforcing feedback loops, would cause a worse problem, and wouldn't let you install a functional system, which is your desired end state; a gym with an exercise bike.

That leaves;

  • Negative satisfaction
  • No bike
  • Budget manager
  • Budget
  • Purchasing

If we could remove the negative satisfacion directly, we would have done that, but that's controlling people's thoughts. I'm going to go out on a limb and say that one's a no-go. Similarly, if we could just magically provide a bike, we would have done so. That leaves budget and purchasing, which are closely related enough that I think we can treat them as one problem. If I'd rendered this as a series of gears, a lot of it would revolve around (or near) the budget manager.

My money's on just making a case to the budget manager as a quick way to get an exercise bike; if there's no budget, there's no budget, but it's the most logically complete answer available to us.

In this case, formulating a strategy - a business case, probably - targeted at the budget manager, asking them to authorize an additional purchase or to find room in another discretionary pot of money is the most likely solution; target the weakest link, formulate a strategic way to affect it, break the old system, and then replace it with a new, functioning system using most of the same parts, because we need a lot of things that were in the problem system, like budget, and employees. Install the new system, which is a gym with a functioning bike. This fixes the negative sentiment - at least the negative sentiment about the gym. You can't fix everything with an exercise bike.

Build a new strategy

Maybe you don't need to break a problem state.

If you need to build - or overhaul - a communications strategy, it’s a good idea to follow a set formula, and deviate if needed. When writing things, I’m a fan of the outline approach, because it breaks the tabula rasa problem (where the page is blank and you can’t think of anything to write and then the existential dread sets in).

I make an outline with these sections:

  • Summary
  • Situation or problem statement
  • Objectives
  • Audience
  • Core messages
  • Channel map
  • Tactics / plan of action, and timeline
  • Feedback mechanism and analytics
  • Risks and contingency planning

Generally, I fill them out in a non-linear fashion. First, problem, then people, then objectives, then messages, then channel map, and so on. Start with what you know; research the rest. If you don’t know, ask.

This is a very broad overview; I’ll write a future post on how to build a comms strategy in detail.

Overhaul an existing strategy

When overhauling a strategy, I find that the easiest way to go is to take a three-fold approach;

  1. Why isn’t it perfect as-is?
  2. What else needs to be updated, overhauled, or replaced?
  3. Have your analytics changed? If so, wrap this campaign into your new analytics methodology.

Fix the big things that are making it underperform (or whatever it was that required an overhaul), then do a minor facelift on the rest of the strategy, then make sure your analytics, KPIs, and whatever else align with your current priorities and how you’re collecting and reporting data. Then ship. This is probably the easiest out of the three (fixing problems, making entirely new strats, or just minor tune-ups) options.

Always measure and iterate

Last - measure everything. Listen to what your users say. And iterate; take that feedback, make changes, redeploy. Refine over time, and take notes. That gets you to the optimum solution; ideally one that works for you and your users.