Engineering Approach
Technology should serve people
During my years as IT Manager at Keppel FELS Baltech, I developed an approach built around a simple principle: IT exists to support the people doing the actual work, not the other way around.
Long before DevOps became widely recognized, collaboration, automation, continuous improvement, and direct user feedback were already central to how I organized our IT activities.
Rather than waiting for formal requests, I observed engineering workflows and discussed everyday challenges with ship designers. This often revealed opportunities to simplify or automate time-consuming tasks — sometimes without the engineers themselves realizing that improvement was possible.
Other ideas came directly from colleagues. In every case, the starting point was the same: understanding the actual problem and defining a meaningful outcome.
Prove the value before scaling
Before implementing a change, we evaluated its expected benefits, technical risks, required resources, and impact on existing workflows — including people's natural resistance to change.
Instead of introducing changes everywhere, we typically started with one or two workstations. We observed the results, worked directly with the engineers, listened to their feedback, and refined the solution.
Only when an improvement demonstrated its practical value did we extend it to the broader engineering environment.
Working with consistently limited budgets reinforced another principle that became part of our departmental philosophy:
"We do more with less."
For us, this was not about compromising quality. It meant making better use of available resources, eliminating unnecessary work, and finding effective solutions without assuming that every problem required additional spending.
I start from the future
When approaching a new project, I usually begin by imagining its completed state.
What should the final solution look like? What should it accomplish? How will people interact with it? What would make it intuitive, reliable, safe, and efficient?
Once that future state becomes clear, I start working backwards.
I identify the capabilities required to achieve it, the critical milestones, the dependencies between them, and the obstacles that can already be anticipated.
Moving backwards from the intended result towards the present helps me establish the essential architecture, functionality, and key decisions before committing to implementation.
Only then comes a deeper critical analysis.
Research, challenge, create
I research existing solutions, examine established industry practices, study how large organizations approach similar challenges, and evaluate relevant technologies and architectural alternatives. Today, discussions with AI have also become part of this process.
But researching existing solutions does not mean copying them.
I use that knowledge to challenge my assumptions, reconsider the design, and develop an approach suited to the actual requirements — with the ambition to improve upon existing solutions whenever there is a meaningful opportunity.
The result is a conceptual implementation plan based not only on established practices, but also on independent reasoning and practical experience.
For me, engineering is not simply about implementing technology correctly.