What does it mean that what to never delegate?

Some decisions and responsibilities must remain with you — knowing which ones is a meta-skill.

Example: You are leading a product team. You delegate the technical architecture to your lead engineer, the design system to your design lead, and the go-to-market timeline to your marketing partner. All reasonable. Then a customer-facing crisis emerges: a data breach that affects trust, requires a public response, and forces a strategic decision about how the company will handle user privacy going forward. You delegate the crisis response to your communications team, the technical fix to engineering, and the privacy policy revision to legal. Each team executes competently in isolation. But nobody made the integrating decision — the one that says what this company stands for, what trade-offs it will accept, and what it will tell customers about its values. Six months later, the technical fix, the public statement, and the revised policy all point in slightly different directions, because the identity-defining decision at the center was never made by a person with the authority and context to make it. You delegated the tasks correctly. You delegated the decision you should have kept.

Try this: List three to five decisions you have delegated or automated in the past six months — to people, to systems, to habits, or to AI tools. For each one, apply the three-test filter: (1) Does this decision shape my identity or values? (2) Does this decision require context that only I possess? (3) Would I be unable to reverse the consequences if the delegate got it wrong? If any decision scores yes on two or more tests, you have identified a candidate for reclamation. Pick one and write a single paragraph describing what you would change about how that decision is handled — not necessarily taking it back entirely, but restructuring the delegation so that the non-delegable core remains with you while the delegable execution still goes to the delegate.