A word from this week’s sponsor…

There’s a reason 400,000 professionals read this daily.

Join The AI Report, trusted by 400,000+ professionals at Google, Microsoft, and OpenAI. Get daily insights, tools, and strategies to master practical AI skills that drive results.

Sign up now for free and work smarter, not harder.

Learn

👨‍🏫 Stop Using a Hammer for Every Problem

As a technical program manager, you get a lot of problems thrown at you.

I mean…a lot. And the trickiest thing in my experience is that not all problems are created equal.

About 5 years ago I entered the world of woodworking. I built my first (and only) utility stool. I quickly learned that building even a simple stool requires a variety of tools – a saw for cutting, a drill for holes, sandpaper for finishing. You wouldn't use a hammer for every step, right?

The same principle applies to technical program management.

I know I've definitely tried to force a square peg into a round hole before, and it wasn’t pretty. I remember once trying to rollout an Agile adoption to a handful of teams. It was honestly a disaster, but a massively beneficial career experience for me. Agile practices weren’t going to solve their problems. We pivoted quickly to a different approach and had better success.

It made me realize that just like a woodworker wouldn't use a hammer for every task, we shouldn't use the same project management style for every problem.

Enter the Cynefin Framework

That's where the Cynefin Framework comes in.

It's not some fancy academic theory; it's a practical way to categorize problems so you can choose the right approach. Think of it as a map to navigate the different types of challenges we face. Here’s a visual from HBR’s article “A Leader’s Guide To Making Decisions”:

You see above that there are five domains that fall somewhere on a spectrum of unordered to ordered.

Let’s start in the middle of the visual above, Disorder.

This is when you're just plain confused!

You don't even know which of the other domains you're in. The first step is to break things down and figure out what kind of problem you're actually dealing with. This is it isn’t immediately apparent which domain is most applicable and your first task is to figure that out.

As you move out of disorder, ambiguity begins to retreat and you start to see the problem(s) for what it is in one of the categories below.

Simple (Sense - Categorize - Respond)

These are your bread-and-butter tasks. The cause and effect are obvious. Think bug fixes, routine deployments, or adding a standard feature. You know what needs to be done, and there's usually a best practice to follow. It's like following a recipe.

The go-to moves are “Sense - Categorize - Respond”. You see the problem, you know the solution, you apply it. Boom, done. Example: A routine software patch deployment. While TPMs often deal with more complex issues, elements of 'Simple' problems are frequently embedded within larger programs and require appropriate handling. 

Applying this to our world as Technical Program Managers across 4 example domains of our job:

• Risk Management: Risks are usually well-known and predictable. Focus on prevention through checklists, standardized procedures, and quality control. Contingency plans should be simple and straightforward. Think "if X happens, do Y."

• Stakeholder Management: Communication should be clear, concise, and focused on progress updates. Regular, brief status reports will suffice. Stakeholders are usually interested in knowing that things are on track and within budget.

• Communication Strategy: Simple, direct communication channels are best. Email, short status meetings, and project management software updates are sufficient.

• Team Structure: Hierarchical, with clear roles and responsibilities.

Complicated (Sense - Analyze - Respond)

These are trickier. There are multiple moving parts, and you need some expertise to figure things out. Like integrating two existing systems or building a new feature with detailed specs. You can figure out the cause and effect, but it takes analysis.

Your actions are to “Sense - Analyze - Respond”. You see the problem, you bring in the experts to analyze it, then you respond with a solution. There might be multiple good solutions, but you can find them with enough analysis. Example: Integrating a new payment gateway into an existing e-commerce platform.

Applying this to our world as Technical Program Managers across 4 example domains of our job:

• Risk Management: Risks are more complex and require analysis. Use techniques like risk assessments, SWOT analysis, and fault tree analysis. Contingency plans should be more detailed and consider multiple potential scenarios.

• Stakeholder Management: Engage stakeholders throughout the process, especially during analysis and design phases. They may have valuable expertise to contribute. Regular meetings and more detailed reports are necessary.

• Communication Strategy: More in-depth communication is required, focusing on explaining technical details and trade-offs. Use presentations, white papers, and technical documentation as needed.

• Team Structure: Cross-functional teams with specialized expertise are crucial.

Complex (Probe - Sense - Respond)

Now we're in the weeds. Cause and effect are only clear after the fact. Think developing a brand-new product with an uncertain market or dealing with major organizational change. You can't plan everything upfront; you have to experiment and see what emerges.

"Probe - Sense - Respond" is key. You try something (probe), you see what happens (sense), then you adjust your approach (respond). It's all about learning and adapting. Example: Developing a new AI-powered recommendation engine with uncertain user adoption.

Applying this to our world as Technical Program Managers across 4 example domains of our job:

• Risk Management: Risks are emergent and difficult to predict. Focus on building resilience and adaptability into the project. Use techniques like scenario planning and simulations. Embrace iterative development and frequent feedback loops to identify and mitigate risks early.

• Stakeholder Management: Keep stakeholders informed of the overall direction and progress, but don't try to over-promise specific outcomes. Manage expectations by emphasizing the experimental nature of the project. Frequent communication and transparency are essential.

• Communication Strategy: Open and frequent communication is paramount. Use collaborative tools, workshops, and regular demos to keep stakeholders engaged and informed. Focus on sharing learnings and adapting the approach based on feedback.

• Team Structure: Self-organizing, cross-functional teams with a high degree of autonomy are ideal.

Chaotic (Act - Sense - Respond) 

This is full-on crisis mode. No cause and effect is apparent, and you need to act fast just to regain control. Think major production outages or unexpected security breaches. The priority is to stabilize the situation first and ask questions later.

"Act - Sense - Respond" is the only way to go. You do something to stop the bleeding, then you assess the situation and figure out your next move. Command-and-control style because the stakes are usually very high. Example: Responding to a major data breach.

Applying this to our world as Technical Program Managers across 4 example domains of our job:

• Risk Management: Risk management is about immediate response and damage control. Focus on stabilizing the situation and preventing further escalation. Post-mortem analysis is critical to learn from the experience and prevent future crises.

• Stakeholder Management: Communicate frequently and transparently, even when information is limited. Focus on reassuring stakeholders that the situation is being handled.

• Communication Strategy: Clear, concise, and immediate communication is crucial. Use all available channels to reach stakeholders quickly.

• Team Structure: A command-and-control structure with clear lines of authority is necessary.

Wrapping it up

It’s not about rigidly applying a template, but rather using the framework as a guide to make informed decisions about how to manage your projects effectively.

By understanding where your program (and sub-projects) falls within the Cynefin Framework, you can tailor your approach to maximize your chances of success.

This will help you avoid a lot of the headaches and frustration we've all experienced when trying to force a one-size-fits-all solution onto a complex problem.

Thanks for reading today, happy TPM-ing!

Resources

📚 Technical Program Managmenet: A Practitioner’s Guide

A couple years ago I launched a course on Educative.io, which is a text-based course platform. I can’t believe it has been that long!

It has a heavy emphasis on program lifecycle, with supplemental content on system design, leadership, and career management. And the great thing is that I can give my readers a special end-of-year discount to the platform. Enjoy!