Diagnosis
I read the code, the incidents, and the delivery history — then I talk to the people who carry the pager. The constraint is rarely where the org chart says it is.
Most platforms do not fail. They slow down, and the slowdown gets described as a people problem. I am usually called once it is clear the problem is architectural.
Delivery has slowed and nobody can point at a single cause.
A monolith that everyone agrees should be split, and nobody agrees how.
Incidents that are survivable but never fully explained.
A migration that has been six months from done for a year.
An AI initiative that produces code faster than the team can review it.
I read the code, the incidents, and the delivery history — then I talk to the people who carry the pager. The constraint is rarely where the org chart says it is.
The three or four architectural choices that actually move the outcome, each with its cost and what it forecloses. Not a list of best practices.
I stay long enough that the decisions survive contact with the roadmap: design reviews, the first services, and the guardrails that keep the pattern from eroding.
A written architectural assessment: what the system can carry today, where it will break next, which three decisions matter most, and what each one costs. It is useful whether or not we work together afterwards. Telecom Argentina and Sky Mexico are what this deliverable looks like: an assessment, an architecture, and a roadmap the client can act on.
Consulting is delivered through SiliconTrace, a consultancy currently being built.