Minura Kariyawasam
Senior Sales Engineer, WSO2
I think in systems, speak in trade-offs, and build proof that doesn't need a disclaimer.
There's a gap in most organizations that nobody names.
It sits between the engineer who can build it and the person who can sell it.
I live in that gap. Not because I picked a hybrid role, but because the way I think doesn't separate the two. I see a customer's architecture the same way I see a codebase: a system of constraints, dependencies, and hidden assumptions that will show up under load.
The rare part isn't the technical skill or the people skill. It's that they don't compete with each other. One feeds the other. That's not something you train into someone. It's how I'm wired.
Work
I'm part of a specialized cross-BU sales engineering team at WSO2 that handles the evaluations others can't scope. The ones where the customer's environment includes five different vendors, the success criteria span three business units, and the decision-maker changes halfway through.
Most SEs know one product deeply. I work across the full WSO2 portfolio and just as well across the competitor and third-party technologies the customer isn't replacing. That's what this team was built for.
That breadth is the reason I can stand in front of a prospect running a mixed stack, build a working proof across all of it in days, and have an honest conversation about what fits and what doesn't.
How I Think
I don't separate the technical problem from the human one. They're the same system. A prospect's objection about token expiry is also a question about whether they trust their own team to manage the config. A question about API rate-limiting is also a question about who owns what.
I think in layers. Not just protocol layers, but layers of concern. What the architecture needs. What the team can actually run. What the executive is worried about but won't say in front of their engineers. Most people read one of those layers at a time. I read them all at once, and I adjust what I build and how I present it based on all of them.
That's not a process. It's a habit of attention. And it's the reason I can walk into a room with no script, listen for twenty minutes, and build a proof that answers concerns the customer hadn't fully named yet.
Lesson I Carry
I once built a proof-of-concept so thorough that it exposed a gap the customer didn't know existed in their own architecture. The demo worked. But the conversation shifted from evaluation to damage control, and the deal stalled because we'd accidentally made them doubt their own readiness.
Most engineers would call that a success. I saw it as a misread. Technical depth without awareness of the room is a problem. The job isn't to prove you're the smartest person there. It's to make the customer feel able to succeed with what you're showing them.
Now I build proof that gives confidence, not proof that overwhelms. The line between the two is thin. Knowing where it is, that's the real skill.
What I Say No To
I say no to evaluations designed to confirm a decision that's already been made. If the outcome is already decided, the PoC is theater, and I don't do theater.
I say no to narrowing the technical scope to avoid hard questions. If the customer's real environment includes a competitor's identity provider and a legacy bus, the proof should include them. Not pretend they don't exist.
I say no to separating the sale from what comes after. If I can't look the delivery team in the eye once the deal closes, I built the wrong thing.
The willingness to say no in a sales cycle is itself rare. Most people are focused on the close. I'm focused on what happens after.
Focus
Hard PoCs
Multi-product, multi-vendor proof-of-concepts wired into whatever the customer actually runs: AWS, Azure, Kafka, Okta, competing gateways, legacy middleware. Built to survive the hardest question in the room, not the friendliest.
Build-to-Win
When the deal needs something the product doesn't have yet, I build it. A connector, an extension, a custom flow. Then I ship it as a PR upstream so the product gets better in the process.
Team Multiplier
Building reusable demos, SA tools, and evaluation setups that make the whole team faster. The best sign of individual skill is when it works even when you're not in the room.
Background
WSO2
2023–PresentSenior Sales Engineer
The team rotates R&D and CS specialists into engagements when needed, includes BU SA leads from every product line, and works through whatever channel fits: Slack, email, tickets, external chat. We set up live cloud environments on Choreo, Asgardeo, Bijira, and Devant so prospects evaluate against real conditions, not slides.
Before this, I was a Site Reliability Engineer, keeping production systems stable across cloud and on-prem. That's the part most people don't expect. I've run the systems I now sell. I've been paged at 2 AM for the infrastructure I now demo at 2 PM. Builder and operator, seller and engineer. That combination is the thing I haven't seen replicated.
Writing
I write about systems thinking, engineering careers, and the gap between how software is designed and how it is actually used.
Research
I've published applied research on monitoring multi-tenant cloud environments, focused on performance isolation, scalability, and real-time analysis in distributed systems.
Deep technical knowledge, competitor awareness, production experience, and the ability to build trust in a room full of skeptics. That's not a job description. It's a very specific kind of person.
I happen to be that person.