Look, we've all been there. You ship a mobile app. Marketing wants a new flow yesterday. The backend team is three sprints deep in a service mesh refactor. Product is asking why the iOS team is "blocked" again. And somewhere in the middle of all this, somebody — probably you — is duct-taping seventeen REST calls together in a ViewModel and praying the network layer doesn't notice. Enter the BFF. Backend for Frontend. The pattern your architecture diagrams promised would save you. Except… it didn't. Because we built BFFs that just shuffled JSON around and called it a day. We took "frontend-shaped backend" and made it mean "the same backend, but with worse pagination." **It's time to do better. It's time for BFF4EAE.** Backend For Frontend, but For Extending All Endpoints — and by "endpoints" I don't just mean HTTP routes. I mean *intent*. UI state. Actions. Side effects. Feature flags. The whole janky pile of "things the client has to coordinate." A BFF4EAE doesn't just give your mobile app a tailored payload — it gives your mobile app a tailored *brain*, one that knows what to do, when to do it, and (critically) how to stop doing the thing when the thing is no longer the thing. We're going to talk about building BFFs that are self-controlling — services that own their own state machines, decide their own retries, manage their own degradation, and don't require your mobile client to be the orchestration layer for the entire company. Topics include: - **Action-shaped APIs** — why `POST /do-the-thing` beats six chained GETs and a prayer, and how to design endpoints that ship *behavior*, not just data - **The Self-Controlling BFF** — circuit breakers, adaptive backoff, and graceful degradation that lives on the server where it belongs, not smeared across three platforms in slightly incompatible ways - **UI-as-Contract** — server-driven UI without falling into the "we built a worse React on the wire" trap - **Action Manifests** — declarative descriptions of what the client *can* do right now, generated by the BFF based on user state, feature flags, and whether the downstream service is having a moment - **Killing the Coordination Layer** — moving retry logic, dependency resolution, and "wait for these three things then do this fourth thing" out of your mobile codebase and into a place that can actually be tested - **Versioning without crying** — how to evolve a BFF that controls UI *and* actions without bricking the v3.2.1 app some user refuses to update A working mental model for treating your BFF as a *product*, not a passthrough. Concrete patterns you can steal on Monday. War stories from shipping this in production at scale, including the parts that went badly because — spoiler — some of it went badly. Honest tradeoffs about when this pattern is overkill and when not using it is malpractice. Also: opinions. So many opinions. You will not agree with all of them. That's fine. Bring your own.

You survived the grind to Staff or Lead. You are technically excellent. You are holding the entire codebase together with your bare hands and honestly a little bit of spite. And yet somehow — somehow — the promotion to Sr. Staff or Principal isn't happening, leadership keeps looking past you, and you can't figure out why. I can. And I'm going to tell you, with love and zero sugarcoating, that the things keeping you stuck are the exact skills that got you here. Let's fix it. Picture this: You are a Staff Engineer. Or maybe they call you a Lead. Or a Senior Lead. Or a Senior Lead II, because your company ran out of words. You have been at this level for — let's not say how long. You are the person your team calls when something is on fire. You are the person who knows why that one service does that one thing that nobody else remembers. You have opinions about architecture that are correct, and you've been told they're correct, and then watched someone with a fancier title make the wrong call anyway while you quietly fixed it at 11pm. You are excellent. And you are stuck. Here's the thing nobody is going to put in your performance review: the habits and coping mechanisms that made you indispensable at Senior are actively hiding your readiness for the next level from the people who decide if you get there. The quiet heroics. The "I'll just fix it myself." The aversion to the visibility that feels like self-promotion but is actually just your job now. The scoping yourself to the team in front of you when the role requires you to be thinking three teams ahead. The way you've learned to survive a broken system — and how that survival mode looks, from the outside, exactly like someone who isn't ready to lead at scale. We're going to talk about all of it. Specifically, we're going to name the behaviors: The Hero Anti-Pattern: Or, Why Being Indispensable Is a Career Trap If your team cannot function without you, leadership doesn't see a Principal candidate — they see a risk they cannot afford to promote away. We'll talk about why the instinct to just absorb the problem is the thing that's keeping you exactly where you are, and what to do instead. Invisible Wins: The World's Least Efficient Strategy You shipped something incredible. You know it. Your team knows it. Does your skip-level know it? Does the VP? Because if the answer is no, it didn't happen for your career. Making your work visible is not bragging — at the Staff+ level, it is the job. We'll talk about how to do it without becoming that person. The Scope Blindspot Staff engineers who are ready to be Sr. Staff or Principal are already thinking like Principals. They're not waiting for the title to start operating at the next scope. If you are solving the problems directly in front of you and waiting to be asked about the bigger ones, leadership reads that as ceiling, not humility. We'll dig into what it actually looks like to expand your scope intentionally and visibly before you have permission. "I Don't Do Politics": The Most Expensive Thing You've Ever Said Influence without authority is the core skill above Staff. It requires relationship capital, communication across functions you don't control, and yes — some amount of navigating organizational dynamics that feel gross and shouldn't be necessary but absolutely are. We'll talk about how to build real influence without selling your soul, because those are not the same thing. The Skills That Actually Unlock Principal and Beyond Technical depth got you here. Technical breadth, cross-functional fluency, and the ability to shape organizational direction — not just codebase direction — get you to Sr. Staff, Principal, Distinguished, and maybe even CTO one day. We'll get specific about what those skills are, how to develop them, and how to start demonstrating them now, in your current role, without waiting for someone to give you a project that justifies it. This is a talk about getting unstuck. It's also a little bit of a confession, because some of these traps? I built them myself. The good news is I know how to get out of them. And I will not let you spend another two years staring at a promotion that should have happened already.