Two instructor-scheduling tools inside one company is an awkward confession, but it is where this story begins. The company is invented; the numbers in it are not. Picture a flight-training group in Hyderabad with a nine-person software team looking after student records, aircraft booking, and an instructor portal spread across four campuses. For years the group worked the way most small software teams do: requests arrived, the loudest shout got built, and nobody kept a list of what already existed. Then they spent twelve months running their internal tooling as a product, under the discipline the industry now calls PlatformOps, and the before-and-after figures deserve a close look.
PlatformOps Started With an Audit, Not a Build
The first move of the newly appointed platform lead was to refuse every request to write code. She spent three weeks interviewing each development squad — not about wishes, but about workarounds: which spreadsheets were propping up which process, whose script emailed results at midnight, which report got copy-pasted into three places. Then she spent a fourth week reading access logs. What the interviews produced was a pattern Spotify researchers once labelled rumour-driven development: squads kept rebuilding near-identical things because nobody knew what already existed. One team had written a PDF generator for student progress reports; another had written a slightly worse one; a third was two sprints away from starting a third. None of the three knew about the others. Nothing malicious, just the ordinary fog of a growing organisation.
The access logs said something harsher. The team’s shared component list claimed five services depended on the old notification library. The logs showed seven callers, two of them belonging to tools whose maintainers had left the company the previous year. A record nobody verifies is not an inventory; it is a diary of good intentions. Reconciling declared consumers against actual callers took two days and quietly prevented a broken migration that would have taken two departments by surprise. From then on the reconciliation ran every quarter, and “is this still true?” became a normal question to ask of any internal page.
Every Capability Received an Owner and a Promise
The second phase looked bureaucratic from the outside and felt liberating from the inside. Each shared capability — the single sign-on flow, the template that stood up a new student-facing service, the notification library, the reporting generator — received three things it had never had before. A named owner who could answer questions about it. A published service level, written in plain sentences, saying what the capability promised and what it did not. And a support tier, so a trainee-scheduling outage at 2 a.m. knew exactly which pager to hit and which ones to leave alone.
The notification library became the honest test case. Its new owner declared it Beta rather than generally available, and wrote down the missing piece: no support yet for the Malayalam SMS gateway one campus needed. Two squads had been planning to adopt it. One waited. One adopted anyway, knowing precisely what it was skipping and who to ask when that gap hurt. That is the quiet difference between a component list and a product — the second one lets its customers make informed choices, and the act of publishing a maturity stage forced conversations that years of wiki pages never had.
What the Platform Team Never Owned
Mid-year, a well-meaning director suggested the platform group should “just take over all the infrastructure”. The lead said no, and the reasoning is worth keeping. The team’s job was the interface and the experience: the portal page where a squad requests a database, the template that assembles a compliant service, the documentation that answers questions before they are asked. The network, the raw virtual machines, the cloud accounts themselves stayed with the people who had run them for years. A platform organisation curates and presents capability; it does not have to swallow every machine behind it. Keeping that boundary small is what kept the team to two engineers instead of nine.
What the Evidence Said About Patience
Not everybody believed the effort would pay off, so the group leaned on published findings rather than enthusiasm. DORA’s research program has warned that an internal platform, run carelessly, can actually push delivery throughput and stability downwards — a tool nobody asked for is a tax, not a gift. The countermeasure chosen was measurement with teeth. For the booking API they set a 98% availability objective, which across a typical day of 2,400 requests allowed roughly 48 failures before the objective was missed. That one calculation ended a long argument about whether “mostly working” was a plan.
They also borrowed a habit from Google’s site reliability writing: when you claim a capability is ready for consumers, test the claim. Google famously ran synthesized outages against Chubby, its lock service, to watch how dependents behaved under stress. The Hyderabad version was smaller — a staged failure of the notification queue during a quiet week — and it exposed two scripts that had been silently retrying into a void for months. Their owners fixed them, not the platform group, and that detail mattered. The boundary held: application squads stayed on call for their own services, while the platform group answered only for the shared components underneath.
Progress was not linear, either. Month three was the low point — the old workarounds still worked, the new template still had rough edges, and one squad publicly reverted to its own build script. By month five the template had absorbed the compliance checks everyone used to forget until audit week, and the same squad came back on its own. Nobody wrote that dip into a slide, but everyone remembered it when the next slow month arrived.
There is a training-floor parallel the instructors at the group appreciated. A student pilot does not learn landings by reading every manual ever printed; they fly a defined pattern, with an instructor watching, until the pattern is theirs. The platform template worked the same way. It did not contain every option — it contained the safe route, the checks, and a person to call. Squad engineers flew the pattern until they outgrew it, and the ones who outgrew it were free to depart from it, provided they accepted that the support promise ended where the departure began.
Five Lessons Worth Carrying Elsewhere
Asked what they would tell a team of similar size, the group kept returning to five plain points.
- Count before you build. Two weeks of interviews and log-reading prevented at least one duplicated tool and one blindside migration. The audit is the cheapest phase of the entire effort.
- Attach a name to everything shared. A capability without an owner is a liability wearing a friendly name. Ownership is not bureaucracy; it is the difference between a question answered in a minute and a week of archaeology.
- Write the promise down, then keep it testable. A service level that can be checked — availability, latency, supported regions — settles debates that opinions cannot.
- Verify your records against reality. Self-declared lists drift. Logs do not lie, and a quarterly reconciliation is an afternoon’s work for peace of mind.
- Let demand arrive rather than assigning it. The month the backlog filled with voluntary requests was the month the team knew the model had taken hold. Mandated adoption hides disagreement; pulled adoption surfaces real demand.
The Year-End PlatformOps Ledger
Twelve months in, the count looked like this. One scheduling tool survived; the duplicate was retired with a written migration path and a two-week overlap, not a farewell email. The component record was trusted because it was checked against logs quarterly. New student-facing services went from first commit to first deployment in an afternoon. And the platform backlog filled with requests from squads — pulled demand rather than assigned demand — which the team treated as the truest signal of the year.
None of it required heroics, and the whole programme cost two engineers’ time and a lot of unglamorous writing. What it required was treating internal users as customers who could say no, and treating every shared component as a small product with a promise, a pager and a planned retirement. For readers who want the source material behind these practices, the Ops Atlas PlatformOps guide collects the definitions, the research references and the operating model in one place. Two reads from this site travel well with the story: a practical guide to learning site reliability engineering skills covers the reliability half of the work, while this aviation entrance exam guide is a reminder that structured syllabi and supported routes beat improvisation — in cockpits and in code bases alike.
