The Feedback That Made Me Question Everything I Knew About Being a Good Engineer
10 years, two countries, one blind spot
Three months into my first Dutch job, my manager told me I needed to “improve my communication skills.”
I sat there confused. Communication skills? I’d just proposed implementing proper observability. I’d suggested refactoring that would make our codebase cleaner. I’d offered to improve our logging.
I was being a good engineer.
Wait.. What?
I came to the Netherlands with 5.5 years in Turkish tech. I knew how to build systems. I understood the why behind patterns, not just the how. I once wrote a whole article about implementing the State Machine pattern from scratch, not because someone asked me to, but because that’s what serious engineers do. We go deep.
In Turkish tech culture, engineering excellence isn’t a goal. It’s the goal.
You don’t ship half-ass solutions. You don’t compromise on code quality. At one company, we had two-day planning sessions. Two full days. Database schema. API contracts. Error handling strategies. Deployment approach. Everything mapped out before writing a single line of code.
And you know what? Even after two days, there were still things unclear during implementation. Because you can’t plan away all uncertainty.
But we tried. Because that’s what good engineers do.
This system creates something real: engineers who understand tradeoffs, who can explain why they chose one pattern over another, who care about craft. I’m proud I learned to think this way.
But here’s what nobody told me: I had confused engineering excellence with business value.
I didn’t see it until the Netherlands showed me.
When I proposed observability improvements to my Dutch team, they asked: “What problem are we solving?”
When I wanted to refactor for cleaner abstractions, they asked: “Is this blocking us from delivering?”
I thought they were being short-sighted. Careless about quality.
They weren’t.
They were asking a question I’d never learned to ask: Why does this matter right now?
Dutch tech culture cares about quality. But they filter everything through a different lens:
Business impact over technical elegance. Fast user feedback over perfect first version. “Does it fit the requirements?” over “Is it flawless?”
The planning sessions here? High-level system design. How it connects to requirements. Implementation details? Up to the developer.
That’s it. No two-day deep dive.
At first, this felt sloppy. Underprepared. How can you make good decisions without thinking through every detail?
But it’s not sloppiness. It’s a different bet on where uncertainty lives.
The Dutch approach says: we can’t plan away uncertainty, so let’s not pretend we can. Design the structure, trust engineers to solve problems as they emerge.
The Turkish approach says: we can minimize uncertainty through thorough planning. Think through everything upfront.
Same fundamental truth. Different timing on where to place your bets.
There’s something else I noticed that goes beyond philosophy. It’s structural.
In the Netherlands, when I proposed a feature, the first question wasn’t “Is the architecture clean?” It was “How does this handle user data deletion requests?”
GDPR isn’t a nice-to-have here. It’s foundational. You design with compliance from day one. Privacy by design isn’t a buzzword, it’s baked into every technical decision because the regulatory environment requires it.
In Turkey, we were less rigorous about this. Not because we were careless or didn’t care about users. The regulatory environment was different. Less enforced. Less immediate.
This reshapes how engineers think about architecture from the start. When Dutch engineers ask “does this meet requirements?”, those requirements include regulatory compliance in a way Turkish requirements often didn’t.
It’s not that one culture cares more about doing the right thing. The definition of “right thing” is shaped by different constraints.
So that feedback about communication skills. I think I finally get it.
I was walking into meetings with solutions. Technical solutions. “Here’s what we should do because it’s technically better.”
But I wasn’t asking what mattered in that business context:
What problem are we actually trying to solve? What’s the business impact? What do we need to learn? Is this even the right problem to solve right now?
I was performing “good Turkish engineer”: deeply technical, focused on excellence, ready to build the right thing.
The context needed “good Dutch pragmatist”: business-aware, outcome-focused, willing to ship imperfect solutions to learn faster.
Neither was wrong. I was just in the wrong mode.
And nobody told me directly because... how do you explain to someone that their entire framework for what “good engineering” means is contextual?
I’m 10 years into my career now. Almost exactly split between these two cultures.
And I can’t fully be either anymore.
But I know this now: the real skill isn’t mastering one approach. It’s learning how to be adaptable. Recognizing which context you’re in. Seeing tradeoffs both sides make, even when they can’t see them themselves.
Being caught between two worlds is uncomfortable.
But at least now I can see the blind spot.
What’s your experience working across different tech cultures? I’d love to hear if you’ve noticed similar patterns or completely different ones.