What happens when everyone agrees something needs to change, but the software you rolled out to fix it isn't actually fixing anything?

In Part 2, Emma Marks and Audrey Damman get real about what happened after they got consensus to roll out Asana to their team at WRI. Spoiler: getting everyone to agree was just the beginning. This is where they learned that culture eats software for breakfast—and that the real work of internal change happens after the design phase is "done."

This continues our conversation from Part 1, where we explored how Emma and Audrey designed their Asana rollout. They had consensus. They had a vision. They had a plan. But implementation is where internal change projects get tested, and where Emma and Audrey discovered their biggest blind spot: they'd invested heavily in designing the system, but hadn't invested enough in the culture needed to make that system work.

The big twist? Getting consensus was actually the easy part. Emma and Audrey thought they had it figured out after the design phase, but implementation revealed some hard truths about what it actually takes to change how a team works—and what role software actually plays in that equation (hint: it's smaller than you think).

They also discovered some surprising things about what you actually need to make internal change happen. Spoiler: it's not what most people think, and it might make your job a lot easier.

My Favorite Quotes of the Episode:

"Software is not a proxy or replacement for good habits around project design and project management... If you don't have a project kickoff for every internal project where everyone is co-designing a timeline and roles, then the thing that you're putting into the software system is ultimately kind of meaningless." - Emma Marks

"Don't wait until it's perfect because you can spend forever trying to design the perfect process... Give it the appropriate amount of thought and then just roll it out and start testing it." - Emma Marks

"If you believe in your vision... you need one person, or maybe two... and you can make a change." - Audrey Damman

Episode Breakdown

00:00 - 01:48 - Introduction and recap: consensus achieved, now what?

01:49 - 05:32 - From office hours to micro trainings: what worked and what didn't

05:33 - 07:57 - The after-action review and addressing uneven adoption

07:57 - 09:23 - Why vision matters for iterative design and onboarding new team members

09:24 - 13:53 - How their M&E framework evolved (and why flexibility matters)

13:53 - 17:14 - The big realization: culture eats software for breakfast

17:15 - 20:55 - Internal projects vs external: unique challenges and timelines

21:02 - 26:50 - Don't wait for perfect; you don't need leadership buy-in to start

26:50 - End - Final reflections and the importance of working with people who inspire you

What is happening when your whole team agrees on what's broken, but at the end of the day, nothing changes?

In this episode I sit down with Emma Marks and Audrey Damman to talk about what they learned rolling out a new work management system to their team. We get into some of their findings about how just because everyone agrees that something is a problem, it doesn't mean that solving that problem is a priority for everyone. Agreement is definitely not commitment!

This is part one of a two part conversation about designing internal change projects- the kind where you're trying to shift how your team works, not just deliver a product to external stakeholders. Emma and Audrey walk us through their design process, what they wish they'd done differently, and why leading with vision matters more than listing pain points.

If you've ever wondered why your well-designed project lost momentum, or why stakeholder buy-in seemed solid until it wasn't, you might find some tid bits in this conversation.

My Favorite Quotes of the Episode:

"...you don't want to over-index for your point of view because your pain point isn't necessarily everyone's pain point." - Emma Marks

"We might reach consensus and be all on the same page about what the problem is, but how meaningful that problem is to people varied. People didn't see it as needing the same level of intervention or the same level of time investment." - Audrey Damman

Episode Breakdown

00:00 - 07:00 - Introductions and setting up the project

07:00 - 14:00 - What project design means for internal change projects

14:00 - 20:00 - The theory of change rollout that inspired this work 20:00 - 29:00 - How they facilitated problem definition without over-indexing

29:00 - 34:00 - The gap between consensus and commitment

34:00 - End - Why vision matters and preview of Part 2

In this final part of the conversation with Sebastian Varela, we get into something that might be the most important piece of the puzzle: how do you build organizational structures that create coherence without crushing the diversity of perspectives that actually makes your work valuable?

Sebastian is the Director of Strategy and Institutional Alignment for the Cities Program at the World Resources Institute (WRI), a global think-do tank focused on environmental work. Over the course of this three-part series, he's walked us through the tensions of alignment, how organizational vision creates space for flexibility, and now—the organizational foundations that make any of this possible.

Part 3 digs into what Danielle calls "designing for the design." Sebastian shares how WRI spent years building frameworks and vision—the guardrails that let you actually prioritize instead of trying to do everything at once. Without them, you can't commit to metrics, you can't attract larger grants, and decisions get made by whoever's loudest rather than what's most evidence-based. It's painful work that involves real organizational transformation, redistribution of power, and discomfort.

But here's the tension: those guardrails aren't meant to shut people down. Sebastian's closing message is about embracing diversity—of intentions, values, ways of doing things. "Every person is a universe," as one of his bosses used to say. The goal isn't to constrain those galaxies of perspective, but to create enough structure that you can actually harness them. Use facilitation to make space for the people who aren't naturally vocal, because they often have the most transformative insights.

If you've ever struggled with balancing the need for organizational clarity with the messiness of multiple voices, or wondered how to build structure without stifling creativity, this episode is for you.

Welcome back to Part 2 of my conversation with Sebastian Varela! If you haven't listened to Part 1, I recommend starting there — we set up the core tension between clear, top-down alignment and the flexibility that local teams need to actually get things done.

In Part 2, we dig into the "how." If too much rigidity backfires, how do you know how much flexibility to give? Sebastian's thinking on this has evolved over the years. He used to be more lax about whether teams even needed a shared framework. Now he sees it differently — having that collective vision isn't what restricts flexibility, it's what makes flexibility possible. When everyone understands the "why," you don't have to micromanage the "how."

But here's the thing that really stuck with me: without a shared vision, anything can be a priority. And when anything can be a priority, the loudest voices in the room end up driving decisions. That's not alignment — that's just politics. A clear vision gives you something to point to when you're making hard calls, so decisions are grounded in shared understanding rather than whoever talks the most or pushes the hardest.

Key Takeaways from Part 2:

• Without a shared vision, anything can be a priority — and the loudest voices end up winning
• Frameworks don't have to be restrictive; when everyone understands the vision, teams have the freedom to adapt the "how"
• A clear vision gives you something to anchor decisions to, so you're not just navigating internal politics
• The donor dimension is real — building shared understanding with local teams about constraints is essential, but that understanding has to go both ways

Want to hear how organizations can set themselves up for this kind of clarity? Subscribe to Project Design: The Good, The Bad, and The Wild so you don't miss Part 3, where we get into "designing for the design" — the organizational foundations that need to be in place before any of this works.

In this episode, I sit down with Sebastian Varela to dig into one of the trickiest parts of project design: alignment. Not the "check the box and move on" kind. The kind where you're trying to balance clear communication across stakeholders with the flexibility teams need to actually get things done on the ground.

Sebastian is the Director of Strategy and Institutional Alignment for the Cities Program at the World Resources Institute (WRI), a global think-do-tank focused on environmental work. His team tackles big issues affecting urban centers around the world — public transportation, climate resilience, public spaces, etc., which means a lot of different stakeholders with a lot of different ideas on how to get things done. The best way I can describe what Sebastian does? We once gave him a poster of himself herding cats up a mountain. He is a master at helping people with different viewpoints come together around an idea.

Key Takeaways from Part 1:

• Alignment isn't a one-time exercise. It takes time, is highly subjective and requires repeats depending on the different people that are in the room at different times.
• Top-down alignment can be "very clear, very specific, simple to understand, easy to communicate" — but that clarity often comes from having fewer voices involved
• When alignment is too tightly held, people on the ground will work around it rather than follow it
• The tension between "easy to share" and "works in context" is one of the core challenges of project design

Want to hear how Sebastian navigates this tension in practice? Subscribe to Project Design: The Good, The Bad, and The Wild so you don't miss Part 2, where we get into how organizational vision can help you find the right balance between clarity and flexibility.

In most organizations, you plan first, then build, but what if we plan to build first and design later?

Welcome back to Part 2 of the conversation with Ken Wilkins. In Part 1, we heard how Ken's software team navigated FDA regulations and the tension of needing approval without getting timely feedback. But Part 2 digs into something even more fundamental: what makes a design process actually work?

Ken explains how software's quick prototyping cycles create a unique advantage: you can build something, see how it works, and then loop that learning back to improve your original design. His team transformed a narrow fix-this-one-thing directive into a sustainable framework that would make future work easier. Instead of creating one-off patches, they built a general solution the FDA could approve once and apply to similar problems going forward. But this only worked because they had a project manager who listened when they said "we need to change the scope."

Here's the catch: this kind of bidirectional design process—where what you learn during implementation can actually reshape the design—isn't the norm. In many organizations, whether you're dealing with FDA regulations, donor requirements, or just organizational bureaucracy, the design gets locked in early and you're stuck with it. Ken talks about what he sees as the gold standard: processes that people actually want to follow because they make work easier, not harder.

If you've ever felt like your team is doing good work and then awkwardly jamming it into a process after the fact, or wondered why it's so hard to shift direction even when everyone can see a better path forward, this episode is for you.

What happens when the people closest to the technical work can't make the final design decisions- but also can't get the feedback they need to make good recommendations?

In this episode Ken Wilkins takes us inside the world of FDA-regulated medical device development, where design decisions involve life-or-death stakes, regulatory gatekeepers, and technical constraints most of us never think about. Working on a wearable defibrillator, Ken's team faced the challenge of designing for not just their users- but also a faceless regulatory agency that is not exactly speedy in providing feedback.

Part 1 explores how design actually happens when you're operating in a highly regulated space: the tension of needing to make decisions without timely feedback, the complexity of coordinating teams on completely different development cycles, and what it takes to think strategically about trade-offs when you can't build everything.

If you've ever felt stuck waiting for stakeholder input while somehow being expected to deliver the 'right' solution, this episode is for you! The constraints might differ across sectors, but the tension between authority, information, and decision-making is universal.

Almost every guide or resource on Project Design I've ever read tells you to 'consult your stakeholders', almost none of them tell you how to actually do that -- how to functionally engage people when not everyone can be a decision-maker, and how to keep people engaged when realistically you can't do what they want.

In Part 2 Matt and I get into how to navigate these real-world situations. He shares:

• How he 'closes the loop': His approach to maintaining stakeholder engagement even when you can't incorporate their input.
• Why you should cook your projects, not bake them: How rigid, detailed plans often become straitjackets that hurt implementation (and what to do instead).
• The people principle: Why human dynamics - not templates or PowerPoints - determine whether your project succeeds or fails.

If you're tired of project design feeling like some abstract theory or a bunch of buzzwords, well I can't promise that this will solve all your problems. But I can say that Matt gives his honest take on what has worked and not worked for him IRL, and I really think you will walk away with some useful insights.

The bottom line of all this: Projects are implemented by people, not plans. Design accordingly!