How to Keep Stakeholders Aligned 📣
Let's talk about meetings, tools, and setups
When I have to write a new Refactoring article, I often think at traits that the best teams I know have in common, and try to explain them.
Some of these traits are easy to spot, and we talk about them all the time: ship often, hire well, or talk with customers.
Others though, are sneaky, and less visible from the outside. In this category, one of my favorites is: keeping stakeholders aligned on status.
Stakeholders is kind of corp-speak, so let’s just say that in any project there are people who participate in different ways and capacities, and therefore have different information needs. E.g. a PM needs to know blockers to remove them, customer support needs to know new releases to assist users, an EM may check for technical dependencies between two tasks, and more.
Technically, a project is a singular, shared entity, so this alignment problem doesn’t feel too hard. In reality, it most often is, and engineering leaders (among others) often get caught in convoluted balancing acts to deliver tailored, timely, and correct information to all parties.
The impact of getting this right vs wrong can be immense:
🟢 Good communication — people know where to look for what they need, they trust the data, and take action in a timely manner.
🔴 Bad communication — people don’t trust tools, overly rely on meetings to pass information, and make slow and uninformed calls.
So, over time I stole developed a rich set of strategies for this, with ideas on how to use tools, meetings, and how to serve everyone efficiently.
So here's what we'll cover:
🔀 Understanding stakeholder needs — who you should account for.
🤝 Meetings vs async tools — turning status updates into async workflows.
🛠️ Single tool vs multiple tools — and strategies to make both approaches work.
🎯 How to choose for your team — practical heuristics and steps to make the right call.
Let's dive in!
🔀 Understanding stakeholder needs
Before we can discuss tools and strategies, we need to understand what stakeholders actually need to know. Such requirements vary significantly across roles, and recognizing these differences is the first step towards alignment.
Let’s look at the five most common stakeholders in any software project:
🎨 Product Managers — need a holistic view of the project, including timelines, progress, and any blockers or risks that might cause delays.
🎖️ Engineering Managers — they have many overlapping needs with PMs (depending on their duties) and may look into more detailed information about capacity and technical dependencies.
🔨 Software Engineers — need granular, task-level information. This includes requirements, acceptance criteria, links to repos, PRs, and more.
💬 Customer Support — needs to stay informed about feature releases, known issues, and the product roadmap to set customer expectations.
👑 Executives — need high-level, impact-oriented info. They're typically interested in overall project health, how it aligns with business priorities, upcoming milestones and potential risks.
To serve each of these needs you have two broad strategies: 1) talk with people, e.g. in meetings or chat, or 2) self-serve through tools and docs.
Both options have merits and drawbacks, so let’s explore them 👇
🤝 Meetings
Meetings are the easy default, and have plenty of qualities: they are easy to setup, they are high-bandwidth, and they help relationships among peers.
They also have drawbacks we all know: they are incredibly draining, ephemeral (information may get lost), challenging in distributed teams, and more.
In my experience, meetings are best spent in situations where there is shared creation or action. They shine when there is creative, quick back-and-forth between participants, converging into an outcome that would be cumbersome to obtain async.
Conversely, unidirectional communication, like status updates, is better served by good tooling and docs.
The trick here is that a lot of status updates don’t look like it. They look like complex, involved conversations between multiple parties — but what is actually happening is only a translation act that someone (the source of information) performs in service of other participants.
If you are unsure what your meeting is about, ask yourself: how many times did the meeting lead to an action or an outcome that was different from what would have happened (or you would have decided) without the meeting? If the answer is none or very few, then your meeting is probably a glorified status update.
You can find more ideas about reducing meetings and turning them into async processes in this popular piece 👇
🔨 Tools
For status updates, the #1 alternative to meetings is async exchanges through docs and tools.
Now, in my experience, creating docs and keeping them up to date looks hard, while using tools looks like low-hanging fruit. After all, everything about the project already lives on Linear / Jira / Notion, so why can’t people go straight there to get information? If we all use and access the same source of truth, updates will always be timely, and data will never become stale.
This line of thinking has merits, but is also simplistic.
In fact, most tools are specific: they are thought of for 1) some use cases, and 2) some ideal users. Jira is hard to parse for non-technical users, just like Notion feels cumbersome for tracking coding tasks.
So what do you do? There are two options here, which can work equally well:
Single tool — stick with a single source of truth, prioritizing consistency over UX. E.g. use Notion for everything.
Multiple tools — use specialized solutions for the different use cases, prioritizing UX over consistency. E.g. use Notion for OKRs and Jira for tasks.
I have seen both situations and I don’t think there is a strictly superior one — it depends on many factors, including your team skills, your product, your scale, and more.
So, let’s cover both approaches, together with the best strategies I have seen to make them work.
Let’s start with the single tool approach 👇