What 20+ Years in IT Taught Me About Technology Leadership

What 20+ Years in IT Taught Me About Technology Leadership

The lessons I learned from solving problems, making difficult decisions, and growing with technology

Nobody ever tells you the moment your job stops being about technology.

For me, it happened at 4 pm on an ordinary afternoon, standing in a server room, watching water drip onto a rack I was supposed to be protecting.

I didn't know it yet, but that moment — and a handful of others like it over the next twenty years — would end up teaching me more about leadership than any certification, framework, or promotion ever did. Not because the incidents themselves were extraordinary. Because of what they forced me to decide, in seconds, with no manual to consult and nobody above me ready to make the call first.

This is the story of a few of those moments, and what they taught me about the difference between fixing technology and leading through it.

It was 2008, during a major festival week. Around 4 pm.

My manager called me, asking for remote access to a particular server. He couldn't connect. Nothing unusual — happens all the time. I walked into the server room to check what was going on.

And I froze for a second.

Water. Pooling on top of the server. The machine was already down.

I looked up. It was dripping steadily from the ceiling — not a drop here and there, a real leak, and it was getting worse by the second.

I called my manager. "Sir, there's water coming through the roof. We need to power everything down now, before it spreads to the other racks."

He paused. Thinking it through. Weighing the decision.

I didn't have that kind of time.

"Sir, we don't have time. The water is increasing."

I made the call myself. Power down. And I didn't stop at the manager — I called the maintenance team too, telling them to shut off the water inlet at the source, so the leak itself would stop while I dealt with what was already coming through the ceiling.

Then I ran. Outside the server room, the floor was mid-renovation — freshly polished wood, carefully wrapped in plastic sheeting to protect it. I tore that plastic straight off the floor and threw it over the server racks instead, trying to keep the water out.

I could have waited. Waited for my manager to arrive, waited for someone senior to make the "official" call, waited for the process to catch up with the emergency. That would have been the safe thing to do.

But in that moment, it wasn't just about the servers anymore. It was about the hotel — every guest, every check-in, every system that depended on those machines staying alive.

Later, I found out what had happened. A guest checking out had left a tap running. The room flooded. The floor above the server room gave way, and the water came straight down onto our infrastructure.

Two servers were damaged that day. I stayed the entire night — not because my job description said so, but because somewhere between the plastic sheeting and the power switch, it had stopped being my job and started being our problem.

I want to tell you that story first, before anything else, because it's the truest thing I know about technology leadership.

It was never really about the technology.

Making Things Work Was Never the Real Job

When I started my career in IT, I thought success meant exactly that — making things work.

If a server was running, if a system was available, if a technical problem was solved, I felt like I'd done my job. And there is a real satisfaction in that. You wrestle with something for hours. You try one thing, then another. You fail. You search. You finally crack it.

The problem is solved.

You feel relieved. Sometimes even proud.

But more than twenty years in, I've come to understand that "making technology work" was only ever half the job. The real question was always bigger than that:

What difference did it make?

Did it help someone do their work better? Did it reduce risk for the business? Did it make somebody's impossibly difficult day just a little bit easier?

That night at the hotel, the technical answer was simple — power down, contain the water, protect the hardware. But the reason I stayed until morning had nothing to do with hardware. It had to do with guests who needed to check in. A front desk that needed its systems back. People whose day I could make easier, or a lot worse, depending on what I chose to do next.

That's the shift nobody tells you about when you're starting out. And it's still, honestly, a work in progress for me.

I Used to Think Leadership Meant Having Every Answer

Early in my career, technical knowledge was my confidence. The more I knew, the safer I felt. I wanted to be the person who could solve the problem — any problem, put in front of me, on the spot.

That mindset took me far. It also nearly wore me out, because the higher I climbed, the more I realized something uncomfortable:

I would never know everything. There would always be a new technology, a new failure mode, a new 4 pm phone call I hadn't planned for.

At first, that felt like a weakness I needed to hide. People look to you for direction — surely you're supposed to have the answer ready?

But I've learned that leadership was never about knowing everything. It's about knowing what matters right now, asking the right question, and being willing to make the call even when you're not 100% sure.

Standing in that server room, I didn't know exactly how bad the leak would get. I didn't know if powering down was the "textbook correct" move or an overreaction. I just knew that waiting was riskier than acting.

Sometimes leadership sounds like: "I need more information." Sometimes it sounds like: "I don't know yet, but I'll find out." And sometimes — like that afternoon — it sounds like: "Sir, we don't have time."

I've learned that saying any of these doesn't make you weak. It makes you honest. And honesty, more than certainty, is what actually earns trust.

I remember this most clearly from a mobile app deployment I was pulled into. My actual expertise was infrastructure — that was my world, and I knew it well. Mobile app development, the release pipeline, the coordination between our in-house app team and the external developers — that was not my world. I was there mainly for the infra side.

Then, in the middle of development, the project coordinator left.

The timing made it worse. Only the wireframes had been finalized at that point — nothing else was locked down. And the hardest part of this particular project was never really the wireframes. It was the handshaking between our in-house developers and the vendor's mobile developers — two teams, two codebases, two sets of assumptions, that needed to integrate cleanly with each other. That's exactly the kind of thing a coordinator exists to hold together. And now there wasn't one.

I didn't know the mobile stack the way the coordinator had. I didn't know the vendor team's release quirks, their sprint rhythms, half of their vocabulary in the early days. What I did know was how to ask the right question to the right person, how to keep the in-house team and the vendor team talking to each other instead of past each other at exactly the point — the handshake — where projects like this usually start quietly falling apart.

So I stepped in.

Not because I suddenly became an expert in mobile development. I didn't. But leadership, I was reminded again, was never really about knowing every layer of the stack. It was about making sure the handshake between two teams who didn't report to each other, and didn't fully trust each other's process yet, actually held — especially with only a wireframe standing between us and the rest of the build.

Every Technical Decision Has a Business Heartbeat

Here's something that took me years to internalize: a technology decision almost never stays inside the IT department. It ripples outward.

A decision about infrastructure touches productivity. A decision about cybersecurity touches trust. A decision about uptime touches whether a hotel full of guests can check in on time.

That night, powering down the servers wasn't a purely technical decision — it disrupted check-ins, check-outs, the entire hotel's operations for hours. I knew that when I made the call. I made it anyway, because the alternative — losing the servers entirely — would have cost far more.

That's the tension technology leaders live in constantly: the technically "best" option and the right option for the business, right now, are not always the same thing. Sometimes the right decision is the harder one. Sometimes it's the one that causes short-term pain to prevent long-term disaster.

Leadership isn't only about approving the exciting new idea. It's also about having the judgment — and the nerve — to make the unpopular call when the moment demands it.

I think about a much quieter incident too, in 2018. Cloud adoption was still relatively new for our organization back then — we'd moved critical workloads to a major cloud provider, but hadn't yet been through a real crisis on it. Our cloud server crashed in the middle of the night — a hardware failure, 4 am, no warning. Nothing dramatic like fire or flooding. Just a dead server and a business waiting on it.

What made it work was that nobody tried to be a hero alone this time. We got on a call with the provider's support team immediately, and stayed on it — our team and theirs, working the problem together, hour after hour. By 1 pm, the service was fully restored.

A few days later, our MD called the entire office together. He walked up to me and handed me his own smartwatch — off his wrist — as a thank you.

I still don't wear it much. I keep it more as a reminder. Not because the recovery was technically impressive — plenty of recoveries are — but because it was the clearest proof I'd had up to that point that when a business trusts you to hold its most critical infrastructure, and you come through, it notices. Quietly, sometimes. But it notices.

People Are Never Just Components in the System

Systems can be replaced. Servers can be swapped out. Code can be rewritten.

People can't be treated the same way.

Our server room was on the 14th floor. The fire started on the 6th.

I got the call from a teammate first: "The building's on fire, we're all evacuating to a safe distance." That was the first thing I heard that morning. Everyone getting out safely — that mattered more than anything else, and it happened.

But almost immediately, another thought started tugging at me. Our servers were on the 14th floor, serving ten diagnostic centers across the city. None of those centers had a single server anywhere near that burning building — but every one of them depended on ours to function. The moment our servers went down, so did their reception desks, their billing, their ability to run lab tests or release a single report. Real patients, at real centers, waiting on results that suddenly couldn't be generated or delivered.

The fire brigade was already on site, using water cannons and extinguishers on the lower floors. I got on a call with my manager and our MD. My one request: we needed to power down the servers immediately, before a short circuit turned an electrical fire into a server-room fire.

I remoted in and shut the servers down, one by one, from wherever I was.

By the time I reached the building — around 11:30 — the fire was under control, but every floor was thick with smoke. Multiple companies from the building were standing outside, waiting. I climbed all fourteen flights of stairs with my colleagues, because the lifts were obviously down, and found what I expected: the power source had been disconnected because of the fire.

Now the real problem started. How do we bring the servers back online with no power?

We needed a generator. And somehow — I still think about this — my colleagues and directors agreed, without much debate, to physically lift a generator from the ground floor and carry it up fourteen flights of stairs on their shoulders.

That is, without exaggeration, the best example of teamwork I have seen in my career. Nobody was assigned this. Everybody just showed up for it.

The generator we carried up wasn't powerful enough to run everything. So we called a DG (diesel generator) vendor. Even they hesitated to run cable all the way up to the 14th floor. One of our directors picked up the cable himself and started carrying it up, alongside whoever else was willing.

By around 4 pm, we were back online. Of all the companies in that building, ours was the one that got its servers running again that day — on a borrowed, hand-carried generator and a cable dragged up fourteen floors by people who had no obligation to do any of it.

I've seen technically excellent environments struggle badly — not because the tools were wrong, but because the people running them were overloaded, unclear on priorities, or too afraid to say "something's wrong" out loud. What I saw that day was the opposite. Everyone understood, without being told twice, what the moment needed from them — because they knew what was actually at stake: ten centers full of patients waiting on tests and reports, depending on systems they'd never see, staying up.

As a leader now, I try to build that same understanding in my team, before the crisis, not during it. People need to know what's expected of them, why their work actually matters, and that when something goes wrong, they can say so honestly — without fear. That's what makes a team carry a generator up fourteen floors without being asked twice.

Listening, I've learned, is just as much a leadership skill as directing.

Reliability Isn't a Topic for Audit Day

In technology, the best work is often invisible. Nobody notices the server room until the server room floods.

That incident taught me — more than any framework or certification ever could — that security and reliability can't be treated as checklist items you revisit once a quarter. They have to live in how you think, every single day.

What exactly are we protecting? What happens the moment this fails? How fast can we actually recover — not on paper, but for real?

There's no environment with zero risk. There never will be. But there's a world of difference between knowingly accepting a risk and simply not seeing it coming until it's dripping onto your servers.

Good leadership means understanding the risk, naming it clearly, and being ready to act — sometimes in seconds, not committee meetings.

I learned this lesson again, in a completely different setting, during a major lab accreditation audit — the kind of review that goes deep into a lab's systems, not just its processes. Our Chief IT Consultant, who would normally have faced the auditors on anything related to our lab information systems, wasn't available that day. Management turned to me instead.

It wasn't my usual seat to sit in. I wasn't the one who typically explained our uptime guarantees, our backup and recovery process, our access controls, to an external auditor going line by line. But reliability, I realized standing in that room, isn't something you can only speak to when you're the most senior person in the building. If you've actually built the discipline into how you work every day — knowing what you're protecting, knowing how fast you can recover, knowing who's responsible for what — you can explain it to anyone, on short notice, without a script.

It was uncomfortable. But it confirmed something I'd already started to believe: reliability isn't a document you produce for an audit. It's a way of operating that should hold up even when the person who usually presents it isn't in the room.

The Higher You Climb, the More the Job Changes

This is something I'm still working through, honestly.

I didn't start anywhere close to a leadership seat. My career began as a Support Executive at a systems integrator — ticket queues, break-fix work, learning infrastructure from the ground up. From there I moved into an MNC, then into an Assistant Manager role at another company, got promoted to Manager within that same organization, and today I sit as a Senior Manager, responsible for an IT budget of over ₹6 crore.

I mention the actual path — not the title, the path — because each step changed the questions I was expected to answer. As a Support Executive, the question was simply: is it fixed? As Assistant Manager and then Manager, it became: is the team delivering, and is the system reliable? Now, holding a budget that size, the question is closer to: where should this money actually go, and what are we willing to say no to?

Early in a technology career, the focus is solving the problem in front of you. Then it becomes delivering projects, running teams, managing risk. At a more senior level, the questions get bigger:

Where should we invest? What should we stop doing? How does technology actually move the business forward — not just keep it running?

I don't have all the answers to these questions. I don't think a title ever automatically gives anyone all the answers. But I've come to believe that growing into that kind of thinking takes more than technical skill. It takes business understanding, financial awareness, emotional maturity, and — every so often — the willingness to make a fast, unpopular, correct decision with a manager still deciding whether to green-light it.

What Stayed With Me

I still think about that night sometimes.

The smell of wet server room air. The sound of the water hitting metal. The plastic sheeting crinkling in my hands as I wrapped it around a rack that wasn't mine to protect according to any job description — but was absolutely mine to protect in every way that actually mattered.

My job was to take care of the servers. That's what I was hired to do. But somewhere in those hours, I stopped protecting equipment and started protecting a commitment — to the guests checking in the next morning, to my team, to a hotel that needed its systems back before sunrise.

That's the difference experience has taught me to see.

Earlier in my career, I asked: Why isn't this working? Now I ask: Why are we doing this in the first place?

Earlier, success meant the task was done. Now, success means I actually understand who it helped, and what it cost.

I still enjoy solving a hard problem at 2 am. That part of me hasn't changed, and I hope it never does. But experience has taught me to pause a little longer before reacting, to listen a little harder before deciding, and to remember that the most impressive technical solution isn't always the right one.

Sometimes the most important decision isn't what to build next.

It's what to stop doing, what to protect right now, and whose job it quietly becomes to stay until the water stops.

Why I Started Writing This Down

I've spent more than two decades in technology — learning through wins, mistakes, pressure, 4 pm phone calls I never saw coming, and decisions I still think about years later.

Some lessons came from solving problems. Some came from the people I worked with. Some came from standing in a flooding server room, deciding I couldn't wait for permission.

I wanted a place to share those lessons honestly — not as someone who has it all figured out, but as someone still figuring it out in real time.

That's why this space exists.

It's not a place where I pretend to have every answer. It's where I share what I've learned, what I'm still learning, and how I think about technology, leadership, AI, cloud, cybersecurity, automation, and digital transformation.

Maybe something here helps an IT professional rethink their next career step. Maybe it helps a manager explain a hard call to senior leadership. Maybe it just reminds someone, at 4 pm on an ordinary Tuesday, that they don't have to figure it all out alone.

After 20+ years in IT, I've learned that leadership was never about knowing everything.

It's about staying until the water stops.

And this — this is just the beginning.