The brief is never the actual problem: Unlearning what clients tell you they want.

I remember an early project where a client handed me a detailed brief. It was specific. Measurable. It seemed like a clear map to success. I executed it almost exactly as specified. The building was delivered on time. It met every stated requirement.

Then the client's team actually started using it, and they realized something crucial was missing. Not because I'd failed to understand the brief, but because they hadn't articulated the actual problem.

That taught me something fundamental: the brief is rarely the problem statement. It's usually a symptom of a deeper challenge that the client hasn't fully identified.

Now, when a client comes to us with a project, especially in my consultancy work with hiring, I spend more time asking questions than listening to answers. "Why do you need a retail space now?" isn't about the space. It's about their business strategy. "What's your team struggling with?" isn't really about office size. It's about their organizational health.

For the HouseEazy offices, the brief was straightforward: design spaces for a growing team across multiple locations. But the actual problem was deeper. They were scaling rapidly, and they needed the physical environment to support that growth without losing their founding culture. That wasn't stated in the brief. I had to infer it through conversations.

I've learned that understanding the actual problem takes time. It requires talking to not just the decision-maker, but the people who will actually use the space. It means observing, not just listening. It means sometimes pushing back and saying: "I think what you're really asking for is something different than what you stated."

This approach has made me a better designer and a better consultant in my hiring practice too. The question "What kind of architect are you looking for?" often hides questions like "How do I build better teams?" or "Why does my current team feel incomplete?" Solving for the stated problem doesn't help. Solving for the actual problem does.

The most rewarding projects are the ones where I've understood what the client genuinely needed, sometimes before they could articulate it themselves. That's where real value in architecture lives.