From Operations to Engineering — why domain knowledge matters

There's a persistent myth in tech that the best path to becoming a software engineer is a CS degree followed by grinding LeetCode problems. And sure, that works for some people.

But some of the most impactful software I've seen — and built — came from a different path entirely: starting in operations, understanding how businesses actually work, and then learning to build the tools that should already exist.

When I was managing contact center performance across Switzerland and Poland, I spent my days drowning in spreadsheets, manual reports, and enterprise tools that were designed for executives, not operators. Every day I thought: 'I could build something better.'

So I did.

The transition from operations to engineering wasn't easy. There's no bootcamp that teaches you Go concurrency patterns AND contact center workforce management. But that intersection — that's where the magic happens.

Domain experts who learn to code don't just build features. They build solutions that actually solve the right problems. They don't need a product manager to tell them what to build because they've lived the pain.

If you're in operations, customer service, logistics, finance, or any other 'non-technical' role and you're thinking about learning to code: do it. Your domain knowledge isn't baggage — it's your competitive advantage.

The tech industry has plenty of engineers who can build anything. What it lacks is engineers who know what's worth building.