Someone, probably your exec, decides something is broken. The travel booking process, the meeting prep routine, how invoices get approved, whatever it is this month. The very next sentence out of their mouth is usually: “Can you just sort that out?”
If you’re the kind of EA who’s wired for ops work, your brain goes straight to solutions. You’re already picturing the new spreadsheet, the new approval flow, the Slack channel you’re going to set up. By the end of the call you’ve basically built the whole thing in your head.
I want to talk you out of that. Not because your instincts are wrong, but because they’re early.
Before you fix anything, you need a discovery session. It sounds like consultant-speak, I know. But it’s really just a proper conversation, with a real purpose, before you touch a single process. Skipping it is the single biggest reason ops fixes from EAs don’t stick.
Why we skip it
EAs are doers. We got good at this job by being fast and helpful, not by asking ten questions before we lift a finger. Slowing down to ask “wait, why does it actually work this way” can feel like stalling, or worse, like admitting you don’t already know the answer.
Here’s what happens when you skip discovery and go straight to building: you fix the version of the problem your exec described to you, which is usually the version they personally experience, not the version everyone else deals with. Three weeks later someone in finance tells you your shiny new process breaks a rule nobody mentioned, and you’re back at square one, except now you’ve also burned a bit of trust.
A discovery session fixes that. It’s the bit where you find out what’s actually going on before you decide what “fixed” looks like.
The four things a discovery session needs to cover
Let’s use a real example. Say your exec says, “Travel booking is a mess, can you sort it out.” That’s the whole brief. Here’s what you actually need before you go anywhere near a solution.
What’s actually broken, not what they assume is broken. Your exec thinks the problem is that bookings take too long. When you dig in, the real problem might be that nobody’s clear on who’s allowed to book what, so everyone’s nervous about committing and everything goes through three rounds of “can you just check with X first.” Different problem, different fix.
How it works today, the real version. Not the process doc (that you possibly wrote!), the version people actually use because the official one doesn’t quite work. This is where you talk to the people who do the task, not just the person who complained about it. The PA who books for three other directors will tell you things your exec never will.
What’s off the table. Every process has a few things you can’t touch. A finance rule, a tool nobody’s allowed to cancel, a person who has to sign off no matter what, however slow they are. Find these now. Finding them after you’ve built the new process is how you end up rebuilding it.
What “fixed” actually looks like, and who decides that. This is the one people skip most, and the one that saves you the most grief later. If your exec wants “faster” and finance wants “more compliant,” you need to know that before you design anything, not after you present it.
This is where it gets practical. Extra Wrap subscribers, keep going for the exact questions I ask in these sessions, a real example of how one actually went, and the mistakes I see EAs make most often when they try this for the first time. There’s also a bonus AI prompt to help you organise all your discovery session notes.
