Blog
Diagnostic, governance, and technical leadership writing from the field.
When a company adopts technology because a competitor did, a conference promoted it, or a vendor demonstrated it convincingly, the technology is rarely the problem. The problem is that the decision was made without diagnosing whether the organisation can operate what it is adopting — and that mismatch between capability and capacity is where the cost appears.
When a company shifts its business model — new pricing, new market, new channel — the technology does not break. It resists. The resistance is invisible because it presents as engineering complexity, expanded timelines, and increased cost rather than as a structural mismatch between the system's embedded assumptions and the direction the business is now heading.
When organizations lack a single technical owner, architectural decisions do not wait — they migrate into meetings. What looks like cross-functional collaboration produces an architecture nobody designed, nobody owns, and nobody can change without calling another meeting.
The most fragile parts of most companies' technology are not in the code. They are in CRM automation rules, spreadsheet formulas, no-code workflows, and integration triggers — systems running critical business processes without governance, documentation, or ownership.
Most persistent product delivery failures are not execution failures. The roadmap was written against a technical architecture that cannot support it. No sprint process, capacity plan, or estimation improvement changes this.
A system's architecture is shaped by the communication structure of the organization that built it. Organizations that attempt to modernize their architecture without changing their organizational boundaries will invest significantly and reproduce a system that structurally resembles what they replaced — because the same people, with the same reporting lines and the same interface boundaries, will rebuild to the same shape.
The cost of a technical shortcut is not the rework event. It is the continuous overhead the shortcut imposes on every subsequent decision, hire, integration, and change. This cost is real, compounds quietly, and is systematically invisible — because it presents as normal engineering effort rather than as the tax it actually is.
Data quality problems that persist after significant investment in data infrastructure are almost never technical failures. They survive because the root cause is definitional authority — who decides what key business entities mean across the company — and no data tool can resolve that question for an organization.
When the same type of incident recurs despite repeated fixes — different symptoms, similar frequency, similar organizational impact — the cause is almost never infrastructure. It is a governance or architectural condition that the incident fixing is not reaching. The post-incident review closes the symptom. The structure that produced it remains.
Automation is not a mechanism for generating efficiency from broken processes. It is an amplifier — of whatever the process already produces. In well-governed systems, it creates leverage. In fragmented ones, it accelerates the production of exactly what the process was producing before: broken outputs, at higher volume and lower cost per error.
