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

In October 2021, I was formally given the role of 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.

From one to four

Over the following months, I grew the team from just me to four people: a developer and UX designer in Vancouver, a second developer in Germany (my first hire in 2020, who I now managed formally), and eventually additional capacity as the workload demanded. I wrote the job descriptions, was hiring manager for each role, and owned the onboarding.

When Alex joined in Vancouver, I flew to Canada to spend a week onboarding him in person. 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. That investment paid back quickly.

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, product, sales, 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 and Slack automations that funnelled requests into the right place. This didn’t eliminate urgent requests, but it gave the team a single source of truth and made prioritisation tractable.

The go-live quality gate: Before this, go-lives happened when someone thought a page was ready. I introduced a formal final approval step: my eventual successor as team lead as the designated quality control point for all go-lives, with a checklist and a clear standard for what “ready” meant. Last-minute changes that hadn’t been reviewed stopped reaching production.

The GitHub migration: The codebase was in Bitbucket. I migrated it to GitHub, 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, I was the technical lead — not because I was forced to step up, but because I’d never stepped back.

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.