Context
Across every role I held at TCWGlobal, I kept seeing the same pattern: support tickets requesting simple backend data updates — an end date, a user's email — that nobody but engineering could actually make. Superusers, admins, and account managers all lacked the access to self-serve these changes.
Problem
Each request triggered the same slow loop: ticket, support review, dev ticket, developer query, confirmation, reporter notification. Six steps for what was often a one-line update, repeated constantly enough that it was a real drag on both support and engineering time.
My Role
I designed and owned the fix: an epic granting scoped, whitelisted permissions to a specific trusted layer, rather than routing the request through the usual RBAC conversation.
Team & Stakeholder Dynamics
The obvious but unasked question was why directors couldn't just make these updates themselves. Account managers were correctly excluded from this access — the risk of a data-entry error was real, and they weren't positioned to catch it. Directors were different: a trusted layer who'd also be accountable if a direct report made a mistake, which made them the right people to hold this access.
Process & Decisions
I deliberately chose not to build a full RBAC system. A proper role-based access control rebuild would have been the "correct" long-term answer, but it was a multi-month effort for a problem that didn't need that much machinery. I scoped the fix to exactly the data points causing friction and shipped a whitelisted-permissions epic instead — a real tradeoff, since it's less elegant than a full rebuild, but it solved the actual problem fast.
Outcome
Support tickets requesting backend data updates dropped by roughly 75%. A simple, high-friction gap closed without a multi-month rebuild, and the six-step loop mostly disappeared for the cases directors could now handle themselves.
Reflection
The judgment call here wasn't technical — it was resisting the pull toward the more "complete" solution when a scoped one would actually solve the problem. Over-engineering a fix so it looks more rigorous is its own kind of risk; the right-sized answer shipped faster and fixed the actual pain point, which was the point.