Writing Process

I’ve always had an inclination to write.

When I was in 10th standard, around 15 years old, I put together a small 12-page booklet on organizational management. It sounds unusual now, but even then I was thinking about how businesses should be structured, how departments should work together, and how roles should be defined. At that age, I didn’t know that entire libraries already existed on these topics. I was simply writing what made sense to me.

Around the same time, I also wrote short stories. They were personal, emotional, and very raw. Writing became a way to capture what I was feeling as I was growing up. I still have some of those pieces, and every once in a while I go back and read them. I’m often surprised by how much self-reflection was already there, even when I had no real awareness of it at the time.

In engineering college, writing took a more practical form. I was deeply involved as a student leader and eventually formed an organization called the Instrumentation Technology Student Association. Our labs were in poor shape. Cables were broken, instruments didn’t work, and experiments required more fixing than learning. To solve this, I raised funds, worked with faculty, and focused on improving what we already had instead of buying everything new.

During this time, I wrote another informal book called the The P Code this one focused on how to build engineering projects using existing tools and limited resources. It covered topics like reusing hardware, basic soldering, PCB creation, software development, and even how to obtain free samples from manufacturers. I never formally published it. I shared it with peers and uploaded versions to my personal website. But the urge to write never went away.

That same mindset carried into my professional career. When I joined a chemical manufacturing company as an instrumentation engineer, I also took on IT responsibilities because there was no dedicated IT staff. I managed servers, backups, audits, upgrades, vendor coordination, help desk support, and infrastructure for over 120 employees. At the same time, I became deeply involved with OT systems, DCS environments, and even physical security.

Incidents were constant. Server failures, hardware issues, overheating server rooms, malware infections, and operational disruptions were part of daily life. I was responding to incidents continuously, often without formal procedures, checklists, or response plans. This hands-on exposure shaped how I understood operations, technology, and risk.

By 2016, ransomware and cyber incidents were becoming mainstream news. I started attending conferences, learning more, and connecting patterns. When our organization was hit by malware that turned our Windows servers into spam-sending machines, the gaps became obvious. There were no incident response plans. No business impact analysis. No continuity planning. And the incident didn’t stop at IT. It affected OT systems as well.

I didn’t know it then, but this was the beginning of the book.

By 2016, self-publishing was becoming more accessible. Amazon was changing how people read and write books, and I started seeing professionals publish e-books based on real-world experience. That planted a seed.

At work, I was increasingly pulled into emergency response meetings. I often acted as the IT liaison during incidents, supporting the incident commander and operations teams. Anything that touched computer systems, communication, or automation usually landed with me. For example, when emergency messages needed to reach employees quickly, I figured out how to use enterprise Windows management tools to push pop-up alerts to every workstation, supplementing alarms and announcements.

Accountability during emergencies became another problem to solve. Paper forms worked, but they weren’t enough. We needed a backup that was automated. I had access to the badge access control system, which tracked employees, contractors, temporary workers, and special access badges. Working with an instrumentation and DCS engineer, we explored ways to use that data to support accountability at muster locations.

As all of this was happening, one thought kept coming back to me. If I’m learning this much, I’m going to forget it. I should document it.

So I started writing again. This time, the focus was on understanding IT systems and emergency operations, without exposing sensitive details. I learned how to explain problems, workflows, and decision-making without naming specific tools or systems. I focused on roles, coordination, and how people actually respond under pressure.

By the time I reached around 100 pages, I felt the book was “done.” Attention spans were shrinking. Smartphones were everywhere. Early e-readers felt slow and limited. I still thought of books as something printed and physical, not digital.

I started reaching out to publishers. A few responded. Most said there wasn’t a clear market, or that the topic didn’t fit their catalog. Others suggested I look elsewhere. It was discouraging, and the manuscript moved to the background as life and family responsibilities took priority.

Around 2018 and 2019, the term Operational Technology started appearing more frequently. When I first saw a job posting with “OT” in the title, I had to look it up. At the time, the search results mostly returned occupational therapy. Still, something clicked. I realized that much of what I had been doing for years finally had a name. And that unfinished book was still waiting.

By 2023, I was already deep in the work.

I had been involved with multiple professional organizations, standards groups, and committees, contributing to discussions around industrial systems, safety, security, and resilience. I was speaking at conferences, participating in working groups, and helping shape frameworks related to incident management in complex environments. Over time, that gave me confidence. Not the loud kind, but the quiet confidence that comes from having seen real problems and worked through them with real teams.

That same year, I was also navigating my immigration process. During one of the discussions, my attorney asked a simple question: “Do you have any publications?” I did. Technical documents, guidance, articles, and contributions through nonprofit and professional organizations. Then she asked another question: “Do you have a book?”

That question took me back to 2016. I remembered the unfinished manuscript. The roughly 100 pages I had written years earlier and then set aside. At the time, it hadn’t found a home. Now, nearly eight years later, the industry had changed. The conversations had changed. The urgency had changed.

I went back to that document with fresh eyes. Over several months, I reviewed it line by line, marking what still mattered and what no longer fit. I built a proposal around the core idea rather than the old structure and reached out to publishers again. This time, the response was different.

There was clear interest in critical infrastructure, incident management, and operational resilience. Organizations were struggling with talent gaps, but just as importantly, with knowledge gaps. Information had become a critical dependency. How incidents are understood, communicated, managed, and learned from often makes the difference between recovery and prolonged damage.

I was in a position to write the book, not because I had time, but because I had clarity. I knew the audience. I knew the problems. I knew what was missing. A publisher proposed an aggressive timeline. I was upfront. I could write, but only outside work hours. They agreed to adjust expectations. What was originally planned as months turned into years. And that was intentional. Because this time, I wasn’t just trying to write a book. I was trying to write the right one.

There is no real process for writing your first book. At least not in the beginning.

You discover the process toward the end, after you’ve already struggled through most of it. Early on, the most important thing is having an open mind. I didn’t fully have that. I believed I could schedule writing, structure it neatly, and stay organized. That turned out to be much harder than I expected.

When I signed the contract with my publisher, they provided a rough timeline. There were incentives built into it. If I completed and submitted drafts for a set number of chapters, I would receive part of the advance. That kind of structure sounds motivating, and it is, but reality rarely follows the plan. Over nearly two years, I probably met the schedule once. Most deadlines were missed, moved, or renegotiated.

Writing a chapter means starting from a blank page every time. You’re not editing notes. You’re creating something from scratch. And doing that on a computer comes with constant distractions. New tabs. Emails. Messages. Notifications. Even small interruptions break momentum.

For the first month, I struggled to find any rhythm at all. I realized that if I didn’t intentionally remove distractions, I wouldn’t finish the book. So I changed my environment. I used a separate laptop dedicated only to writing. It had minimal applications installed and access only to the publisher’s platform. I didn’t log into email, banking, or social media on it. Writing had to be deliberate.

I also changed how I used my time. I bought a small foldable table and carried it with me. When my son was at swim practice, instead of scrolling on my phone, I would sit and write. On weekdays, I wrote one to two hours in the evenings. On Saturdays, four to five hours. Sundays, a little less. Every week.

If I missed a week due to illness or life, I made it up the following weekend. Over time, I learned that I needed about eight focused hours per week to keep moving forward.

Before any writing began, there was the outline. Creating it was one of the hardest parts. I spent time in libraries, reviewing existing books on incident management, emergency response, OT, ICS, IT forensics, and even cyber law. I bought books I hadn’t read before, not to copy them, but to understand what already existed and where the gaps were.

I didn’t want to write in a silo. I also didn’t want to contradict established thinking in ways that made the book unusable. That balance required constant review and self-correction. Even today, I can find areas I would improve. At some point, you have to accept that no book is ever truly finished.

Near the end, my wife told me something I needed to hear. If I kept refining endlessly, the book would never be published. I had to stop writing and submit it. That moment mattered more than any edit.

Another major part of the process was learning how to handle feedback. The editorial team reviewed drafts, added comments, questioned sections, and sometimes told me that entire parts didn’t belong where I had placed them. There were days when four or five hours of writing had to be cut or moved. I never deleted that work. I kept everything. Some sections found a better place later. Others never returned. That was part of the learning.

In December 2025, after more than two years of writing, revising, and reworking, I submitted the final manuscript.

Toward the end, the work became more technical. Images, tables, and charts needed refinement. Content had to be reviewed carefully for clarity, accuracy, permissions, and proper citations. This phase required close coordination with the editorial team and the publisher. It was detailed, methodical work, and it mattered just as much as the writing itself. A book is not finished when the words are written. It is finished when it is ready to be read.

When everything finally came together, the experience felt deeply satisfying.

More importantly, the journey taught me something unexpected. The most important outcome was not the book. It was the reminder of what truly matters. Time with family. Time with friends. Being present with the people you choose to surround yourself with. Writing forced me to be intentional about how I used my time, and in doing so, it clarified my priorities.

The goal of this book was never just to publish. It was to create awareness in OT security by breaking down complex topics and making them practical. To give people something they could actually use. Tools, frameworks, and ways of thinking that help organizations build resilience, not just react to incidents. Disruptions will happen. Cyber incidents, system failures, and operational adversity are inevitable. The question is not if, but when. Being ready is the entire point.

That readiness is the theme of this book.

Writing is liberating because it allows you to put clarity where there was once noise. It forces you to organize thoughts, stand behind them, and let them exist independently of you. Once they are written, they are no longer just ideas in your head. They become something others can engage with, challenge, or build upon.

If someone else is considering writing a book, I hope there is something in this journey that helps. And if not, they will find their own path. Either way, writing is worth it. If you have ideas you feel compelled to share, writing is one of the most honest ways to do so.