"The universe is not made of atoms. It is made of stories." — Muriel Rukeyser

I've always believed the same is true of systems. A problem statement is a story. A requirements document, a gap analysis, an architecture decision record — all stories, told with varying degrees of precision. My job, in every room I've been in, is to find the story underneath the system. That's what makes a design defensible, a workshop land, a complex idea legible to the person who has to act on it.

I started in technical support, troubleshooting hardware and software issues for enterprise customers, writing the knowledge base articles that should have existed before I needed them. From there into technical writing — documenting product suites for IBM Emptoris and Avaya, learning that the gap between what a system does and what a person understands it to do is where most real failures live.

That observation became a career. At Apttus, I moved from writing documentation to designing and delivering the training itself — twenty-plus end-to-end programmes across CPQ, CLM, Billing, and Incentive Management, for 1,000+ participants across five countries. Not generic curriculum: a scaffolded model built from a live bank of real-world use cases, iterated continuously against what Directors and Senior Managers actually called "job-ready." The result was participants who were production-ready from day one, not participants who had merely completed a course.

Deployed to the World Economic Forum in Geneva as Solution Architect, I learned what it means to bridge technical design and human enablement in one of the most complex stakeholder environments there is — translating architecture into adoption for teams who did not build the system and had to trust it anyway.

Since then, that same instinct — design the system, then close the gap between the system and the people who run it — has moved with me into enterprise AI architecture. TOGAF, Google Cloud, machine learning engineering: the credentials changed, the question underneath them did not. Can this survive an audit. Can this be defended in front of a compliance board. Can the team that didn't build it sustain it without me in the room.

Two ventures of my own — Ekada and Data Domine — gave me the other side of that question: what it costs to build the thing yourself, fund it yourself, and decide, with founder's judgement, when to wind one down and start the next. Data Domine continues today as a technical practitioner education company, applying the same production-ready discipline to the next generation of architects and ML engineers.

I design enterprise AI and Quote-to-Cash systems for regulated industries. I am at my best in the room where a technically correct answer and a defensible one are not yet the same thing — closing that distance is the work.

info@raosiddharth.com