- Situation
- Technology choices were announced rather than argued, so nobody outside the room could challenge them and debates reopened later.
- Task
- Make the reasoning behind each decision outlive the decision, without imposing heavy documentation.
- Action
- I set a standing practice: name the choice, name the closest shortlisted alternative, and link to where the why lives, in a small table.
- Result
- The practice carried across projects and became what new decisions arrive with, so decisions can be reviewed on their reasoning.
◈ View in the world- Situation
- The chatbot platform's runtime holds conversation state in memory, so under high availability any pod restart dropped live conversations.
- Task
- Survive pod churn without rewriting the conversational runtime the product was built on.
- Action
- I checked alternative frameworks, found the same limit, and kept the runtime: sticky sessions, state persisted to Mongo, and Redis pub/sub to close duplicates.
- Result
- The platform ran multi-container with state surviving restarts, and the design documented its failure modes, including those the fix introduced.
◈ View in the world- Situation
- The bot platform needed web push notifications, and my instinct was to build it in house for future flexibility.
- Task
- Decide between building and buying, separating engineering reasons from personal preference.
- Action
- I wrote down what I wanted from in-house, weighed it against what the release needed, and recorded the preference and the decision against it.
- Result
- We shipped on the vendor, and the recorded trade-off made later customisation questions easy to answer.
◈ View in the world- Situation
- Cloud spend was climbing, and no single person could see which servers it went to because billing access was split.
- Task
- Establish the real footprint before deciding what to shut down.
- Action
- I scripted a sweep across cloud projects that listed every virtual machine with its project and state, then sequenced access, pruning and backups.
- Result
- Pruning followed the inventory instead of guesswork, and the sweep set the order of what to stop.
◈ View in the world- Situation
- A senior engineering candidate had been assessed by a reviewer I trusted, and the recommendation was already written.
- Task
- Decide whether I agreed by reading the candidate's actual work rather than the review of it.
- Action
- I reviewed both pull requests, issue discussions and documents independently, then wrote my assessment point by point, differing on the algorithmic work.
- Result
- The decision changed on the merits, and the reviewer could see which points I accepted, setting the expectation that recommendations are examined.
◈ View in the world- Situation
- Two pipelines had each been split into many microservices that shipped, failed and were debugged together, adding cost without independence.
- Task
- Make the case for consolidation on operational cost, with the boundary authors in the room.
- Action
- I wrote up the reasoning for a loosely coupled monolith, keeping only the seams with distinct scaling or failure characteristics and merging the rest.
- Result
- Fewer services to deploy, fewer cross-service failures to trace, and each remaining split could be defended individually.
◈ View in the world- Situation
- Model spend was climbing across products, and the instinct was to change models or shrink prompts without breaking the bill down.
- Task
- Cut cost through a mechanism we could explain, without switching to a cheaper model and losing quality.
- Action
- I reviewed usage per project so consumption was attributable, saw identical completions paid for repeatedly, implemented prompt-completion caching, and tracked the bill afterwards.
- Result
- Cost fell sharply with no change to models or outputs.
◈ View in the world