In data and analytics the course is rarely set by the big bets. It is set by the quiet accumulation of small choices: the partition picked today, the metric someone decides to measure, how a field gets modelled, how a source gets integrated. Those choices feel automatic at the time, and I have watched them either accelerate a project or complicate it for years. This is where I write about them.
I work on data architecture: how information gets modelled, moved, and made trustworthy enough that people will act on it. Most of the work that matters happens before anything is built — agreeing what a metric actually means, deciding where a boundary belongs, and telling apart the complexity a system genuinely needs from the kind it has merely inherited.
"Done is better than perfect!"
I came to this by building. Shipping applications end to end teaches you what happens downstream when a schema is convenient rather than correct, and that is the perspective I bring to architecture now: designs that survive contact with the people who have to implement them and query them later. I still keep my toolset deliberately compact — fewer technologies understood properly beats a longer list.
The medallion architecture divides a lakehouse into three layers, and anyone can read them without instruction: bronze is what arrived, silver is what’s been cleaned, gold is what you can use. Then two teams query …
A chat on top of your warehouse feels like you’ve finally crossed the finish line. Users ask in plain language, the model generates SQL, and the endless queue to your data team simply disappears. Then someone asks …
To read more here.
