Scaling Teams with Ownership: A Protime case study
How a renewed focus on ownership improved Protime's agility
Unpredictable delivery times. Teams at capacity. The agility of the early days gone.
These are familiar growing pains to any fast-moving organisation. Protime, a workforce management company, were facing these challenges in 2023 when they contacted Aardling.
Growing from a small Antwerp startup to managing the time of 500,000+ workers across 40 countries came with all the usual challenges.
It wasn’t always like this - The Technical Evolution
The organisation had already undergone a significant technical transformation. They'd moved from a large, monolithic codebase to a web-based suite. The product was developed by multiple teams working in parallel. Their delivery pipeline had evolved from yearly software releases with no formal quality assurance process to regular releases with automated testing. A growing number of services gained full continuous deployment.
Initially these teams operated as “feature teams”. A small team would work on a single feature until it was done, which lasted 4-6 months. After that the team would move on to a different feature. The teams maintained broad system knowledge while delivering end-to-end features independently. This model of working worked well for a while.
An overstretched system
Over the years, the technical landscape expanded. The business domains and subdomains grew, and with that, the number of services.
By 2023, Protime had 12 feature teams, but the system showed clear stress:
Some features touched multiple codebases. This led to unpredictable delivery times.
Domain knowledge was spread thin. Trivial changes took months to complete, as the team would need to find the people with the knowledge.
Some teams lacked the coaching capacity and senior technical leadership to succeed.
The product team designed solutions top-down, treating development teams as pure implementation capacity. Developers were not involved in the decision process.
More domains and services led to a complex software system with varying requirements, user interface patterns, and architectural styles.
The Ownership Problem
Aardling’s lead consultant Thomas Coopman began to piece together a solution. He worked with engineers, product, and other stakeholders to visualise their systems. Alongside the team he modelled the different elements of their technical landscape. In group discussions and one-on-one meetings with key stakeholders, a core issue emerged: "Everyone owns everything" had gradually transformed into "No one owns anything".
Issues were sometimes going back and forth for days or weeks before being triaged and worked on.
Erik Sacré
Technology Architect at Protime
The implications were systemic:
Teams became passive, expecting complete solutions to be handed down from product managers.
The gap between business and IT widened as teams couldn't effectively contribute to problem-solving.
Technical debt accumulated as teams lacked the deep domain context required for proper solution design.
Production issues were difficult to triage and resolve.
Because teams rarely worked on the same part of the code for a long time, they weren’t incentivised to improve the quality and developer experience.
Shifting to Domain Ownership
Technology Architect Erik Sacré remembers an important breakthrough: In a set of workshops, ran with a cross-section of the software organisation, Aardling consultant Thomas Coopman posed some fundamental questions:
"Who's responsible for what?"
"Where do the responsibilities of a team start and where do they end?"
"What is the ideal team structure?"
Diverse perspectives revealed the need to redefine team boundaries around domains rather than features.
The shift was significant according to Philip Van den Heuvel, a technology business partner at Protime:
Feature teams became teams that either owned a domain, or a service related to a single domain. This created clear ownership paths from problem definition through to production.
Philip Van den Heuvel
Technology Business Partner at Protime
In those workshops, the discussions were sometimes hard. We didn't always find consensus, but everyone agreed that the current responsibilities of the teams had eroded so much that they weren't effective anymore. In order to improve, teams would need to be involved earlier in the design process and be more responsible for their results. In order to do that, the team composition had to change and have the necessary skills to do all this work.
Thomas Coopman
Senior Consultant at Aardling
Results and Ongoing Changes
Six months after those workshops, the teams where we created stronger domain ownership showed improved delivery predictability. The organisation gained clearer capacity insights and better alignment between team capabilities and business goals.
Protime was in a challenging moment when Aardling came along and Thomas struck the right balance between getting input and moving forward. In the past, teams didn’t feel like they were supposed to own certain problems, but that’s changed.
Jordy Dehaes
Chief Technology and Product Officer at Protime
For Erik, it definitely helped to have that outside voice with different experiences with different clients.
Aardling has accumulated a lot of experience with different projects, so Thomas could also really point to examples where this had worked or where this didn’t work. And of course, I could only bring it from a theoretical point of view, ‘I feel this would work’, is quite different from ‘We’ve done this with this team and that was the outcome, so let’s try it.
Erik Sacré
Technology Architect
For Protime, this work is ongoing. As their vision is to become Europe's leading workforce management provider, the transformation isn't just about technical practices—it's about creating a system where teams can succeed.
Aardling’s work at Protime demonstrates that scaling software delivery isn't just about adding more teams—it requires rethinking fundamental assumptions about team structure, ownership, and delivery models.
Key Learnings
Feature team rotation works at a small scale but becomes a liability as system complexity grows.
"Everyone owns everything" leads to a lack of real ownership.
Domain-aligned teams enable deeper technical and business knowledge.
External perspectives help drive necessary organisational change.
Scaling effectively requires a fundamental shift in how teams are organised and how they own their work.