Building a team, a career track, and an operating model

In October 2021, I stepped into the Lead Web Developer role, and it became clear that I was on track to lead the team formally, which happened in January 2022, when I became Team Lead Web Development. Before that, I’d been the only web developer at Staffbase; I’d been doing the work of a team by myself for three and a half years. Building the actual team, and building the structures that would let it function, was a different kind of challenge.

Building the team

The team I led grew to four people, including me. The Vancouver-based Web Designer & Developer (one role, covering both design and development) came into the team through the Bananatag acquisition rather than through a hiring process I ran; integrating that person into the Staffbase web team was itself part of the acquisition work. Alongside that, I made two hires of my own: my first hire, based in Chemnitz, joined in 2020, and a second developer based in Hamburg joined in August 2022 as the workload demanded. HR was involved throughout the hiring process, but as hiring manager I was responsible for the job descriptions and the process end to end, and I owned onboarding for each person who joined.

When the Vancouver-based team member came into the team, I flew to Canada to spend a week onboarding him in person, the first of six trips over the following three years. The 9-hour time difference made remote-only onboarding a significant risk; there was no substitute for being in the same room during the first week. It turned out there was no substitute for it afterward either. Roughly every six months from November 2021 through November 2024, I flew to Vancouver: a consistent investment in closing a gap that time zones don’t make disappear on their own.

The trips continued, each with its own official agenda (working sessions, planning cycles, design reviews) and an unofficial one running underneath: the trust a distributed team runs on doesn’t build over video calls. It builds over the meals, the downtime, the hours that have nothing on the agenda. Same underlying logic every time: some things work better in person.

Building the structures

A team needs more than people. It needs a way of working together.

The career track: When I took the role, there was no formal career development framework for web development at Staffbase. I built one from scratch: first as a responsibility-based model (what you do at each level), then refined it into a competency-based model (how well you do it, not just what). This gave every IC on the team a clear view of where they were, where they were going, and what “excellent” looked like at their level.

The sprint framework: Ad-hoc delivery is workable when you’re one person. It doesn’t scale. I introduced a sprint-based working model for the team: structured ceremonies, a predictable cadence, a way for stakeholders to have visibility into what was coming and when. Not heavyweight Scrum, but enough structure that delivery became more predictable without adding bureaucratic overhead.

The request intake system: One of the most acute problems we faced as the team grew was request volume. Marketing, IT, legal, employer branding: everyone had web needs, and they arrived through every possible channel. I built a dedicated Jira project for web requests, with a structured intake form so every request landed in one place instead of scattered across Slack DMs and ad-hoc messages. This didn’t eliminate urgent requests, but it gave the team a single source of truth and made prioritization tractable.

The GitHub migration: The codebase was in Bitbucket. As a team, we migrated it to GitHub and introduced codeowners, mandatory PR review requirements, and CI/CD pipelines. Standard practice, and the right moment to introduce it properly.

Staying hands-on

One thing I was deliberate about: staying a developer. Not because the leadership work wasn’t sufficient, but because a team lead who can’t contribute technically is a bottleneck, not a resource. I kept writing code, reviewing pull requests with depth, and owning technical decisions. When the Storyblok migration began after I’d transitioned back to IC, I brought that same hands-on instinct to the project: contributing directly to implementation and bridging SensioLabs’ Symfony expertise with our actual content and workflows, rather than stepping back into a purely advisory role.

The operating model

By November 2025 (after I’d transitioned back to IC), the team had documented our way of working into a formal operating model: triage responsibilities, communication expectations, escalation paths, guiding principles. The document codifies what had been established through years of iteration.

The real measure of the structures I built is that they continued to work after I was no longer the person running them.

Leadership didn’t end with the title

Moving back to IC in October 2024 changed the form of my leadership, not whether it continued. I kept mentoring: onboarding and growing the team’s new UX designer the same way I had every person who joined before. I kept building the structures the team relied on: I proactively created the Web Team Vision document, intending to present it to the CMO; that follow-through never happened, but the initiative itself was mine, written before anyone asked for it. I kept being the person who connected disciplines (bridging backend, frontend, design, and increasingly, AI tooling) and made a habit of bringing knowledge back from conversations elsewhere in the company rather than sitting on it.

None of that needed a manager title. It needed the habits the team-lead years had built: document it, share it, make sure the people around you have what they need before they ask. The operating model survived because the behaviors behind it never actually stopped.