Optimize teams before code
A stronger architecture does not help if the team lacks clarity, ownership, and review discipline. I start by improving how engineers decide, collaborate, and deliver.
Evidence: 2 related achievements
Engineering leadership
Leadership Principles
Practical operating principles for building teams, improving engineering systems, and keeping technical decisions connected to business outcomes.
Looking for an Engineering Manager in the Netherlands? This focused profile explains how my résumé maps to engineering leadership roles.
Developer experience is a product
Internal delivery systems deserve product thinking. Preview environments, release automation, and quality gates should make good engineering behavior easier to repeat.
Evidence: 2 related achievements
Clarity creates ownership
Engineers take ownership when expectations, context, trade-offs, and decision rights are visible. Ambiguity should be resolved early, not hidden inside implementation work.
Evidence: 2 related achievements
Measure before optimizing
Performance and delivery improvements should start from evidence. Benchmarks, hotfix rates, pipeline timing, and review data make priorities easier to defend.
Evidence: 3 related achievements
Architecture should enable delivery
Technical decisions should reduce product risk and improve team flow. The best architecture creates safer paths for change instead of becoming a separate goal.
Evidence: 2 related achievements
Technical decisions should support business outcomes
Engineering strategy needs a business reason. Release systems, migration plans, AI workflows, and platform practices should connect back to reliability, speed, quality, or growth.
Evidence: 2 related achievements
How I Lead
Short explanations of the leadership behaviors behind the board: ownership, mentoring, collaboration, technical debt, discussions, and quality.
How I create ownership
I make outcomes, constraints, and decision boundaries explicit so engineers can own work without waiting for constant direction.
How I mentor engineers
I use reviews, growth plans, demos, and technical discussions to help engineers improve judgment, communication, and delivery habits.
How I work with Product and Design
I translate technical constraints into product choices and keep engineering decisions connected to customer, delivery, and business priorities.
How I approach technical debt
I treat debt as owned product risk: measure the friction, explain the trade-off, and improve the system without blocking delivery unnecessarily.
How I run technical discussions
I keep discussions grounded in options, constraints, reversible choices, and the operational cost of each path.
How I balance delivery and quality
I prefer quality systems that protect momentum: release automation, feature flags, testing standards, and review practices that catch risk before production.