The Founder Who Is Also the Problem

Working hypothesis: the turnover is a leadership-behavior problem concentrated at the top, not a manager-skill problem. The evidence pattern is consistent - centralized decision rights (all promotions), role encroachment (chairing reviews, rewriting code publicly), and exit data that is likely softened because HR is not independent of the CEO. 'Career growth' is a socially safe exit narrative; it may be true, but it's confounded.

Tests before confrontation:

1. Triangulate exit data - request de-identified raw exit notes and, if feasible, brief neutral follow-up conversations with 4–6 departed engineers conducted by me (not HR), framed as a learning interview.
2. Map decision rights - document who actually decides promotions, technical direction, and reviews. A simple RACI-style artifact makes the centralization visible without accusation.
3. Stayers' perspective - a short anonymous pulse with 3–4 targeted items (autonomy, voice, recognition) to see whether the pattern generalizes beyond leavers.
4. Test alternative explanations - compensation benchmarking and market data, since 'career growth' could also mean pay or title ceilings.

I would not present a diagnosis of the CEO in a room the CEO controls until I have corroborated data and have discussed the framing with him privately first.

Presenting a leader's behavior as the root cause in front of his direct reports is a high-risk, low-yield move - it triggers defensiveness and makes the team complicit in a public critique. I'd restructure the sequence:

1. Pre-brief the CEO privately first, with data not verdicts: 'Here's what the pattern shows; here's what it might mean; I want to test my read with you before we discuss it as a team.' This gives him a chance to offer context (e.g., a funding crunch driving control) and preserves his standing.
2. Reframe the team session around system, not person: present decision-rights mapping, turnover cost, and the autonomy/voice data as organizational facts. The CEO's behaviors appear as structural features (approval bottlenecks, review design) that the team can redesign together.
3. Convert to a shared problem: ask the team what they'd need to change so senior engineers own technical decisions. The CEO's participation in that conversation is the intervention.

If the CEO insists on a confrontational public reveal, I'd negotiate scope down to a working session and flag the risk in writing. My loyalty is to the system's health, which includes the CEO's ability to lead the change.

I'd accept the opening but resist the frame of 'fixing the CEO.' The goal is a behavioral contract, not a personality change.

Response structure:

• Acknowledge without over-attributing: 'The data point to a pattern of decision centralization and public rework. That's a system you built, and it's also the system you can change. I'm not diagnosing you.'
• Co-design 2–3 concrete, observable behavior changes with him, e.g.: (a) promotions above junior decided by a calibrated panel he chairs but doesn't unilaterally decide; (b) sprint reviews chaired by the tech lead, with the CEO as participant; (c) code feedback given in PRs, not live meetings.
• Make it public and testable: he announces the changes to the team himself, with a 90-day check on the autonomy pulse and engineering retention.
• Address the HR independence issue - exit interviews need a neutral channel, or the data will keep lying to him.
• Build in support: an executive coach or peer group for him, since behavior change under a founder's identity load is hard solo.

I'd also name the risk honestly: if the behaviors don't change, the turnover will continue, and I'd say so plainly - respectfully, but without softening it into uselessness.