Leadership Academy — Session 3: Psychological Safety, Stakeholders, and Managing Expectations
What Google's Project Aristotle found makes teams work, how to map stakeholders properly, and why expectation management only counts before the gap opens.
Part of the Leadership Academy series — notes from Exaze’s Leadership Academy, Batch 1.
Popularity is not the job
The session opened with an uncomfortable observation: people tend to like a leader only for as long as that leader’s decisions serve their interest. The moment the right decision costs them something, the same people turn. Leadership means being willing to make the unpopular-but-correct call and living with what follows.
“When in doubt, take the decision. Do not delay. You need the spine to stand by it.”
What actually makes teams work: Google’s Project Aristotle
Google spent two years studying around 180 of its own teams to find out what separates the effective ones from the rest. Individual talent and team composition weren’t the answer. Five factors were, in order of importance.
| Factor | What it means |
|---|---|
| 1. Psychological Safety | Team members can take risks, disagree, admit mistakes, and ask questions without fear of punishment or humiliation. Worth holding two nuances here: safety is arguably a property between two people, not automatically a whole-team property — you may feel safe one-on-one with someone but not in a room of twenty. And safety has a hard boundary — it doesn’t extend to covering for bad intent or a genuine lack of skill. |
| 2. Dependability | Can teammates count on each other to deliver, on time and to quality. This is peer-to-peer trust — a leader can’t force it, only cultivate the conditions for it. |
| 3. Structure and Clarity | Do people know what’s expected of them, why, and what happens if they don’t deliver. “Ambiguity is a silent killer” — and vague instructions (“handle the delivery”) without real clarification are the most common failure pattern. |
| 4. Meaning | Is the work personally meaningful. This naturally fades with career age — early on, people are often excited by default; sustaining that later takes real, individual attention. |
| 5. Impact | Does the work matter to the larger outcome. No single part of a car moves it alone — not the tire, the engine, or the gears — but understanding your contribution to the whole matters, without anyone believing only they matter. |
A separate point on accountability for team composition: if you chose who joined your team and they’re underperforming, that’s your failure of selection — your job is to make it work or make the call. If you inherited a team you didn’t choose, your job is to know their strengths and weaknesses and support them accordingly — but the responsibility for the outcome still sits with you either way, not with assigning blame downward.
Example (from the session): For Psychological Safety, feeling unsafe was compared to waking up in unfamiliar territory, or a car’s brakes failing — you feel unsafe in unfamiliar or uncontrolled situations regardless of any wrongdoing; confidence and competence (an F1 driver who knows exactly where the emergency brake is) is what reduces that fear. For Impact, the tire-maker, the engine-maker, and the gear-maker are all correct that their part is essential — but none of them alone moves the car.
In the real world: Pixar’s “Braintrust,” created by Ed Catmull during the troubled production of Toy Story 2, is one of the best-documented psychological-safety mechanisms outside Google’s own research. A small group of directors watches unfinished cuts and gives unfiltered, candid feedback — but critically, the Braintrust has no authority. The director is never obliged to act on any note. Catmull argues that separating candor from control is exactly what lets people say “this isn’t working” without political risk, and he credits it as central to Pixar’s creative track record. (Fast Company)
The framework: the Stakeholder Power/Interest Grid
Two axes — how much power someone has to affect the outcome, and how much they actually care — sort every stakeholder into one of four quadrants, each with a different engagement style.
| Quadrant | How to engage |
|---|---|
| High Power / High Interest — MANAGE CLOSELY | Your most important stakeholders — they can block your work and they care. Engage frequently, tailor the message, make it two-way. Example: your manager, a senior sponsor, a client with budget authority. |
| High Power / Low Interest — KEEP SATISFIED | Can block or enable, but don’t want the detail. Light-touch, high-level summaries; flag issues only when they need to decide. Example: an approving department head, finance sign-off. |
| Low Power / High Interest — KEEP INFORMED | Can’t directly block you but care a lot — ignore them at your peril, they talk. Regular updates, early visibility. Example: teams on adjacent projects. |
| Low Power / Low Interest — MONITOR | Minimal engagement. Periodic check-ins and broad communications are enough. |
Two things worth remembering about this grid: quadrant placement is about someone’s relationship to a specific outcome, not their job title. And the grid isn’t fixed — part of the job is deliberately moving people toward higher interest when it serves the outcome, not just reacting to where they currently sit.
Example (from the session): HR looks like a low-stakes, background function day to day — but for a specific ask, like sourcing a quote for a LinkedIn employee story, HR becomes high-power/high-interest, because they can block that specific outcome and they care about it. Separately: a compliance stakeholder who currently has high power but low interest is a candidate to deliberately move toward higher interest — bringing them into the loop earlier so their power works for you instead of surprising you later.
In the real world: Heathrow Terminal 5’s opening in March 2008 is a well-documented case of the grid going wrong. T5 was engineered meticulously, but a six-week construction delay compressed staff testing and training. Frontline baggage and check-in staff — arguably a high-power, high-interest group given how operationally critical they were — reported not understanding the new baggage reconciliation system, and that feedback wasn’t acted on. British Airways cancelled roughly 500 flights and misplaced over 23,000 bags in the first five days, at a cost of about £16m and a UK Parliamentary inquiry that called it a “national humiliation.” Post-mortems point to one root cause: a critical stakeholder group was heard, but not weighted the way its actual power over the outcome deserved. (stakeholdermap.com)
Assignment
Pick one small project. List every stakeholder. Map them honestly onto the grid — and check whether your actual engagement with each one matches what their quadrant recommends, or whether you’re over- or under-engaging.
Expectation management, introduced
Most “stakeholder problems” aren’t competence or process problems — they’re expectation gaps. Someone expected an X and got a Y, and that gap is where trust erodes, whether it’s honesty, a delivery date, or how much chili is in your food.
The rule that makes this work: expectation management only counts if it happens before the gap opens. After the fact, it isn’t expectation management anymore — it’s incident response.
The framework: SCOPE
Set at the start of any working relationship or project, before anything can drift.
| Letter | Set this at the outset |
|---|---|
| S — Success | What does success actually look like — defined by the stakeholder, not by you. |
| C — Constraints | The real timeline, budget, and quality constraints in play. |
| O — Ownership | Who’s responsible for what, and who decides if there’s a conflict. |
| P — Progress | How and how often you’ll update them — in the format they want, not what’s easiest for you. |
| E — Escalation | What threshold triggers escalation, and through which channel. Don’t email something urgent that should have been a phone call, then be surprised nobody responded in time. |
Example (illustrative — not from the session): Kicking off a new client project. Success — the client says success means their support team can self-serve 80% of tickets by go-live, not just “the software works.” Constraints — six-week timeline, fixed budget, no compromise on data migration accuracy. Ownership — you own the build, the client owns UAT sign-off, and you decide scope trade-offs jointly if the two conflict. Progress — a five-minute Friday video update, because that’s what this client actually watches, not the written status doc you’d normally send. Escalation — anything that threatens the go-live date gets a phone call within the hour, not an email that might sit unread.
In the real world: two of the most-cited project failures in management education are both, at root, expectation-setting failures. Denver International Airport contracted a fully automated baggage system in 1992 for an October 1993 opening — a timeline engineers had already flagged as unachievable before the contract was signed. The airport opened 16 months late with roughly $560 million in overruns, much of it the baggage system. (Calleam Consulting) The Sydney Opera House is the classic version of the same problem the other direction: construction started in 1959 before the design was finished, and the publicized budget was reportedly chosen to be politically palatable rather than accurate. It opened ten years late at roughly 1,400% over that budget. (PMI) Neither project had a genuine SCOPE conversation before the clock started.
Closing note
“If my role is to defend, I will not let a drop of blood come out of my team members. If I’m fighting a war, I’ll fight with perfection. Do not try to be on the right side or the wrong side of things — you are there to do something.”
Previous: Session 2 — Personal Commitments, Team Operating Rhythm, and SBI Feedback · Next: Session 4 — Communication Modes and Difficult Conversations
Sources: