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. That instinct eventually became a formal go-live quality gate, so the standard didn’t depend on me personally pushing back every time.

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.

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 infrastructure-as-code so the platform isn’t tied to one person’s knowledge, to processes that outlast their creator. When I joined a company as its 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.

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 organization (taking that case directly to the CMO), 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.

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. The request intake system I built channeled ad-hoc requests into a predictable process instead of letting them overwhelm the team, and the sprint framework did the same for unpredictable delivery.

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.

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 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. I also built a career track so every IC could see their own path and know what “good” looked like at each level: enablement that outlasts any single onboarding conversation.

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

8 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 an anniversary post marking 8 years there, 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 practice it.

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 recognized 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 a vendor’s usage limit before it became a crisis. Writing the recap from a major cross-team kickoff so people who couldn’t attend 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: one more way of bridging the web team and the wider engineering org as AI adoption accelerated.

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

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.

The CMO at the time once described the pattern as “the little cultural things that make a difference.” That’s exactly what I was going for.

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.

The CMO at the time described it directly: “You’ve realized 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.”

It’s also why an internal recognition award once specifically cited me for showing up consistently in ways that had nothing to do with my job title.

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

If you see something that needs doing and you can do it, do it. That’s been true in every role I’ve had, especially in the first weeks: auditing what’s already there, noticing what’s broken or inefficient, and fixing it without waiting to be asked. It was never about being exceptional; it’s just how I approach work.

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 a vendor’s usage approaching its limit before it ran out, and proposing a workaround. 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.

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.

A direct report once put it simply: “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. That didn’t stop after the onboarding trip: over the next three years I went back five more times, roughly every six months, because some things only work in person. When growth conversations came around, I tried to make them genuinely honest, not corporate performance theater. I built the web development career track so every IC had an actual path, not just a vague promise of growth.

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. A direct report later told me I’d managed it: “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.

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, but as a daily practice.

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 8 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.