Speed for PMs (2)— The fog of war

Fog of war in RTS games (AOEO Wiki)Fog of war in RTS games (AOEO Wiki)

This is my second write up in the Series on speed (link). I am using this series to simply highlight tactics and techniques how PMs can improve their pace to ship faster. Disclaimer: I am not talking about validation of assumptions, building for the right outcomes etc.

In this post I write about “Fog of war”. In my opinion, this is one of the biggest obstacles PMs face to help their teams ship consistently and predictably.

The fog of war has its origins in military history. Imagine going into a war without a map of your battlefield, and without knowing who your enemies are. Without this map, your troops are blind, not knowing what comes next and thus left at the mercy of chance.

Fog of war has been written about in military and corporate strategy as well as in the gaming world.

the state of ignorance in which commanders frequently find themselves as regards the real strength and position, not only of their foes, but also of their friends. (link)

Each commander is forced to rely on imperfect and incomplete information on the battlefield, and often must improvise based on intuition and common sense . (link)

PMs, are battling the fog of war every day. Your assumptions create fogs, the market creates a fog but for the sake of this article, consider the fog of war as the lack of visibility around where your biggest challenges for executing a new launch lie.

The fog of war prevents your teams from seeing the complete “map” when they start working on a new big feature or a new product altogether. High density of fog of war, gives you more uncertainty → more potential of uncovering landmines, and higher chances of slowing , delaying or stopping your launch down the line.

Landmines slow execution down

Execution landmines can slow your teams down, can set back shipping over and over again, can delay launches and at worst can even bring your (or someones else’s) release to a grinding halt.

Here are a few landmines for reference:

1. External team dependencies — if your launch relies on other teams doing a piece of work for you. You realize later on that they were not ready, they never knew, they got delayed by external factors etc etc. And now you’re stuck with a delayed launch.
2. Unclear engineering challenges — when your team encounters unexpected technical barriers that set them back a few days or leads them to rethink their approach. Worst case, you are left with tons of scrap work and dev effort waste.
3. Maintenance spikes — when the team working on a new feature is also responsible for supporting your current product and encounters an unexpected issue that takes them away from new work
4. Downtimes and interruptions — includes for example, unplanned vacations, outages, company events etc.

PMs can support teams around them by helping them determine the topology for each launch. Very often, teams jump into execution mode without understanding this topology.

This means the team has to spend some time nad figure out which landmines exist for each release plus how best to plan mitigation/avoidance for them

How does it impact speed?

Without a basic understanding of the complete terrain and a general understanding of your landmines / routes ,

1. Teams underestimate the release complexity — we don’t know what / where these landmines lie, and we discount their impact to our timelines. We keep hitting them though, leading to delays
2. Teams are unaware of shortcuts — we can’t create alternate plans, identify potential alternatives that can help us navigate these landmines.
3. Teams discover dependencies and setbacks later in the launch cycle : and they end up delaying our work, or someone else’s.
4. Teams cannot identify cross-impact early on: and fail to see how our work impacts external teams.
5. Teams navigate without focus — without a laser focussed set of priorities by PMs, and a set of markers to guide them, progress is often hampered.

Why does this happen ?

System 1 vs System 2 thinking

• Our brains are programmed to operate in System 1 — our default and unconscious thinking mode. We are on autopilot mode, making quick decisions that keep our daily activities running smoothly.
• System 1 is heavily informed by our biases and past pattern matching. We jump into building, just because its easier to do.
• System 2 thinking lets you plan, step back and analyze. Often times helping you inform and guide the right decisions. Harder to do, but needed before every major project.

Source — UX design collective

Dunning Kruger effect

• Perhaps my most favorite bias of all time, Dunning Kruger effect kicks in when teams are overconfident about their abilities when tackling new work.
• Past successes and biases play a big role.
• If you’re overconfident about achieving something, high odds are you wont do the right diligence needed for it.

Misaligned Dependencies

• It’s often easier to go solo at things. It’s harder to work with other teams in coalition.
• PMs might often skip spending time with other teams in order to avoid “slowing down” thus tiptoe around gathering dependencies, getting alignment, identifying key blockers etc.
• Not doing these activities gives temporary speed boosts but odds are they will show up at some point as obstacles.
• Wrong priorities, different expectations, resource bottlenecks etc are traps and can be avoided by the right conversations early on.

Some techniques to help build your topology of execution

Identify your execution constraints

• Identify the biggest constraints in your execution path early on. Spend time working solo on getting an idea about the biggest pitfalls are. Then loop the rest of the team in to discover more and add fidelity around them.
• You might need to work with a few other folks early on. Specially folks that complement your skill / expertise gaps.
• This builds a high level map, that goes a long way in clearing things up for your next steps

Use Spike Stories intelligently

• Early Spikes pre-development — are helpful in de-risking your release by identifying unseen challenges, determining complexity, even breaking work down. These are powerful longer term levers that if played smartly, help streamline the rest of your efforts.
• Ongoing development Spikes are helpful in determining technical implementation, size and tradeoffs for bigger tasks, small but easy levers to avoid traps when you are in sprint mode.
• I also use them for targeted design research, user validation which I’ll write about at one point.

Loop in devs early

• Make sure your engineering team gets in front of your customer and can read their challenges. Give them time to soak problems in.
• Enable them with the freedom to explore approaches and alternatives, but acting in constraints. Let them have a big say in the how, and give them the space and confidence to negotiate different pathways.

Manage external dependencies

• Communicate with other teams you depend upon early on. Get alignment on what they need. What could block you later on?
• Similarly, What do you need from them that could be hard to get? That’s another pitfall. Get ahead of this question in advance.
• Plan Workshops with other stakeholders
• Invite Customer support for feature training needs / support docs / customer macros.
• Run Risk/Legal through your designs. Is there a compliance speed-bump or a legal hurdle that’s lurking in the release? Identify that before you give marching orders.
• Loop in Security / Devops early. They are super important partners in your build lifecycle. Having them aware of what’s coming early on will save big setbacks down the lifecycle.

Final Notes

The Topology of execution is the map that will tell you what your biggest landmines are and where they lie.

Take some time to identify and communicate this topology before launching your team through the door.

How much time you spend on building this map is dependent on multiple factors including customer impact (upside, downside) , the size and complexity of the release, the investment, the criticality etc. Sometimes , spending an hour with your team is good enough. Other times this could run into a week long sprint.

There will always be a fog (the map is not the terrain). You need to decide the “good enough zone” which is thus, subjective. You’ll have to rely on your product specific parameters to know whats that zone for you.

Once you have started working no the TOE, watch out for the most common landmines, and identify which ones are applicable to your release. Know and communicate them upfront so that you and your team can navigate through. Control them when possible, avoid them the others.

Hope this was helpful. More to come in this series.