Writing
Notes from twenty years of this.
Short essays on the parts of enterprise delivery that decide outcomes and rarely appear in a statement of work. No newsletter, no gate — read and leave.
Your integration project will not fail on the interfaces
Every integration program I have watched go badly had a competent engineering team and an unanswered governance question. The systems agreed on the shape of the data and never agreed on its content.
Your integration project will not fail on the interfaces
It will fail on the question of which system is allowed to be right about a customer’s address.
Every integration program I have watched go badly had a competent engineering team. The APIs worked. The middleware was fine. Data moved on schedule, in the correct format, to the correct place. And six months after go-live, three people in finance were still reconciling spreadsheets by hand.
The systems had agreed on the shape of the data and never agreed on its content. Shape agreement is what an integration project delivers. Content agreement is what the business actually needed, and nobody had been made responsible for it.
That is a governance problem wearing an engineering costume. When two systems hold different values for the same customer, somebody must have decided in advance which one wins, under what conditions, and who is permitted to change that rule. Without that decision the integration propagates the disagreement faithfully, at machine speed. The manual reconciliation you were eliminating does not shrink. It grows, and now it runs nightly.
At Olam I owned a portfolio of more than three hundred applications across seventy countries. Regional teams had built genuinely good systems for their own markets, each with its own definition of a supplier, a contract and a delivery. Consolidating that estate was not primarily a technical exercise. The hard part was getting five regions to agree on what a supplier record meant, and then deciding which system owned it. Once that was settled the engineering was ordinary. Before it was settled, no amount of engineering would have helped.
The same pattern appeared again at Marsh, integrating revenue master data across thirty countries. The cloud migration strategy mattered. The data governance decisions mattered more, because they determined whether the numbers arriving in the reporting layer could be signed off by the people whose names went on them.
So three questions are worth more than any architecture diagram. For each entity that matters — customer, supplier, product, contract — which system is the source of truth? What happens when a second system disagrees with it? And who, by name, is allowed to change that answer?
If you cannot answer all three today, master data governance is not a line item inside the project. It is the project.
A test you can run this week, for free. Ask two people in different departments to pull the same customer from their own system and read the address aloud. If the two do not match, you have found your first workstream before spending anything.
And it is worth being clear about what a cheaper estimate is buying you. An integration quote with no governance work in it is not less work. It is the same work, moved to after go-live, done by hand, by finance, indefinitely.
Founder and Principal of Manki Solutions. Formerly Director of Software Engineering at Mastercard and General Manager, Head of Third-Party Applications at Olam.
When the status report stops meaning anything
There is a specific moment when the reporting decouples from reality and nobody lies to make it happen. Three things restore signal, in a particular order.
When the status report stops meaning anything
Programs rarely fail in one dramatic moment. They go amber for a quarter, and amber stops being information.
There is a specific moment in a struggling program when the reporting decouples from reality. Nobody lies. Every team reports accurately on its own piece. The aggregation still conceals the only thing that matters.
The workstream everything else depends on has been amber for eleven weeks. Somewhere in those eleven weeks, amber quietly stopped meaning this is going to hurt and started meaning we are working on it. That is not dishonesty. It is a word wearing out from use.
The executive asking why the program is late is not being obtuse — they are being told something locally true and globally useless. The delivery team is not concealing anything either. They are answering the question they were asked, in the format they were given, at the cadence they were told to use. The reporting system is working exactly as designed, and the design is the problem.
Three things restore signal, in this order.
One. Re-baseline honestly, once. Not a replan that quietly protects the original date. A genuine statement of where the work actually is, what it will take, and what that means for the date. This is painful and it is the only thing that buys credibility back. Every report afterwards is measured against a line the team believes in, which is what makes the reports worth reading again.
Two. Publish dependencies, not statuses. A RAG status describes how a team feels about its own work. A dependency map describes what is actually blocking what. At Visa I built a cross-team reporting layer for cloud security compliance across five organizations — identity, data protection, security architecture, cyber defense and infrastructure — none of whom reported to me. It did not make anyone work faster. It made the queue visible, and the queue was the problem.
Three. Put a name on every open decision. Most stuck programs are not short of engineering capacity. They are waiting on a decision nobody has been told they own. Write the open decisions down, put a name and a date against each, and take that list to the steering committee instead of the status pack. Half the amber resolves without anyone writing a line of code.
None of this is sophisticated. It is unglamorous, it is what program leadership actually consists of, and it is the reason a portfolio of programs can run predictably while a single program somewhere else cannot.
One diagnostic. Ask the program manager what would have to be true for the date to hold. If the answer is a list of things outside their control, you do not have a delivery problem. You have a governance problem, and no amount of additional engineering will touch it.
The uncomfortable part is why this is so hard to do from inside. Everyone in a position to tell you has a stake in the answer — the integrator whose revenue depends on the program continuing, the sponsor who approved it, the team that has been working nights. None of them are lying. None of them are disinterested either.
Founder and Principal of Manki Solutions. Formerly Director of Software Engineering at Mastercard and General Manager, Head of Third-Party Applications at Olam.
The second market is where the architecture decision gets made
Fork the thing you have, or separate what is common from what is local. By the third build you are not making an architecture decision — you are funding a migration.
The second market is where the architecture decision gets made
Nobody notices the cost of a bespoke build until they are asked to do it a second time, under a deadline.
At Mastercard we were delivering digital wallet platforms into three markets — Citibank Singapore, Citibanamex in Mexico, and Australia. Each had its own regulator, its own banking partners, its own expectations about what the product should feel like. The obvious path was three builds, and the first was already underway on that basis.
We consolidated onto a common core platform with market-specific layers above it instead. That is a more expensive first launch. It is a slower quarter, a harder architecture conversation, and a genuinely unpopular choice with anyone measured on the first market’s date.
It also meant every market after the first launched faster than the one before it, which is the only outcome that matters eighteen months later.
The shape of this recurs constantly in mid-market businesses, usually without the word “architecture” anywhere near it. A second branch. A second legal entity. A second country. A second product line that is almost the same as the first. In each case there is a moment where you can either fork what you already have, or do the harder work of separating what is genuinely common from what is genuinely local.
Forking is always cheaper this quarter. It is what almost everyone does, and it is frequently the right call — if there will only ever be two. The question is not which approach is better in the abstract. It is whether you honestly expect a third.
If you do, the consolidation conversation has to happen before the second build starts. Once the third has been commissioned you are no longer making an architecture decision. You are funding a migration, out of a budget that was approved for features, and explaining why the thing that worked twice now needs rebuilding.
The difficulty is rarely technical, which is why it gets missed. A common core has no single owner, no budget line of its own, and no market willing to pay for capability the other markets will use. Somebody has to fund it centrally and defend that decision in a room where every individual date gets worse before any of them get better. That is an organizational problem, and it is solved by an organizational decision, not a design document.
One question, before the second build. If we win a third next year, does this decision make that launch faster or slower? If nobody in the room can answer, the decision has not been made. It is being made by default — and default always chooses the fork.
Founder and Principal of Manki Solutions. Formerly Director of Software Engineering at Mastercard and General Manager, Head of Third-Party Applications at Olam.