Change the altitude, not the substance

This is more of an ad hoc post, one I was inspired to write rather than planned. I spent an hour today with people who think about building the way I do, trading ideas about what to make next, and remembered that this is my favourite part of the job. Not the diagrams. The conversations.

A thank you first. The messages, the questions, the people who reached out after the last few notes and trusted me with a problem they’re actually sitting on: I’ve read every one. It’s why I added the Learn AI section to khalidshams.com, from “what is an agent” through the full build workflows, so the next person who asks has somewhere to start that isn’t a sales deck. New connections, old colleagues, the people who disagreed politely in the comments: thank you. Keep them coming.

Now the thing I wanted to say.

In one day I’ll talk to a CTO about risk, cost and what the board will ask, then sit with an engineer about identity flows, permission boundaries, where state lives and what gets logged. People ask how I switch. I don’t. Same substance, different altitude.

The executive doesn’t need less truth. They need the same truth at the height where their decision lives: what it costs, what breaks if we’re wrong, who owns it, when we’ll know. The engineer needs it at ground level: which service, which boundary, which log line. If the facts change between those two rooms, one of them will eventually find out. Change the altitude, not the substance. That rule has done more for my career than any certification.

A small example. A customer was ready to buy a bigger database tier because performance had become a complaint. The easy answer was yes. We looked at how the workload actually behaved first, which queries, which tenants, which hours, and the honest answer was that the tier wasn’t the problem. To the executive: “we’re not spending that yet, and here’s what we’ll measure before we decide.” To the engineer: a list of queries. Same decision, two altitudes.

The hidden hack underneath all of this is reusable flows. Every time I break a big engineering effort into a shape a business person can see, I try to make that shape something I can use again: the questions to ask first, the boundaries to set, how to verify the result. It takes time and real attention to detail to map a solution so it survives the next client and the next team. But the day you watch one come to life in a room you’ve never been in, with people you didn’t train, is the most gratifying thing I know in this work.

Advice, since you’re still reading. Surround yourself with people who are not only like-minded but smarter than you. Then listen more than you talk. You can learn something from everyone, from the intern’s question to the CFO’s objection, if the mindset is there.

What altitude is your next conversation at?