Every data team has a Brent. The one person who knows everything. The one person the org can’t afford to lose. The one person who’s about to burn out.
In The Phoenix Project, Brent is the brilliant engineer everything flows through. Nothing ships without Brent. The organization created a bottleneck, then blamed Brent for being overloaded.
Goldratt’s Theory of Constraints - originally a manufacturing framework - explains exactly what’s happening on your data team. Any improvement not at the bottleneck is an illusion. Hiring 3 junior engineers doesn’t help if they all need Brent to review their work.
I’ve seen this at almost every client. There’s always someone who knows where the legacy data lives, why that one transformation has a weird join from 2021, and which pipeline will break if you touch the customer table.
Goldratt’s fix applies directly: protect the constraint. Reduce unplanned work hitting Brent. Document what’s in Brent’s head. Distribute it. Make Brent replaceable - not because Brent isn’t valuable, but because the org shouldn’t be fragile.
The uncomfortable part: Brent isn’t the problem. The org made Brent by never investing in documentation, pairing, or knowledge distribution. A manufacturing theory from the 1980s diagnosed your data team’s problem better than any agile retrospective.
Who’s the Brent on your data team? What happens when they quit?