When I was in consulting, I was occasionally called into a "project rescue." It’s a euphemism, of course. It meant a project was struggling, and my job was to figure out why.
In one instance, finding the root issues took just a few days. I interviewed every contributor—the engineers, the designer, the PM, the client stakeholders. On the surface, things looked fine. They had a perfectly groomed backlog and believed their work aligned with the Statement of Work. In reality, they hadn't broken the work down properly and had no real idea when it would be completed.
They were shipping features, but nobody could connect them to the client’s problem. There were other issues, too—a senior engineer whose toxic behavior was shutting down important conversations.1 But the core problem was systemic: the team lacked the shared understanding and trust to notice they were drifting off course. They were executing someone else’s plan, not solving a problem together.
Comparing projects that felt like a slog to those that were a joy, I saw a pattern. The healthiest teams were instinctively asking a handful of fundamental questions.
These questions aren’t a checklist. They're a byproduct of a culture built on transparency and trust. They reveal whether the relationships are strong enough to sustain the messy, unpredictable work of building great products. This framework, created from those observations, has been a helpful mental model for me.
What I Mean When I Say "Project Health"
Project health isn’t a set of KPIs or ambiguous RAG (Red-Amber-Green) reports. For me, it boils down to one question I try to answer with every interaction: do the people building this thing understand the “why” and trust each other enough to solve hard problems together?
On the best teams, everyone from the newest engineer to the lead stakeholder has enough context to see when things are going sideways. Concerns are raised and addressed not because a process dictates it, but because the underlying relationships and information flows encourage it.
Conversely, the most spectacular failures I’ve been a part of shared a common root cause: information was siloed and feedback loops were broken. People were flying blind, unable to see they were off course because they were trusting someone else—often a nameless 'they'—to ensure the work was correct.
These five questions codify what healthy teams do naturally. They're not a magic formula, but they are effective at prompting the conversations that build shared context and conviction.
A Framework for Asking Better Questions
Question 1: How is the team able to use their time?
Why it matters to me: I once managed a team where I thought we were focused, only to discover—by looking at the data—that engineers were losing nearly 40% of their week to meetings they didn't find valuable. I was asking them to deliver, but the system I was responsible for was preventing them from doing so.
The wording here is intentional: not "how should the team use their time," but "how are they able to?" It presumes good intent and examines the system around them.
What I’m trying to understand:
- How much time do we get for focused work versus meetings and interruptions?
- Are we spending our energy on the work we agreed was most important?
- Where is work getting blocked or slowed down?
- Do people feel their skills are being put to good use?
A team that can answer "How is the team able to use their time?" with positive, data-backed evidence has the agency to do meaningful work.
Question 2: How well does the team understand what success looks like and why it matters?
Why it matters to me: I've seen too many projects where the "why" was held by one or two people. When requirements inevitably changed, the broader team couldn't contribute to the conversation about tradeoffs because they lacked business context. They could only execute well-written tickets.
Healthy teams don't just know what they're building; they understand why it matters to a user. This shared context allows a team to make good decisions when a leader isn't in the room.
What I’m trying to understand:
- Can everyone on the team explain how their current task connects to a larger user or business goal?
- Do our definitions of "done" include the outcome we expect, not just the output we're creating?
- When we estimate work, are we including our confidence level and assumptions?
A team that understands what success looks like can move from implementing features to actively steering toward the right outcome.
Question 3: Do stakeholders understand what they're actually getting and when?
Why it matters to me: Stakeholders should rarely be surprised. Sending frequent updates—status reports, sprint summaries, burn-down charts—isn't enough. Talking at stakeholders doesn't build a shared understanding with them. This gap is where trust erodes and expensive rework begins.
Effective stakeholder relationships require deep alignment. They need enough context to give meaningful feedback and make informed decisions about tradeoffs.
What I’m trying to understand:
- Are stakeholders reviewing working software regularly, not just slide decks?
- Do we communicate estimates with ranges and assumptions, so they understand the uncertainty?
- When stakeholders give feedback, do they see it reflected in our plan?
- Are we all telling the same story about what we're building and why?
Ensuring stakeholders understand what they're getting—backed by evidence like shared demos and documented decisions—builds the trust required to navigate inevitable scope changes together.
Question 4: Does the client regularly review and accept work that is being completed?
Why it matters to me: I learned this lesson the hard way on a project where we saved all user feedback for a big "UAT phase" at the end. We had built what was defined through user interviews, but it still wasn't what users needed. The three months of rework that followed taught me: feedback loops during development aren't optional.
Feedback loops with users and stakeholders are our primary method of risk management.
These loops are our primary form of risk management. The goal isn't just to get approval; it's to validate that our solution is solving the problem. This requires creating opportunities for real people to interact with what we're building long before it's considered "finished."
What I’m trying to understand:
- How quickly can we get a new idea in front of a real user?
- Is feedback specific enough to be actionable?
- Are we learning things that challenge our initial assumptions? (If not, I get worried.)
A project where the client regularly reviews and accepts work stays on the path to building something people want.
Question 5: Is the project adequately staffed and on track to deliver?
Why it matters to me: I’ve been on projects that were doomed from the start—unrealistic timelines, under-skilled teams, unclear goals—but nobody felt safe enough to say it out loud. An environment where people can't talk about risk is the biggest risk of all. This final question is about whether the team has conviction in the plan. That conviction enables execution; without it, they're just hoping.
Honest conversations about constraints—time, budget, people, technology—aren't negative. They are the foundation of a realistic plan.
What I’m trying to understand:
- Does our timeline feel challenging but achievable, or does it feel like a fantasy? When it’s a fantasy, teams expect to fail.
- Are there gaps between the work we need to do and the skills on the team?
- Do people feel comfortable raising concerns before they become crises?
A team with the safety to answer these questions honestly can address foundational issues like staffing and timelines, building a conviction based on shared reality, not hope.
This Isn't a Checklist, It’s a Compass
These five questions aren't about a perfect score or new KPIs. They're a compass—a way to take a bearing and see which way you're pointing.
The hardest part is getting real data. It's easier to work from intuition, and many people groan at the suggestion. But the teams that thrive are the ones who push through that discomfort. They're the ones who spend 15 minutes in a retro asking, "How confident are we that our stakeholders understand what we're actually building? What could we do this week to get a clearer signal?"
This isn’t about more process. It’s about building the transparency, trust, and shared understanding that allow a group of talented people to solve hard problems together, especially when things don’t go according to plan.
I'm still figuring out how to do this well, and my thinking evolves. But this framework has been my most reliable compass.
What do you use to take your bearings? I'm curious how other teams build and maintain alignment. I'm interested in how you measure something like "trust" without asking someone to fall backwards into their coworker’s arms.
If you have thoughts, stories of your own failures, or frameworks you've found useful, reach out. You can find me on LinkedIn or email me directly at hello@joel.software.
Footnotes
-
We removed the individual from the team almost immediately. The choice instantly improved morale; the team had been struggling and didn't think anyone would act. It sent a clear message that people's well-being was a priority. That engineer was put on a performance improvement plan and, last I heard, had improved their conduct. It was a powerful lesson that no process can substitute for addressing interpersonal issues head-on. ↩