Dennis
Van Beersel

Born and raised in Belgium, I migrated to Denmark in 2008 - I consider myself to be an IT geek that is obsessed with "understanding how things work". A fine quality for this field of work.

The first code I got paid for shipped in 2003. Since then the work has grown from writing code to leading the teams that write it, and I've stayed hands-on the whole way.

The last six years were at Maturix: construction IoT, concrete sensors, and a Saint-Gobain acquisition in the middle. That chapter has its own sections further down.

Partway through I went part-time for a year to co-found MinRapport, a four-person company building for construction sites.

I also still run Styr På, a case-management platform for the Danish social sector and the successor to Effekt Plus, which I'd been building since 2011. It runs in maintenance mode next to everything else.

In my personal life I'm happily married to the wonderful Helena, "bonusfar" to Ema, father to Ellie, and proud co-owner of a Norwegian forest cat. What spare time is left goes to fishing on the Danish coast and hunting flea markets for old videogames, a hobby that eventually became a software project (see Side projects below).

I lead by example, and hands-on - but in my own little corner (usually backend systems, tools, libraries), not the parts I need the team to implement. Engineers need to own what they write, and if the work they hand off goes through two more rewrites by me or another team member, you get a massive disconnect - and it sets a bad example.

The team

There is a fixed structure too. Monday morning we kick off the week - what got done last week, what the plan is for this one, and everyone gets a say. Daily standups are short, and they exist mostly so I can spot early which engineers might be stuck or need help. The rest is an open door: I want people to feel safe raising their hand and asking for advice or a sparring session whenever something isn't clear, before they hit a barrier.

I don't believe in pushing tasks onto people. I present what needs to be done, we have a conversation about the right way to approach it, and I give my thoughts on how I think it should be implemented. I also make sure everyone knows enough about the bigger picture to understand how the task they're on today affects something from last month, or builds toward a feature planned two months out.

Team members who are well taken care of, professionally challenged and feel listened to become the highest performing engineers - which I have proven in practice.

The AI part

All of the softer stuff above leads directly into tickets, acceptance criteria, RFCs and ADRs. In spring 2025 I moved the team onto AI-assisted development with Claude Code, on MCP servers I wrote myself to connect it to everything we had written down. Our Scrum/Kanban tool became the team's context brain. You open a session and the context is already loaded, and a ticket can arrive as a draft PR. The engineer stays responsible for what they ship - also when the model wrote it.

The shift in engineering has been more towards 80% thinking and 20% implementation to reach a good result, instead of the pre-AI era where it was 20% thinking and 80% implementation - which is where my role fits best these days.