In complex companies, with non-obvious interdependencies and hard schedule constraints, organizing the process is a huge “full-time” job, and can save weeks of delays if done right. It signifies the role of a project manager, despite the teams having a product manager in their fold.
As Ben Kuhn puts it, when done right, it can save weeks of delays and nip problems in their bud even before they materialise in the first place.
I’ll share a few examples from crisis projects, non-profits, startups, and larger organisations I’ve worked with, and some principles that has helped me ‘nip problems in the bud’. This serves as a note to myself, in case I run any future project:
-
Anchoring your project around a canonical document. One living source of truth—owned by you—should define scope, sequencing, owners, and assumptions. It’s the object everyone orients to when reality shifts. (Inspired by Naomi’s conversation on the Lenny’s podcast, refer here for resources)
-
Using weekly planning sessions to align on priorities and tradeoffs. Keep it tight, focused, and driven by real constraints—not status theater. Use this as a platform to facilitate cross-functional friction, and from the project management persp. ease the gaps as much as possible. Best to do on early Mondays, right at the start of the working week.
-
Holding bi-weekly retrospectives that go beyond the exact mechanics of the sprint. Use a simple “start, stop, improve” format to interrogate how your team works, not just what it ships. For more ideas on how to better run retros, refer to this. “Reflection on action” should happen more spaced-out, as it becomes quite draining otherwise. If you think there is no justification for conducting a retrospective, just cancel it. There is no need for unnecessary pontification.
-
If your team doesn’t have uninterrupted blocks, your throughput is going to be cosmetic. If you have to schedule a block with the team anyways, schedule it close to the meetings they already have planned, instead of this one-off meeting scheduled in between a long gap of deep work hours. A 15-min “quick catchup” in between a four hour window might just stick out like a sore thumb. Speaking about quick catchups, never ping anyone on Slack with a ‘quick catchup’, that’s another cardinal sin when it comes to coordinating with people.
-
Running short, daily standups—strict 15 minutes max. They’re not for updates; they’re for aligning intent and unblocking execution. If updates dominate, fix your async channels to ensure updates flow through the stream as much as possible. In case it’s justified, do schedule a longer one, but it’s important to ensure that the default meeting slot is 15-minutes, unless it warrants a longer one.
-
Project managers within the team should maintain a visible RAID (Risks, Assumptions, Issues, Dependencies) tracker. This needs to be reviewed regularly between project <> product catchups. Dependencies should not be discovered during escalation—they should be managed in plain sight (should be made visible as soon as possible)
-
Track inter-team work in a shared Jira/Linear board or equivalent. Don’t rely on memory or goodwill.
-
Visually demarcate meetings into high, neutral and low leverage with colors such as green, amber and red.
-
Conduct quarterly strategy syncs with senior stakeholders. These aren’t status updates—they’re about resetting shared context, confirming priorities, and preempting surprises.
-
By default, I tend to reach out to folks on private slack DMs, and then realise the mistake here as it’s not even about secret information being shared in private circles, it’s about vulnerability ultimately. Make Slack work for you by keeping hard questions and key conversations in public channels. Transparency shouldn’t just be a cultural nicety.
-
Cultivate a “disagree and commit” culture explicitly. Set expectations upfront: we surface dissent early, resolve quickly, and then go all-in. No passive resistance allowed.
-
Celebrate wins, even partial ones, in visible ways. Build morale through momentum. Momentum is the emotional fuel for complexity. Praise in public, feedback in private.
-
Foster psychological safety by modeling vulnerability and naming uncertainty. If people can’t say “I don’t know” or “this might be wrong,” you’ll never find issues early. These are all good signs.
-
When something breaks, doing a public postmortem—not to assign blame but to improve the system. Mechanics are similar to a retro, but more launch-specific.
-
Assume misalignment unless proven otherwise. The burden of proof is not that someone disagrees—it’s that everyone is solving for the same version of success.
