The train was late again, and Meera spent the extra twenty minutes on the platform reading a support ticket she could not stop thinking about. A traveller’s refund had failed because a deployment had failed, and the deployment had failed because nobody had tested it against the payment sandbox. She had written the apology email. Somewhere between that platform and Andheri, she decided she wanted to be the person who prevented the email, not the person who wrote it. That was the day her move toward DevOps began, though she did not have the vocabulary for it yet.
The Year Before the DevOps Decision
Meera had joined the travel startup as a support engineer, the person between angry customers and a tired engineering team. It was a good teacher. She learned that outages have shapes — the Friday-evening kind, the festival-season kind, the monsoon-flooding kind that no pipeline can prevent — and she learned to reproduce problems from logs before escalating them. What she did not have was permission, or so she believed, to touch anything. The fiction that operations belong to other people is the first thing anyone moving toward this field has to unlearn, and she unlearned it slowly, by asking to sit in on things.
Her sitting-in produced an unexpected discovery: the engineers did not have all the answers either. The release process was somebody’s best effort from three years ago. Once that became visible, the hierarchy flattened into something more useful — a shared problem. From that point on, her ticket queue became a source of delivery research rather than just grievance.
The Skills That Actually Mattered
Her first three months of study were humbler than any roadmap suggests. Comfort with the Linux command line. Git beyond the two commands she already knew. Reading a CI configuration file without flinching. Understanding what a container is well enough to explain it to her mother. By the fourth month she was writing small pipeline steps for the internal reporting tool, supervised, and discovering that automation is mostly careful thinking written down where a machine can follow it.
The concepts arrived more slowly than the commands. It took her weeks to feel the difference between continuous integration and continuous delivery, and longer to internalise why small, frequent releases are safer than large, rare ones. What finally made it click was the research: the DORA measures — the gap between starting and shipping a change, release cadence, recovery speed, the share of changes that misfire, and the newer tally of redone work — gave her a language for the pain her support queue had been measuring instinctively for years. Her old job had been producing delivery data all along. Nobody had called it that.
Her tools stayed boring on purpose. A free automation service for the reporting tool, a container here and there, a checklist for releases. What made the difference was repetition: the same small pipeline, rebuilt until she could rebuild it from memory. Ambitious study plans collapsed; the boring loop survived contact with her actual life.
Learning Like a Traveller, Not a Tourist
She planned study the way she planned a trip, which is to say loosely and with room to change. A flexible itinerary beats a rigid one, in Mumbai and in learning — a piece on planning a flexible Mumbai holiday could almost be repurposed as study advice. Her syllabus came from three books passed around the office: Accelerate, the second edition of The DevOps Handbook, and Martin Fowler’s early essays on continuous integration. She kept a notebook of every term she could not define and interrogated one per commute. Some commutes produced two; the slow days on Western Line produced three.
Not every evening worked. There were weeks the day job swallowed everything, weeks the notebook stayed in a drawer. The honest version of a career change is that it happens in most of the gaps, not all of them. She learned to keep the notebook small enough to restart after a bad week, which turned out to be the most transferable skill of the entire year.
The Outage That Became Her DevOps Interview
In July, the booking search went down during a storm, for reasons unrelated to the storm. The engineer on call was on a flight. Meera, who had by then quietly documented the recovery steps for her own support work, walked the team through them on a shared call. Restoration took forty minutes instead of the usual half-day, and the post-incident review — blameless, for once — listed her runbook as the reason. Two months later the company created a junior platform role. Nobody was surprised who filled it.
She still writes apologies occasionally. But the apology emails now arrive with a deployment identifier, a named owner and a fix that ships within hours, because the delivery culture around her changed too. That is the part of a DevOps career nobody puts in the job description: you are hired for your skills and you stay for the calm.
What She Would Tell Last Year’s Self
Asked for advice, Meera keeps it short, in the way of someone who has done the hard thing and dislikes making it sound mystical.
- Learn the command line and Git properly before anything fashionable.
- Read the research early; the delivery findings will give your instincts a vocabulary.
- Automate something small at work, with permission, and let it be seen.
- Write down recovery steps as you learn systems — runbooks are career capital.
- Sit in one blameless review and take notes on how questions differ from accusations.
One more thing she emphasises, usually to people who assume otherwise: none of this required her to become a different person. The patience that made her good at support — reading logs, reproducing problems, translating between angry humans and quiet machines — is most of the platform job. The title changed; the temperament was already there.
For the full landscape she was stepping into — the frameworks, the history, the complete measures — xOps School’s DevOps reference became her default tab for a season. And for anyone starting from a support desk in this city, she offers one last observation: the commute that feels wasted is usually the only quiet hour you own. Some of us learn frameworks on it. Others just plan better weekends — this guide to spending less time in traffic covers the other option, and these notes on the city’s busy streets explain why the trains test everyone’s patience. Meera took the frameworks. The platform was late anyway.