The brief this memo answers
The memo below answers a fictional brief, typical of the shape these exercises take. You are interviewing to lead engineering platform work at a business-to-business payments scale-up. The pack says there are 140 engineers in 18 product teams and an 8-person infrastructure team that works from a ticket queue.
Services run on three hosting generations: an old virtual-machine estate, a half-finished container migration, and team-owned scripts. An internal survey says product teams spend about 20% of their time on infrastructure work. A new service takes about six weeks from empty repository to production, and two of last year's four major incidents were traced to configuration drift between hosting generations. The readers are the CTO and the CFO.
Every number in the memo comes from that pack or is derived from it. Figures are illustrative.
The memo, as submitted
Recommendation
Turn the infrastructure team into a 12-person platform team, run as a product with its own product manager, and give it one goal for two years: any product team can take a new service from empty repository to production in a day, on one supported path, without filing a ticket. This needs four hires and two decisions from you, listed at the end.
Where we are
Three facts drive this. First, roughly 20% of product-team time goes on infrastructure, which across 140 engineers is the equivalent of 28 people. Second, a new service takes six weeks to reach production, mostly spent waiting on tickets, so teams avoid creating services and bolt features onto old ones. Third, running three hosting generations is now a reliability problem as well as a cost one: two of our four major incidents last year came from configuration drift between them.
The cause is not effort or skill. We have three ways to run software and none of them is the obvious default, so every team makes its own infrastructure decisions, and the infrastructure team spends its time answering tickets about all three.
Where we will be in October 2028
A team starting a new service picks a template, and by the end of the day it is in production with a pipeline, logging, metrics, alerting and a cost tag, without asking anyone. The oldest hosting generation is gone. The platform team publishes a roadmap, takes feature requests like any product team, and is judged on whether teams choose its path.
What we will do
We will build one paved path for new stateless services first, because that is where the six-week wait hurts most and where adoption is easiest to prove. We will then migrate existing services off the oldest generation and retire it, which removes the drift that caused last year's incidents. In year two we will add self-service databases and per-team cost visibility.
What we will not do
We will not adopt a second cloud provider; the brief shows no regulatory or customer driver, and it would double the platform surface. We will not build a developer portal before the paved path exists, because a catalogue of three inconsistent options is still three options. We will not force existing services onto the new path in year one; new services must use it from month six, and existing ones move when the oldest generation is retired. And we will not take on data-platform work, which belongs to the analytics roadmap.
Sequence and gates
| Window | Work | Gate before the next step |
|---|
| Months 0-3 | Form the team, hire the product manager, measure baselines, choose two pilot teams | Baselines agreed with finance |
| Months 3-9 | Paved path for new stateless services | Six teams have shipped on it; new-service lead time under one week |
| Months 9-18 | Migrate off the oldest generation, single configuration source | Oldest generation retired by month 18 |
| Months 18-24 | Self-service databases, per-team cost reporting | Adoption above 80% of deploys |
If the month-9 gate fails, we stop and re-plan rather than starting the migration.
Measures
| Measure | Today | Month 12 | Month 24 |
|---|
| New service to production | About 6 weeks | Under 1 week | Under 1 day |
| Deploys through the paved path | 0% | 40% | 80% |
| Product-team time on infrastructure (same survey question) | 20% | 14% | 8% |
| Major incidents caused by hosting drift | 2 last year | Tracked | None after retirement |
Cost and return
The cost is four hires: a platform product manager and three engineers, added to the existing eight. If product-team infrastructure time falls from 20% to 8%, 140 engineers get back the equivalent of 16.8 people (140 × 12%). At a weaker 14%, the figure is 8.4. Either clears the four new hires, but I would not rest the case on this arithmetic, because survey percentages are soft. The firmer arguments are lead time and reliability. Dual-running costs during migration are unknown until the month-3 inventory, and I will bring a figure to that review rather than guess one now.
Risks
The platform team could become a slower ticket queue with a new name; the product manager and the adoption measure exist to catch that. The two pilot teams will lose some roadmap capacity for a quarter. Migration could stall at the last few services, which is why retirement has a date and an owner.
Decisions I need
Approve the four hires. Agree that new services use the paved path from month six. Agree that the oldest hosting generation is retired at month 18, with the CTO as the escalation point for exceptions.
What assessors mark in a technical vision memo
Assessors at this level read for four things the brief never names. The first is whether the end state is concrete enough to fail. "A modern, scalable platform" cannot be checked; "a new service in production in a day" can. The second is whether the not-doing list has teeth. Each exclusion above is something a real group would ask for: the multi-cloud advocate, the team that wants a portal, the analytics roadmap.
The third is honesty about the numbers. The memo derives its return from the brief, shows a weaker case, and then says the return is not the main argument. A memo that presents 16.8 engineers as a saving would be challenged by any CFO, because nobody is being removed. The fourth is whether it ends on decisions. "I need your support" cannot be acted on; three specific approvals can.
Technology nouns are not a technical vision
The trap that separates strong submissions is writing the vision in tools: Kubernetes everywhere, a service mesh, an internal developer portal. Those are means, and a reader outside engineering cannot tell whether the business will notice. The memo above never names a runtime or a tool, because the technical vision is the experience of a product team and the reliability the CFO is paying for. Tools belong in the appendix or the follow-up conversation, where they can be defended against alternatives.
A related failure is the memo that describes the platform strategy the engineers would enjoy building. If every item in your plan is interesting work and nothing is a retirement, a mandate or a refusal, it is a wish list.
A vision memo earns funding when the end state can be checked, the exclusions would upset someone, and the last paragraph asks for decisions the reader can make this month.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).