Minura Kariyawasam

Work

I'm part of a specialized sales engineering team at WSO2 that handles the complex evaluations. The ones where the customer runs five vendors, the requirements span multiple business units, and the goalposts move mid-engagement.

Most SEs go deep on one product. I work across the full WSO2 stack and just as well across whatever the customer already has: AWS, Azure, Okta, Kafka, legacy middleware, competing gateways. The proof has to work in their actual environment, not a clean demo setup.

I come in, understand the environment fast, and build something real. Then I have an honest conversation about what fits and what doesn't. That last part is rarer than it sounds.

How I think

Technical problems and people problems are the same problem.

When a prospect pushes back on token expiry, they're also asking whether their team can actually manage the config day-to-day. When they ask about rate-limiting, there's usually a question underneath it about ownership and accountability. The surface question and the real question are almost never the same thing.

I pay attention to both layers simultaneously. What the architecture actually needs. What the team can realistically operate. What the executive is worried about but won't say in front of their engineers.

Most people in this role read one of those at a time. Reading all of them together changes what you build and how you present it. It's why I can walk into an unfamiliar environment, spend twenty minutes listening, and build something that answers questions the customer hadn't fully articulated yet.

What I've learned

I once built a PoC that worked perfectly. Thorough, technically sound, covered everything. It also exposed a gap in the customer's own architecture that they hadn't seen before.

The demo was a success. The deal stalled. They spent the next two weeks questioning their own readiness instead of evaluating the product.

The job isn't to prove you're technically capable. Customers assume that. The job is to give them confidence that they can succeed with what you're showing them. Those are two different goals and they sometimes point in opposite directions.

I build proofs that move deals forward, not ones that create new problems for the room to solve.

What I won't do

I won't run an evaluation where the outcome is already decided. If the customer has made up their mind and just needs a vendor to go through the motions, that's not a use of anyone's time.

I won't scope out the hard parts. If a customer's real environment includes a competitor's identity provider and a fifteen-year-old message bus, the proof needs to include them. Pretending they don't exist just delays the real conversation.

I won't close a deal I can't stand behind. If I can't look the implementation team in the eye after the contract is signed, I sold the wrong thing.

Background

Writing

I write about engineering, systems thinking, and the gap between how software gets designed and how it actually gets used in production.

Research

Published work on monitoring multi-tenant cloud environments, covering performance isolation, scalability, and real-time analysis in distributed systems.

Deep technical knowledge, production experience, and the ability to build trust in a room full of skeptics.

That combination is rarer than it should be.