Field notes on technology adoption

Technology doesn’t fail on its merits. It fails in translation.

Your system didn’t fail in prod — it failed in a meeting, six months earlier. Field notes from someone who has built enterprise systems and sold them, on the handover nobody owns.

Portrait of Barun Verma
Barun Verma Engineer → Business development

The failures I’ve watched up close were almost never technical.

I spent almost two years building enterprise systems and the last two and a half selling them, and from both chairs I keep seeing the same thing: the technology is usually fine. What fails is the handover between the people who built it and the people who have to answer for it. Nobody owns that handover. This site is what I’ve learned about doing it properly — so companies adapt to technology because they chose to, not because they panicked.

I was a systems engineer at Infosys before I moved into business development — I’ve now sat through the worst meetings in enterprise IT from both ends of the table. What I keep seeing are interface failures: a working system meeting an org chart that had no plan for it. I keep notes on the failure modes. This is where I put them.

The Read as switch in the top bar rewrites the main claims for a different reader. Same argument, different vocabulary — it’s the most honest description of my actual job.

I used to think working software was the finish line.

I started at Infosys as a systems engineer believing that if you build the thing correctly, people will use it. One project cured me: a system that passed every test and met every requirement — and a few months after go-live, usage was close to nothing. The client’s staff had quietly gone back to their spreadsheets. Nobody had even complained, which was somehow the worst part.

A bug, you can fix. This was a different kind of failure, and it didn’t show up in any log we had.

So I switched sides. I’ve spent the last two and a half years in business development for an IT services and consulting firm, sitting in the meetings where these decisions actually get made and paid for. The suspicion I’d had as an engineer turned out to be true, just bigger than I thought: the rare skill in this industry isn’t building technology, and honestly it isn’t selling it either. It’s carrying an idea between those two groups without dropping it.

2022 – 2023
Systems Engineer, Infosys
Built and ran enterprise systems; learned what “done” doesn’t mean.
2023 – present
Business Development Executive
IT services & consulting — in the meetings where adoption actually gets decided.
Ongoing
Field notes
A small set of claims, revised when I turn out to be wrong.