Setting Clear Expectations

When we scaled the engineering team at EuroDNS from five people to fifteen, I assumed the problems were about hiring. Then I decided they were about communication. It took longer than it should have to realize the actual problem: I kept delegating before I'd finished thinking.

"Can you handle the migration?" I'd ask. And someone would — in the way they understood it, which wasn't always the way I'd imagined it. Nobody was wrong. I just hadn't said what "right" looked like before the work started.

This is the expectation gap, and it's everywhere. It's mostly invisible because both sides are operating in good faith. The person who received the task thinks they understood it. The person who assigned it thinks they were clear. The mismatch only surfaces when the work comes back.

The gap shows up in something as small as a one-line task. "Update the website" and "Update the product descriptions on the New Arrivals page — the copy is in the shared doc, it needs to be live by Thursday 5pm because we're sending the email campaign Friday morning, and if you need design changes beyond the text, flag it before you do anything" describe the same task. The second version takes ninety seconds to write. The first one takes hours to untangle after the fact. The first version is actually the lazy one, not the trusting one.

Remote work makes this worse in a specific way. In an office, ambiguity has a short half-life. Someone catches you in the hallway, asks a clarifying question, and the mental model gets corrected before it causes real damage. Distributed work stretches that feedback loop across time zones and calendar gaps. I manage teams in Luxembourg, Morocco, France, and Spain. A fuzzy instruction on Monday can produce four days of confident, well-intentioned work in the wrong direction before we speak again. By Thursday, the cost of the original vagueness has compounded.

Most leaders resist being specific because they're afraid of micromanaging. That fear is real but pointed at the wrong thing. Specifying what doesn't constrain how. "The database migration needs to complete before the EU business day starts on Thursday" isn't control — it's context. The engineer can still choose their approach, their tools, their way through the edge cases. They just know the constraint they're working inside. Without it, they're guessing, and guesses go wrong quietly.

The thing most leaders skip is the why. Not a long explanation, just enough context to let the other person make good decisions when they hit the unexpected. Most tasks have at least one constraint that isn't obvious from the task itself — a dependency, a deadline with commercial consequences, a stakeholder who needs to sign off. When that context is missing, every edge case becomes either a blocker or a guess. Both are expensive.

There's a happiness dimension to this that I underestimated for too long. The least satisfied people on any team aren't the overloaded ones. They're the ones who don't know if what they're doing matters, or whether they're doing it well. That uncertainty is corrosive. It doesn't show up in any metric until someone resigns.

Good expectations are specific about the outcome and flexible about the method. They're written down, so there's no reconstruction afterward. They carry a real timeline — not "when you can," which is a polite way of saying this isn't a priority. And they include enough context that the person holding the task can make reasonable decisions when something unexpected comes up, without needing to surface everything back to you.

Setting expectations isn't a management technique. It's what finishing your thinking looks like before you hand work to someone else. When you skip it, you're not trusting your team — you're offloading your own unfinished work downstream and calling it delegation.