The dashboard that got applause
I built the visible part first.
Early on I shipped dashboards that were fast, clean and useful-looking, with a backend still trying to catch up to what the front end had already promised. Months later the same team was spending its week keeping things upright: brittle data contracts, unclear ownership, lineage nobody could explain. You cannot retrofit a foundation under a system people already depend on.
Now: data contracts and ownership first, slightly over-built, before anything with a chart on it. It feels slow for a month and is the only version that stays fast.
A PostgreSQL escalation
I nearly resized before I understood.
An Azure Database for PostgreSQL Flexible Server under real pressure, a customer whose whole modernisation programme depended on it, and a room full of confident theories. The instinct is to add capacity and move on. We stopped and established where the load actually came from, which queries, and what the resilience posture really was versus what everyone assumed. Resizing first would have meant the same problem at a higher bill, and the credibility spent before the harder conversation.
Now: root cause before remediation, every time, even when the room wants the fast answer.
"Send everything to Sentinel"
I mistook visibility for coverage.
I have seen the invoice that sentence produces: every verbose log from every subscription flowing in, priced per gigabyte, and a SOC drowning in data it never wrote a single detection for. Seeing everything felt safe. It was expensive noise.
Now: detection first, ingestion second. Decide what you need to catch, trace backwards to the sources that feed it, and let the log bill be a consequence of that choice.
The pilot that never ended
I let a pilot start without a definition of done.
Six months in it still had users, a Teams channel and a renewed budget line, and no decision, because nobody had written down what would trigger a production build or a shutdown. It lived in the space between, indefinitely.
Now: exit criteria go in the first document, before the architecture. A clear no is a win; the only loss is the drift into permanence.
The honest number
I rounded an estimate to what the room wanted to hear.
The honest answer was somewhere between four and nine months depending on three things nobody knew yet. What got written down was six, because it fit the slide and the fiscal year. Month seven arrived, and the person who said six was explaining.
Now: a range, the assumptions that put you at each end, and what it costs to resolve the biggest unknown early. Less satisfying in the meeting. Far better in month seven.
My own AWS platform
I set the cost alarm where it would only catch disasters.
Running a consumer platform alone, I learned that cost is the fastest signal you have. Errors need a log to be read; latency needs a user to complain; cost just accumulates and is measured for free. The alarm I eventually set low enough to be occasionally annoying has paid for itself three times: a retry loop over a weekend, a storage class with retrieval charges I had not read carefully, a test environment I forgot existed.
Now: budgets per environment, thresholds at "surprising" not "catastrophic", daily granularity, and a human who receives it.
