I recently had the pleasure — and the mild terror — of guest lecturing, standing in front of a room of people who design and shape cities and trying to teach them about data. Not data professionals. Urban thinkers, planners, the kind of people whose expertise is the physical and social fabric of a city, now colliding with the fact that cities have become enormous generators of data. And I came away from it having learned at least as much as I taught, mostly about the gap between having data and using it, and about how teaching a thing reveals whether you actually understand it.

So these are my notes from that experience — less about what I said to them, more about what standing there taught me.

Teaching forces a reckoning with what you actually know

The first thing I rediscovered is an old truth that never stops being true: you don't really know something until you have to teach it to someone who doesn't. In my day-to-day work I lean on a scaffolding of jargon and shared assumptions — I can say "we'll stream it through Stream Analytics into a time-series store" to a colleague and we both know what that means and why. Strip all of that away, stand in front of people for whom every one of those words is empty, and you're forced back to the actual ideas underneath.

And that's clarifying in an uncomfortable way. Several times, preparing, I reached for a concept I use constantly and found that when I tried to explain it from first principles, without the jargon, my understanding was shakier than my fluency had suggested. Fluency in the vocabulary had been standing in for depth in the ideas. Teaching found the gap, because a room of smart non-specialists will not let you hide behind a term — they'll ask what it means, and "it means the thing we call it" is not an answer. Every time I had to translate a piece of my own field into plain language, I understood it better myself.

The gap that isn't technical

The more important thing I learned was about them, and about the real barrier to cities — or any organisation — actually benefiting from data. I'd assumed, walking in, that the gap was technical: they didn't have the data, or the tools, or the skills to process it. That's not where the gap was at all.

These are people swimming in data. Cities generate torrents of it — movement, energy, environment, usage. They don't lack data. What they lacked, and what the session kept circling back to, was the bridge between the data existing and the data informing a decision. And that bridge is not technical. It's about:

  • Knowing what question to ask. Data answers questions, and the hardest part is often formulating the right question of your domain — something a planner understands far better than I do, but only once they see data as a thing you interrogate rather than a thing you have.
  • Trusting what it says enough to act. A number changes nothing until someone believes it enough to make a different decision because of it. That's a matter of communication and credibility, not computation.
  • Translating between two expert worlds. They understand cities; I understand data. The value isn't in either expertise alone — it's in the conversation between them, and that conversation needs someone who can stand in the middle and translate both directions.

That third point landed hard, because it's the thing I keep discovering is my actual job, in every context, whatever the technology of the day happens to be.

The translation is the work

I came into data from communication — that's my origin, and it's the conviction I keep returning to: that data is fundamentally people communicating, and the human layer is where the value concentrates. Standing in front of the city-makers was that belief made vivid. The technical part — the platforms, the pipelines, the queries — matters, and I love it. But it was almost entirely not what stood between these people and getting value from their data. What stood in the way was the absence of a shared language between the people who understand the domain and the people who understand the data.

Which means the most valuable thing I could offer them wasn't a tool or a technique. It was to model the translation — to show that data concepts can be spoken in plain human terms, that you don't need to become an engineer to reason about data, that the intimidating vocabulary is a curtain you can pull back. Watching a planner's face change when a concept they'd found forbidding suddenly made plain sense was worth more than any architecture I could have drawn.

Cities aren't short of data, and organisations rarely are either. What they're short of is the bridge between the data and the decision — and that bridge is built out of translation, trust, and the right question, none of which are technical.

What I'm taking back to the day job

Two things stuck, and they've changed how I work since. First, the practice of explaining my own field without jargon isn't just good for the audience — it's the fastest way I know to find the soft spots in my own understanding, and I've started deliberately doing it even when no one's asking, as a private test of whether I really know a thing or just know its name. Second, and bigger: the guest lecture reinforced that the scarce, valuable skill in a data-drenched world isn't the ability to process data — that's increasingly abundant and increasingly automated. It's the ability to stand in the gap between the data and the people who need it, and translate, in both directions, until a number becomes a decision.

I went in to teach city-makers about data. I came out reminded that my real subject was never the data at all. It was the conversation around it — and that's a thing worth getting better at teaching, because it's the thing almost nobody else is teaching, and it's the thing that actually decides whether all that data ever changes anything.