The Engineer Behind the Systems

I do not think trust is earned by sounding impressive. It is earned when people can hand you a hard problem, walk away, and know you will bring back the truth, the trade-offs, and a system that behaves under pressure.

That is the engineer I have been trying to become since I was a child in Colombo, Sri Lanka.

The path from that small island to Oulu, Finland was not neat. It was built through old hardware, client deadlines, startup pressure, release pipelines, financial systems, language study, and a few decisions I would make differently now.

In 2006 my parents brought home a Pentium 3 machine with 128 MB of RAM, a 16 MB graphics card, and a heavy CRT monitor that made the desk creak.

It was not a powerful computer. That did not matter. To me it felt like a room with no walls.

I wanted to know why it froze, why the fan changed sound, why one program made the whole machine slow, and what happened after I pressed a key. I did not have a word for systems yet. I just kept asking what caused the machine to behave that way.

I spent my pocket money on children's electronics magazines and tried to build whatever I saw on the pages.

PCB boards, resistors, capacitors, LEDs, buzzers, and loose wires slowly took over my desk and then the floor around it.

My mother had one rule: do not break things that still work. I broke that rule more than I should have, usually because I wanted one part from inside an old device or one answer I could not get any other way.

At twelve I sat the Sun Certified Java Programmer exam because I wanted to test myself against something real. I learned early that curiosity is useful only when it survives frustration.

At university I studied computer science, but freelancing while studying taught me the lessons that stayed sharp. I used client work to help pay for tuition and expenses, and I often accepted work before I fully understood the path to delivery.

That confidence helped me grow, but it also cost me. On one project I underestimated the unknowns, waited too long to expose the risk, and had to recover under pressure. I delivered, but the experience stayed with me because delivery alone was not the standard I wanted.

What I would do differently now is simple: surface uncertainty earlier, split the work smaller, and make the risk visible before it becomes a deadline problem. That lesson is still in how I run engineering work today.

My first professional role was at SyLabs, a startup where there was very little distance between code, customer pressure, and consequence.

I worked on a production rental platform with real-time tracking, user management, authentication, RBAC, database performance work, and CI/CD automation. The stack included React, Node.js, PostgreSQL, Docker, Jenkins, and AWS, but the harder lesson was not the stack. It was learning how product behavior, data shape, access control, and deployment habits all affect whether users can trust the system.

In a small team, nobody gets to hide behind a narrow job description. Some days the best engineering decision was not the cleverest implementation, but the one the team could understand, ship, and support.

SyLabs changed my relationship with software. Code stopped being something I wrote to prove I could write it. It became something people were waiting on.

In 2021 I joined Zebra Technologies in Sri Lanka and started on SmartLens, an RFID-based system where software had to deal with physical-world messiness: devices, environments, timing, data, and people using the product in real operations.

Later I moved to a new department as the first DevOps engineer in the team. On a Tuesday I noticed a taped-up 17-step manual release checklist near the team area. There was no mature platform waiting for me, and around twenty five engineers were losing days to manual build and release work.

That was the moment DevOps became more than tooling for me. It was the practice of removing repeated pain from good engineers so they could spend more time solving product problems.

I designed and built the delivery flow from the ground up: cloud infrastructure, Jenkins pipelines, automated testing and reporting, artifact publishing to JFrog Artifactory, and deployment delivery to production.

The choice was practical: keep adding scripts that only I understood, or slow down and build a release path the team could run without me sitting beside them. I chose the second path. Reusable pipeline stages, clearer failure points, and visible reports mattered as much as the automation itself.

Release work that used to take three or four days of manual coordination became automated runs that finished in under two hours. More important, release day became less dramatic. The team could see what happened, where it failed, and how to recover.

At LSEG I worked with teams connected to London Stock Exchange, Turquoise products, and Millennium Surveillance systems.

That environment changed my tolerance for vague engineering. A change needed a reason. A deployment needed a rollback path. Access needed boundaries. Cost needed ownership. An incident needed facts before opinions.

Later, as a senior engineer in Millennium Surveillance's cloud team, I owned cloud cost governance, pipeline hardening, service upgrades, cloud migration, reliability improvements, and GitLab migration work. Some of that work was measurable: cloud governance reduced spend by 35%, around $75K per year, and reliability work cut downtime by 20%.

The lesson was not to become slow. It was to become deliberate. In financial infrastructure, good judgment means knowing when to automate, when to stop, when to ask for review, and when a small operational detail is actually a business risk.

What I would do differently now is document the pipeline decisions before touching the pipelines. During the GitLab migration, the runner configuration worked, but two engineers later told me they did not fully understand why it was shaped that way. That was a documentation gap, not a tooling problem.

In 2025 my wife and I moved to Oulu, Finland to build the next part of our lives.

Finland made progress quieter. I started learning Finnish from A1 toward A2, not because language study looks impressive on a profile, but because I want to participate properly in the country I chose. Some days that means grammar tables. Some days it means understanding one more sentence at the grocery store, in a classroom, or in a local conversation.

Oulu has given me specific memories that changed how this place feels: walking on the frozen sea at Nallikari, watching the sky refuse to get dark during Juhannus, cycling long summer roads toward Hailuoto and Kiiminki, and joining OYSTER Hack4Health, where our cross-functional team won Best Pitch for a wearable-based glucose prediction concept.

Starting again in a new country has made me more patient, more direct, and more aware of what it feels like to be new in a system. I think about that when I build platform workflows now. A new engineer should be able to make the first safe change without needing a private tour from the person who built it.

I am a DevOps and cloud reliability engineer who is strongest when the work sits between infrastructure, delivery systems, developer experience, and production responsibility.

The problems that pull me in are specific: CI/CD systems that teams actually trust, Kubernetes platforms with clear access boundaries, cloud environments where cost has an owner, observability that helps people decide instead of admire dashboards, incident processes that produce learning, and automation that removes toil without hiding risk.

My engineering philosophy is practical. Make the normal path obvious. Make failures visible. Prefer boring reliability over clever fragility. Document the decision, not just the command. Treat security, cost, and operability as design inputs from the beginning.

I want to work with teams that can move quickly without turning every release into a rescue mission. I do my best work where platform quality is understood as a business advantage and developer empathy is part of reliability.

If your team is building the kind of infrastructure where reliability, delivery speed, cost, and trust all have to live in the same room, I would like to talk.

Bring me a messy pipeline, a cloud platform that has outgrown its first design, a release process people fear, or a reliability problem that needs calm ownership.

I will bring curiosity, judgment, follow-through, and the habit that started with that old Pentium 3: look closely, understand the system, and leave it more trustworthy than I found it.