Principles

I’ve always believed that the “right way” is rarely the same as the “fast way” — and that the accumulated cost of choosing speed over quality eventually always catches up. Not as a philosophical position, but as a practical one: proper engineering, clear naming conventions, documented decisions, and clean architecture save far more time in the long run than the hours “saved” by cutting corners.

When a colleague once pushed to go live with a page that was missing key visual assets, I pushed back directly: “We should not go live with half-baked work, where at the end the quality of the whole page suffers.” When we took longer than expected to implement a change across the website, I explained why to leadership: “We got rid of technical debt and we are future-proof now. The work we do is also creative work which needs some room and time — it’s not just pushing a button.”

I wrote this to our CMO in a longer message about what the web team was actually trying to achieve: “Our main goal is that we deliver high quality, scalable and sustainable solutions. This helps us remain efficient in our small and high-performing team.” I meant every word.

Quality isn’t stubbornness. It’s investment. Building something scalable and maintainable takes more care upfront, but it’s what makes a small team actually sustainable over time.

Where this shows up: Engineering standards set from 2018 onward — branch naming, commit conventions, Git workflow — the go-live quality gate built for the team, the recurring push-back on pressure to launch incomplete work, and the consistent choice to fix root causes rather than visible symptoms.

The question I ask before almost any technical or process decision is: will this still work when the team is twice the size, the platform is ten times more complex, or the person who built it has left? If the answer is no, the design needs rethinking.

This shows up everywhere in how I work — from modular systems designed to be extended by anyone, to documentation that lets a stakeholder update the website without involving a developer, to processes that outlast their creator. When I joined Staffbase as the only web developer, I wrote knowledge bases for work I was doing by myself — because I always planned for a team. When that team eventually came, the foundations were already there. When I introduced a sprint framework, it wasn’t just for today’s team but structured to work as the team scaled.

Scaling isn’t only a technical concept. It applies to processes, documentation, and the way you hand things over.

Where this shows up: 336 Confluence pages authored across 8 years, the reusable module and template systems, the web team’s career track and operating model, the Storyblok editorial self-service setup that reduced dependency on developers, the Terraform infrastructure-as-code setup so the platform can be maintained by anyone who understands the pattern.

I believe that honest feedback, delivered with care, is one of the most valuable things a colleague can give. I’ve sent messages to managers, executives, and peers that were genuinely difficult to write — not because I enjoy conflict, but because staying silent felt like the worse choice.

I’ve raised communication problems to leadership, pushed back on decisions I thought were wrong, proposed systemic improvements to how recognition worked across the marketing organisation, and written frank messages about what wasn’t working — even when I wasn’t sure how they’d land. When I observed that @channel was being used in ways that disrupted everyone’s concentration, I said so directly: comparing it to someone “permanently shouting across an open office” and proposing specific alternatives. When I felt a colleague’s contribution had been overlooked in a public recognition moment, I asked the question that still feels right to me: “Why should we not praise everyone?”

The same principle applies technically. If I see a broken link, a brand inconsistency, or a process problem — even if it’s outside my domain — I raise it. Quality doesn’t respect org chart boundaries.

Where this shows up: Communication feedback to a senior manager about @channel norms, meeting facilitation proposals to leadership, a recognition-culture proposal to the CMO, frank messages about team structure and management, flagging a broken internal logo link in the product-design channel without being asked, raising brand inconsistencies on pages that weren’t mine.

Most problems I’ve encountered weren’t isolated incidents — they were symptoms of something structural. The antidote, every time, has been to step back and find the root cause rather than patching the visible thing and moving on.

But identifying a root cause isn’t enough — you have to communicate it in a way that people can act on. When I explained to a colleague in a completely different team why certain website templates were locked and couldn’t be freely edited, I didn’t just say “because policy.” I explained the history: “We are coming from a time where we had a mess because everyone was able to do everything — we had no control over the brand and what was in use.” When I introduced a quality gate for go-lives, I communicated not just the rule but the reasoning. When a bug was fixed, I closed the loop with screenshots and before-and-after evidence.

People follow standards more readily when they understand why those standards exist. And systems improve faster when people understand the root cause, not just the symptom.

Where this shows up: Every Jira card comment with visual evidence and plain-language explanation, the request intake system (a systematic solution to ad-hoc requests overwhelming the team), template and brand standards with documented rationale, the sprint framework introduced to fix unpredictable delivery, the Eisenhower Matrix shared with the team as a prioritisation tool.

There’s a meaningful difference between helping someone and enabling them. Doing a task for someone creates a dependency. Showing them how, documenting it, and giving them the tools and confidence to do it themselves creates capacity.

When a new developer joined a project, my message was clear: “Without enablement it will be very hard. Here are the resources to read first. Then we can have a call to address any questions.” I ran Storyblok editorial workshops so marketing colleagues could manage content independently. I wrote how-to guides from 2018 onward not because I had to, but because I knew someone else would need that knowledge sooner or later. When new colleagues joined the team, I invested real time in their onboarding, walked through implementations together, and treated it as a chance to build the team’s capacity, not just complete a checklist.

The goal is always to make yourself less of a single point of failure, and to leave the system stronger than you found it.

Where this shows up: The documentation library built from day one, Storyblok editorial workshops that enabled marketing self-publishing, the “How to prioritise tasks” shared with the team, onboarding treated as genuine investment, the career track built to help every IC understand their path and what “good” looked like at each level.

Eight years at a company going through funding rounds, acquisitions, restructures, leadership changes, and multiple technology migrations taught me one thing above all: nothing stays constant, and resistance is almost always more exhausting than adaptation.

“You learn to stop resisting the waves and start learning how to surf them.” I wrote that in my 8-year anniversary post at Staffbase because it genuinely describes how I’ve tried to operate. When my role changed and I returned from leading a team to deep individual contribution, I chose to treat it as a new chapter rather than a setback. When the platform migrated from a stack I knew well to one I was learning, I leaned in and helped the team navigate the transition. When AI started changing how developers work, I didn’t wait — I started using it daily, introduced GitHub Copilot guidelines tailored to our specific stack, and began thinking out loud about what “the shift from writing code to orchestrating it” means in practice. I introduced retrospectives to the team because the practice of reflecting and improving should be ongoing, not occasional.

Adaptability is a skill. It gets easier the more deliberately you practise it.

Where this shows up: Introducing retrospectives as a team practice (2024), learning Storyblok/Symfony/Twig alongside the team during the migration, writing AI guidelines tailored to the web stack rather than copying from elsewhere, treating the return to IC after three years of leadership as an opportunity rather than a demotion.

In every team I’ve been part of, I’ve found myself doing a kind of work that doesn’t show up cleanly in a Jira ticket or a pull request: spotting what’s about to fall through the cracks, connecting people who should be talking to each other, translating between technical and non-technical, and making sure the handover documentation is complete enough that someone else can pick up where I left off.

I once shared an article with my team about “glue work” — the invisible connective tissue that keeps a team functional — and recognised myself in it immediately. Not because I planned to be that person, but because it felt like the natural response to the situations I found myself in. Proactively flagging Storyblok AI credit overuse before it became a crisis. Writing the GTMKO recap so the team didn’t lose context. Sharing async-work practices at a company-wide meeting because I thought it could help everyone, not just my own team. Bringing a summary of the “Coder to Orchestrator” insight back from a 1:1 with the CTO and sharing it with the team that afternoon.

Glue work doesn’t always get attributed. Do it anyway — because the alternative is things falling apart quietly.

Where this shows up: Closing every loop with screenshots and explanations, sharing the async-work deck with the full marketing organisation, sharing knowledge org-wide after conferences, being the bridge between the web team and the product engineering AI community, vacation handover documents structured as operational runbooks rather than brief notes.

I’ve always believed that recognition, done well, is one of the most undervalued tools in any team. Not generic praise in a meeting — specific, named, public acknowledgment of what someone did and why it mattered.

I pushed back when colleagues were missed in recognition moments. I argued that there’s no meaningful cost to praising everyone — only a cost to leaving people out. I wrote farewell messages that referenced specific dinners and dates from years earlier, because I wanted the person to know they’d actually been seen. I made sure milestone birthdays were celebrated in the wider channel. I invested real time in a teammate’s visa process for a workshop not because it was efficient, but because it was the right thing to do and it mattered to him. I congratulated colleagues on engagements, anniversaries, and achievements — not as performance, but because I genuinely cared.

These aren’t extras. This is how I work. And it shows up not just in the warm moments, but in the hard ones too: when I felt that a colleague’s contribution had been overlooked, I said so, on record, to the person who could do something about it.

Where this shows up: A proposal to the CMO about improving recognition culture, supporting a teammate through a visa process for a workshop, celebrating colleagues’ milestones publicly, the consistent pattern across eight years that David Burnand described as “the little cultural things that make a difference.”

The principle isn’t “tell people what to do.” It’s “show people what good looks like.” The most effective thing a leader or senior team member can do is behave in the way they want the team to behave — not as performance, but as a genuine expression of their standards.

When I introduced engineering conventions, I followed them myself before asking anyone else to. When I preached async-first collaboration, I structured my own standups and updates to model it. When I wanted a culture of transparency and openness, I demonstrated it in my own communication — including the uncomfortable messages I sent when something was wrong.

David Burnand described it directly: “You’ve realised that you can be a leader to everyone just by how you show up: helping people and doing the little cultural things like your nice messages in Slack that make a difference.”

A direct report put it more plainly: “He doesn’t just talk the talk, but charges in the front lines leading by example.”

That’s the whole principle in one sentence. Hold yourself to the standards you set for others — first.

Where this shows up: Engineering standards followed before being codified for the team, async-work practices presented org-wide after already operating that way for years, closing every ticket with evidence and explanation (the behaviour expected from others), the Undercover Hero recognition for showing up consistently in ways that had nothing to do with a job title.

In my first month at Staffbase I went through every Unbounce landing page and removed duplicate tracking scripts, fixed broken links I happened to notice, and audited the GTM setup — before anyone asked me to. That wasn’t exceptional. That was just how I approached work from day one: if you see something that needs doing and you can do it, do it.

Proactiveness is different from being busy. It’s about having enough context and curiosity to see what’s coming before it arrives — and acting on it. Flagging Storyblok’s AI credits at 95.6% before they ran out. Drafting the Web Team Vision document before anyone commissioned it. Proposing improvements to the company’s recognition culture before anyone identified the problem. Preparing a conference business case before anyone asked whether to attend.

Waiting to be asked is a choice. I’ve tried to make the other choice the default.

Where this shows up: The GTM audit in month one (2018), flagging a broken internal logo link in the product-design channel without being asked (2020), proposing Lattice recognition improvements to the CMO (2023), the Web Team Vision document drafted independently (2025), flagging Storyblok AI credits at 95.6% and proposing a Gemini workaround before it became a crisis (2025).

I’ve never been good at hiding how I feel about something. I’ve come to see that not as a weakness but as the foundation of trust. When people know they’ll get an honest answer from you — even an uncomfortable one — they trust the comfortable answers too.

In November 2023 I published a comprehensive communication guide to the entire marketing department, co-authored with a colleague — spelling out explicitly what Slack was good for, what it wasn’t, how to use @channel responsibly, and how to structure posts so people could actually read them. “In case you made it that far, thanks for reading, you are our hero.” Practical, direct, self-aware — and shared publicly because I believed the whole team would benefit.

That’s the level of transparency I tried to bring to everything: not just the big conversations, but the small ones. The Jira card closed with a screenshot and a clear before-and-after. The feedback given in the 1:1, not the corridor. The difficult observation written in a message, followed up with a call. Nothing buried, nothing softened into uselessness.

Where this shows up: The Slack best practices guide published to the full marketing department (2023), direct messages to senior leaders about difficult topics, closing every Jira card with visual evidence and plain-language explanation, a direct report: “an atmosphere of openness, transparency, and growth.”

This one is personal. For years I navigated leadership that felt distant, misaligned, or disconnected from the reality of the work. I know what it feels like to not be seen, to have contributions overlooked, to receive feedback that’s technically correct but not actually useful.

When I had the chance to lead a team myself, I tried to lead in the opposite direction — the way I would have wanted to be led. Not perfectly, but intentionally. When a new team member joined in Vancouver, I flew there to onboard him in person, because showing up matters. When a colleague needed support navigating a visa process for a team workshop, I invested real time in it because his being there mattered. When growth conversations came around, I tried to make them genuinely honest — not corporate performance theatre.

When I finally experienced what genuinely good management felt and looked like, I wrote about it: “I feel seen, understood, and finally supported in the way I’ve always hoped for.” That sentence also describes exactly what I’d been trying to give my own team all along.

Where this shows up: Flying to Vancouver to onboard a new team member in person (2021), supporting a teammate’s visa process for the Berlin workshop (2023), creating the web development career track so every IC had a clear path (2022), a direct report: “An exceptional and inspirational leader — an atmosphere of openness, transparency, and growth.”

Written text is efficient for many things. It is a poor tool for resolving tension, clarifying something nuanced, or having a conversation where tone matters. Almost anything that starts to escalate in a text thread resolves much faster in a five-minute video call.

This became a deliberate habit. When a Figma comment thread was getting complicated: “Können wir einen kurzen Call machen?” When something needed explaining properly to a colleague: “Hättest du 3 Minuten für einen kurzen Call?” When a sensitive topic came up with a manager: “Good morning. Do you have 5 minutes for a short video call?” A link was always attached. The invitation was always low-pressure.

The principle behind this is simple: written messages strip tone, create ambiguity, and invite misinterpretation — especially across time zones and languages. A five-minute call gives you real-time correction and the ability to say “I think I misunderstood you — can you say more?” Text rarely can.

Where this shows up: Multiple instances across years of immediately attaching a Google Meet link when a topic was getting complex, the consistent pattern of de-escalating written friction by switching medium rather than continuing to type — particularly valuable across a 9-hour time zone difference.

The most significant professional shift of the last few years isn’t a new framework or programming language — it’s a fundamental change in where value comes from as an engineer.

When AI makes generating code cheap and abundant, the core focus must shift to strategy, architectural design, and code review. Not as a prediction — as a practice I’ve been living since 2024.

The model: Delegate the first pass to AI. Actively validate its work. Take full ownership of the architectural fit, integration, and edge cases. AI can rapidly get you to 80%. The final 20% — judgment, context, long-term consequences — is irreplaceable, and it’s where experienced engineers now have multiplicatively greater leverage than ever before.

This isn’t about chasing a trend. It’s about deliberately positioning yourself at the point where human judgment still compounds.

“It’s not important what people think when you arrive. What’s important is what people think when you leave.” — Jürgen Klopp

There’s a thing people sometimes get wrong about ownership: they think it ends when they stop being the one doing the work. It doesn’t. How you transition a responsibility — to a colleague, to a successor, to a future version of your team — is part of how well you did the work in the first place.

My vacation handover documents are not “out of office” notices. They are operational runbooks — written every single time, for eight years. Every onboarding I ran was prepared before the person arrived: the Trello card, the Confluence page, the module guide, the Jira link — all ready on day one.

The quality of every handover is one of the clearest signals of how seriously someone took the work that came before it.