Field notes on technology adoption

Technology rarely fails on capability. It fails in interpretation.

The system you deployed may have failed six months earlier, in a meeting. Field notes from someone who has built enterprise systems and sold them, on the handover no one owns.

Read the notes Get in touch
Portrait of Barun Verma
Barun Verma Engineer → Business development
The thesis

The failures I have seen up close were rarely technical.

I spent nearly two years developing enterprise systems and two and a half years selling them. The technology usually worked. What failed was the transfer of responsibility from developers to users. No one clearly owns that transition. This website is about closing that gap, so people adopt technology by choice rather than under pressure.

I worked as a systems engineer at Infosys before moving into business development for an IT services and consulting company. From both sides, the recurring problem is an interface failure: a working system meets an organization that has no plan to absorb it. I document those failure modes here.

The Read as switch makes the same argument in different words. That translation is the shortest description of my job.
The story

I once thought working software was the finish line.

I joined Infosys as a systems engineer believing that if you built a system well, people would use it. One project changed my mind. It passed every test and met every specification, yet a few months after deployment it was barely being used. The client’s employees had quietly returned to their spreadsheets. Nobody complained, which was somehow the worst part.

A bug can be identified and fixed. This was a different kind of failure, and it did not appear in any log we had.

So I changed paths. For the last two and a half years, I have worked in business development at an IT services and consulting company, sitting in the meetings where adoption is actually decided. The suspicion I had as an engineer turned out to be right, only larger: the scarce skill is neither building technology nor selling it. It is carrying the idea intact between the people who build it and the people who must live with 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.
Field notes

Notes, not a feed.

Each note is one claim I’d argue in front of a hostile room. The date is the last revision, not the first publish — a note I can’t stand behind gets fixed, not archived.

001Rev. Jun 2026 · 6 min
The Last Meeting Is Where Adoption Dies

The deal that taught me this stalled for five months after a flawless demo. What killed it happened in a meeting I was never going to be invited to.

Read the note →
002Rev. May 2026 · 6 min
What the Engineer in the Room Knows

I used to be the quiet engineer at the end of the table, the one the vendor never looked at. One sentence from me after the meeting could kill a deal.

Read the note →
003Rev. Jun 2026 · 7 min
The Ten-Year Test

Four questions I run before taking a technology trend seriously. Most things pass the first one and fail the second.

Read the note →
004Rev. Aug 2026 · 7 min
A System’s Best Feature Can Be Someone’s Worst Incentive

A useful feature may still remove control, status, discretion, or earning power. Adoption plans should map those losses as carefully as benefits.

Read the note →
Two doors

If any of this held your attention, say so.

No form, no calendar link — just email, and two suggested openers depending on which kind of reader you are. I read all of it myself.

For decision-makers
“I’m weighing a technology decision and want a straight read.”

Describe it the way you’d describe it to a colleague, not the way a vendor would. Translating it is my job.
For builders
“I build things and want to compare notes.”

You don’t have to agree with anything here. “Note 003 is wrong and here’s why” is my favourite kind of email.

barunverma01@gmail.com — it goes to a person, not a pipeline.