I want to understand why things behave the way they do. Curiosity, investigation, simplification and teaching. All threaded through everything I do.
Read my story
New York City
I'm a performance engineering specialist, test architect and technical leader living and working in the United Kingdom with IBM Consulting, on large government programmes.
But those titles only tell part of the story. I started with an Electronics and Telecommunication Engineering degree, then moved from India to Ireland for a Master's in Computer Science, then into software testing, and gradually into the area that would come to define my career.
Over roughly a decade, my work evolved from executing tests to designing the thinking behind them. From operating tools to questioning what a test is actually supposed to prove. From individual engineering to helping teams deliver outcomes.
And threaded alongside all of it: teaching. Mentoring engineers. Explaining the complex in human terms. Building courses. Creating PractoPerf. Helping others become confident enough to solve problems on their own.
My foundation was built before software took centre stage. The instinct to understand how systems behave, electrical, mechanical, logical, was already there.
More than a qualification. A new country, a new culture, a deeper computing foundation. The first of several deliberate transitions. I moved countries to pursue what genuinely interested me.
Software testing led me somewhere more interesting. Performance problems don't have simple yes/no answers. They require investigation, patience and the ability to connect evidence from across a system. A natural fit for the way I think.
The questions changed. From "how do we run this test?" to "what exactly are we trying to prove?" From executing to designing. From individual contribution to helping an entire team deliver something that actually answers the right question. I work across large UK government programmes where performance testing demands both technical depth and strategic thinking.
Technical leadership, delivery responsibility and an expanding interest in reliability engineering, AI and the future of quality engineering. Alongside all of it: building PractoPerf, teaching, mentoring engineers and exploring what performance engineering looks like next.
A system may work perfectly for ten users and completely differently for thousands. A response-time problem may appear in one component while the actual bottleneck lives elsewhere. A system may perform brilliantly for an hour and slowly deteriorate after ten.
These are the problems I find most interesting. The ones where I have to collect evidence, understand patterns and gradually narrow until the behaviour begins to make sense.
Something that appears healthy at hour one and quietly deteriorates by hour ten. Garbage collection patterns shifting. Thread pools slowly exhausting. Memory creeping. The signal is there, but only if you're looking at the right things.
The component that appears fine while quietly affecting everything around it. The dependency that reports healthy metrics while introducing latency into another path entirely. The problem that points one direction but lives somewhere else.
Real systems have real transaction mixes. Not every endpoint matters equally. Not every user does the same thing. Building a workload model that actually represents reality is a creative and analytical challenge, not just a configuration task.
Before asking "what does this result mean?", I ask "what could make this result wrong?" Test environment differences. Warm-up effects. Monitoring overhead. Timing artefacts. A clean result requires questioning the test itself.
I have a persistent discomfort with unnecessary repetitive effort. If I see engineers repeatedly doing the same manual thing, I start wondering whether the process itself can be improved.
I've redesigned performance testing frameworks so that test data, payloads, configuration and environment properties are separated cleanly. Not because it looks elegant, because it means the next test takes hours rather than days to prepare.
Complex multi-segment workload models. Endurance test reliability mechanisms. Automated configuration generation. Monitoring integrations that surface the right signals automatically rather than requiring anyone to check dashboards manually.
I'm exploring AI not for speed, but for intelligence, reducing the preparation overhead of performance testing so that engineers spend more time thinking about what results mean and less time constructing the infrastructure to produce them.
PractoPerf is my answer to a question I kept encountering: why do so many engineers know which buttons to press without understanding why they're pressing them?
Practical performance engineering education. Learning through real problems rather than memorising definitions. Courses, videos and material designed around the thinking, not just the tools.
The tool is not the skill. Knowing where a button lives inside JMeter is less valuable than understanding why you would press it in the first place.
Understanding scales. Procedures don't. When a system or tool changes, the person who understood the concept adapts. The person who memorised the steps doesn't.
Real problems, not invented exercises. The most useful learning happens when the problem is messy, incomplete and requires judgment, not when it has a clean pre-packaged answer.
Confidence comes from troubleshooting, not tutorials. The goal isn't engineers who can follow instructions, it's engineers who can navigate the unexpected.
My interest in AI isn't about generating code faster. It's about whether intelligence can be brought to the parts of engineering that are genuinely analytical, not just the parts that are mechanical.
Outside work, I'm considerably less interested in response times. I enjoy walking through unfamiliar streets, finding viewpoints, sitting in cafés, observing the ordinary atmosphere of somewhere new, and having enough space to simply think.
Not just famous landmarks. Unfamiliar streets. Architecture. Discovering cafés. Observing coastlines. Finding viewpoints. The ordinary atmosphere of somewhere new. Travel has also sometimes represented a completely new chapter for me, India to Ireland, Ireland to the UK. Movement as transformation.
Space to observe. Space to think. Space to disconnect. There's something about unhurried movement that suits me.
A way to relax that involves entirely different kinds of problems, and occasionally, entirely different kinds of satisfaction.
Stand-up comedy. Theatre. Music. Films. The kind of entertainment that reveals something about how people think as much as it entertains.
A quiet creative interest sitting almost completely outside engineering. I still enjoy cartoons, and I feel no particular obligation to have grown out of them.
A peaceful walk, a good café, music, a scenic place or simply enough space to think appeals to me far more than crowded or unnecessarily loud environments. That same quality carries into how I work with teams, sharing technical knowledge without making others feel inadequate, building confidence rather than diminishing it.
I'm at an interesting transition point. My foundation remains deeply technical performance engineering, investigation, architecture. Leadership and delivery are expanding the scope. But the curiosity that started everything? That isn't changing.
I want to remain close enough to technology that experimentation doesn't disappear. Close enough to problems that I still care about solving them. Close enough to people that teaching stays part of the work.