Author: Jurgen Appelo

How does a fast-growing scale-up organize its teams, management, and business units? What does it mean to have agility embedded in company culture? How can you make everything an experiment? Check out the Coolblue case study and learn what you can do to become the next two-billion euro scale-up.

*Figure 1: A Coolblue Domain in unFIX visuals*

Introduction

I recently ordered a projector screen from Coolblue, and I feel slightly embarrassed for sending it back two times. The first time was my own fault because, despite measuring for the right size, it turned out the projector screen sat too high under our higher-than-average ceiling. They came to swap it for a larger screen, but that one also had to be sent back. Apparently, the package got ripped during transport, and the necessary mounting brackets were missing. I'm happy to say we can now finally enjoy our games and movies on the third projector screen, but I fear Coolblue lost some money on this particular order.

Coolblue is the 2nd largest e-commerce business in The Netherlands. The company was founded in 1999 and has grown to around 7,000 employees, annual revenues of 2.3 billion euros, profits of 91 million euros, a staggering Net Promoter Score of 67, and expansion into Belgium and Germany. That's quite an accomplishment.

Unlike main rivals such as Bol.com and Amazon, the strategy of Coolblue is not to outsource warehousing, distribution, or delivery. To enable superior customer service, the company insists on keeping all parts of the value chain in-house.

In this case study, I take a look at how the company's Tech department is organized, and I compare my findings to patterns in the unFIX model (Figure 1). You will find that Coolblue is an inspiring example of a company that has business agility and the customer experience at its core. However, even though the business has been able to scale up tremendously with agile values and principles in mind, such a fast-growing company still has plenty of challenges to tackle.

Note: The focus of this article is on the Tech part of the company. Also, to minimize confusion, I try to stick to Coolblue's terminology and only use unFIX terms for comparison, and when Coolblue has no equivalent words.

Development Teams

It probably comes as no surprise that the Development Teams at Coolblue are fully agile. The teams of Software Developers (Figure 2) are mission-driven and organized around customer value. (In unFIX terms, they are Value Stream Crews). They commonly work with Scrum and two-week sprints, but they can release and deploy their code continuously (multiple times per day).

Though web development and mobile development are usually split into different Domains (see below), the teams building the mobile apps always combine Android, iOS, and back-end development into one team. Also, the company finds it essential that there are no separate quality assurance teams. All responsibilities necessary for an end-to-end value stream are contained within the Development Teams.

The Head of Technology at Coolblue insists that the fifty Development Teams at Coolblue always have at least two and at most seven team members. People can come up with creative reasons for needing a bigger team, but when there is a valid need to grow larger, the teams are required to split up. New teams are seeded with existing Coolblue-ers to guarantee that the company culture and experience are embedded from the start.

Team Leads

The Development Teams have either a Team Lead or a Development Lead with specific HR responsibilities, such as sick leave reporting, personal development of the developers, and feedback on their performance. A Team Lead (Figure 2) is a manager of one team, while the recently introduced Development Lead has people from multiple teams reporting to them.

The Team Lead role seems similar to what I call a Captain, but it's not entirely the same. In my model, team captains lead missions, but they don't have HR responsibilities toward their fellow team members. I believe teams are usually better off with a line manager outside the team, which helps them be more self-organizing. (See scenario 2 further below.)

The Development Lead role is a step in my suggested direction, and it will be interesting to see how this new role evolves at Coolblue. When a team does not have its own Team Lead, it can still be helpful for them to have a captain role for leading missions as "the first among equals," but this role should not come with a mandate from HR.

Either way, it is good that team members don't see Product Owners as their managers. All team members in Scrum are peers. Product Owners are not more important than Software Developers.

Domains

Development Teams are organized in thirty Domains (Figure 3). Coolblue has domains for Ordering, Warehousing, Delivery, Customer Service, Mobile, Cloud Engineering, HR Systems, and many more. Most of these are oriented around an external customer value proposition; a small number of Domains are inward-looking with internal users inside the company.

The Domain construct comes very close to what I call a Base. It is the part of the company where the employees feel most at home. The size of Domains varies from a handful of people to a few dozen, and they cover all roles that are needed to be self-sufficient and be valuable, either to external customers or to internal users elsewhere in the company.

A typical Domain of 20-30 people has several Customer Journey Specialists (or User Journey Specialists), Data Engineers, Interaction Designers, one or more Product Owners, an Agile Specialist, and a Business Owner. And, of course, one or more Development Teams with either one Development Lead or multiple Team Leads.

Except for the mandate on maximum team size, there are few constraints on self-organization within each Domain. Management recognizes that each unit is different and needs to figure out its own optimal structure.

Dependencies

A classic problem in every organization is: how do you divide the work when the amount is too much for one team? Not surprisingly, Coolblue continuously faces the same question within and among its Domains.

*Figure 4: Product Owner(s) in a Domain*

Some Domains choose to have one Product Owner working with multiple teams (Figure 4), but then these POs need to learn to delegate as much as possible, or else they run the risk of being overwhelmed. Other Domains prefer having one Product Owner per team, each with their own sometimes arbitrary product area, but then they need a way to coordinate work among the POs. Either way, they will have to manage dependencies among the teams.

There are multiple ways of getting this under control. (I suggest a small Facilitation Crew.), But no matter how a Domain chooses to address this problem, it is important not to introduce an additional management layer where, for example, junior Product Owners report to a Senior Product Manager. (In fact, I would recommend an additional constraint that forbids any such reporting layers emerging in any of the Domains.) Healthy companies stay agile and versatile, which means having as few management territories as possible.

Domain Boss

Each Domain is managed by a Domain Boss (Figure 5) who reports to the company's Management Team. The Domain Bosses themselves are the line managers of some people in their Domain, but not all.

Typically, Product Owners, Business Owners, and Customer/User Journey Specialists are organized by "vertical." These business-oriented people report upwards to the Domain Boss. The reasoning is that they all have their primary focus on business problems and opportunities in their narrow Domain.

In contrast, Software Developers, Interaction Designers, Data Engineers, and Agile Specialists are organized "horizontally," and these technical and process-oriented disciplines report to their managers elsewhere in the organization.

The result of this setup is that Domains are not really autonomous, and the organization is a matrix structure. I will have more to say about that in a moment. (Also see scenario 1 further below.)

(Note: The terms "horizontal market" and "vertical market" in sales and marketing language seem the inverse of "vertical functional silos" and "horizontal value streams" in organization design. A discussion between an e-commerce marketer and an organization designer could be rather amusing.)

Guilds

Agile organizations typically enable people to use guilds (Figure 6) to discuss their favorite topics beyond the boundaries of their teams and even beyond their business units or Domains. For example, at Coolblue, there is a Coaching Guild where the Product Owners from multiple Domains get together once or twice per month to discuss their craft. There are other Guilds for recruitment, innovation, training, knowledge sharing, etc.

Such Guilds (or Forums in unFIX language) are especially important for business-oriented disciplines at Coolblue since these people have their managers inside their Domain. Without Guilds, they might have little opportunity to discuss their craft with like-minded employees beyond their own environment.

In contrast, the technical and process-oriented disciplines have their management elsewhere in the company, which means that they can coordinate ways of working within their functional group without the explicit need for a Guild. However, as I will describe below, the functional disciplines could also be turned into Guilds. (See scenario 3 further below.)

Boundaries

The problem of dependencies repeats itself outside of the Domains. No matter how Domains are defined (preferably as autonomously as possible), there are always dependencies to be managed with other parts of the organization. (After all, if there were no dependencies, they would be independent companies.)

Traditionally, Coolblue defines Domain boundaries between the steps in a customer journey. One Domain handles browsing the product catalog on the website; another handles checkout and payment; the next Domain takes care of the delivery; yet another one deals with possible returns, and so on. Each Domain optimizes and improves its part of the entire customer experience.

The company's mobile apps have customer journeys, too, although the journeys on mobile are not the same as those on the website. For example, the Mobile Domain found that augmented reality (AR) on mobile phones significantly improves the conversion rates of TV sales. But such features are not even possible on the website. In contrast, the website traditionally shines in search engine optimization, content marketing, social ads, and more.

But customer journeys and platform technologies are not the only ways to define boundaries. In its 23-year adventure so far, Coolblue has successfully grown the business in somewhat organic and improvised ways. This is by no means meant as a criticism. On the contrary, I see the current organizational structure as the natural outcome of a company that has grown fast in a very agile way. However, future growth may benefit from a more systematic approach to the division of labor on a larger scale.

Collaboration, Cooperation, Coordination

*Figure 7: Clusters of multiple Domains*

In my work on the unFIX model, I distinguish different patterns for collaboration vs. cooperation. Within and across Domains (Bases), people collaborate in Teams (Crews), and they cooperate in Guilds (Forums). Sometimes, active coordination is carried out by specialists (Facilitation Crews).

In a "fractal" organization design, similar patterns exist one level higher: multiple Domains collaborate in Clusters (Figure 7), and they cooperate in Assemblies. The coordination among the Domains may be actively supported by other Domains specialized in facilitation.

In the following sections, we recognize most of these patterns in how Coolblue has organized itself. Granted, the terms being used are different, some of the solutions are in a transitionary state, and some are still evolving, but the first signs of the patterns are there. And this is important because a bigger size of the company comes with more considerable demands on organization design.

What about Coolblue's expansion into regions like France, the UK, or the Nordics? What about new product types such as foods, fashion, or furniture? What about different market segments, like B2C, B2B, and B2G? What about alternative sales channels (online, retail, pop-ups)? What about other business models (direct sales, leasing, franchising, or memberships)? I have no idea what Coolblue might be interested in. There are so many ways to grow and expand the business. Each of them comes with new business requirements, more demands on the Tech department, and more ways of slicing Domains and ending up with dependencies that need to be managed.

Coolblue's ad-hoc and experimental approach (which has been quite successful so far) can be turned into a more deliberate, systemic approach for future growth.

Customer Experience

Coolblue calls itself "obsessed" with the customer. Despite the heavy reliance on technologies, they don't call themselves a tech company because that might distract employees from the only thing that matters: a better customer experience. They have good reasons to brag because the company's Net Promoter Score stands at 67 points, which is beyond impressive.

Each Domain has one or more Customer Journey Specialists (or User Journey Specialists in the case of internal users) who monitor and improve the customer experience (Figure 8). (This matches the Experience Crew pattern in the unFIX model). Whether the Domain has one, two, or five different Development Teams, these Customer Journey Specialists help them create a cohesive, enjoyable, and integrated experience for clients.

But customer journeys are rarely isolated to the area of one Domain. Depending on the kind of product, such journeys can begin online or in the mobile app, cross over to Coolblue's physical stores, and finish with delivery at home. This means that Customer Journey Specialists are expected to coordinate and cooperate across the boundaries of multiple Domains. Currently, the company has no formal structure for this, though they have been able to make this work in a self-organized manner. The question is, will the ad-hoc approach still work on a larger scale?

In the future, I can imagine the emergence of Customer Journey Guilds or Assemblies (cooperation of specialists across Domains) or even Customer Experience Clusters (specialized Domains that offer customer journeys as a service). (See scenarios 5 and 6 below.)

Agile Specialists

*Figure 9: Agile Specialist in a Domain*

Many Domains at Coolblue have a Scrum Master or Agile Specialist available (Figure 9). They assist the Development Teams in building out their agile processes while adhering to the agile values and principles. Unlike Customer Journey Specialists, Agile Specialists are not managed by the Domain Boss. Instead, they have their own Manager Agile outside the Domains.

The Scrum Masters / Agile Specialists see themselves as advisors on temporary assignments. Working most often with the Team Leads and Product Owners, they start with an intake, a few sprints of observations, and then offer suggestions for interventions. While a typical engagement lasts between three to twelve months, they usually work with more than one Domain at a time, and their aim is, after a while, to not be needed anymore.

Considering that the Agile Specialists Team exists to help others, we can easily see them as a Domain with internal customers that offers agile coaching as a service. When the group evolves and grows in the future, it might split into multiple Domains specializing in different facilitation services. Together they could form a Capability Cluster. (See scenarios 4 and 5 below.)

Principals and Specialists

*Figure 10: Principals (can work across multiple Domains)*

Over time, Coolblue discovered that some employees have rare, valuable competencies that need to be available beyond their own Development Teams. They might be people with essential architectural skills or deep technical expertise that is hard to come by. To allow all teams to benefit from those talents, they introduced the idea of Principals (Figure 10). Principal Developers have a home team, but they can freely roam around the company to offer advice whenever they are asked (and also when they are not).

The role of the Principal Developer is a little bit similar to other specialists such as Data Engineers and Interaction Designers. However, while the latter roam around within each Domain, the former often travels across Domains, depending on where their skills are most needed.

The pattern of free-roaming specialists is what I call a Capability Crew. I usually advise that their managers join the management team of the Domains where these specialists operate, but only when they work in only one Domain. Alternatively, when they offer their talents to multiple Domains, the specialists could form a separate Domain instead, and they would be offering their services to internal customers. With Principal Developers helping out other Domains, Coolblue made a first small step in precisely that direction. (See scenario 4 further below.)

Services and Platforms

A fast-growing scale-up such as Coolblue must rely heavily on a top-notch technical infrastructure. Several Domains in the company, such as Hosting & Deployment, are exclusively focused on building and servicing the platforms that the entire business operates on.

It is impossible for almost any Development Team to own a full technical stack from the top UX layer down to the bare metal of cloud servers. At various points, nested levels of technologies are better handled by lower-level suppliers. I call them a Platform Crew when the platform supplier is a separate team operating inside the same Domain. When the company grows, and such teams spin off into multiple infrastructure Domains, they form a Platform Cluster together. In everything but name, this is what Coolblue already has.

Matrix Structure

I discussed earlier that Development Teams at Coolblue have either a Team Lead or a Development Lead and that these report to a Development Manager who does not work in a Domain. At the time of writing, there are five Development Managers, each with a span of around 70 Software Developers, which includes the Team Leads and Development Leads (350 people in total), spread out over thirty Domains. This makes the business a matrix organization.

Matrix structures were invented to solve a pervasive problem in functional silos where people optimized and improved their functional areas rather than the solution to a customer's problem. Agile organizations typically solve the same problem by organizing people around value streams. Coolblue reports that Development Teams feel most at home in their (customer-oriented) Domains, while they have a much smaller connection with their functional disciplines. The matrix design has worked well for Coolblue because there is good collaboration and a personal approach between Domain Bosses and Development Managers. Few conflicts escalate up the management chains, and the pairings of Domain Boss+Product Owner and Development Manager+Technical Lead (and in many cases Agile Specialists) are seen as a vital contributor to the organization's success. The question is, for how much longer will this work?

The literature on organization design has many warnings about the matrix structure. It tends to lead to fat layers of middle management with a lot of coordination overhead between business managers and technical managers. In addition, when collaboration between these managers breaks down, an increasing number of conflicts escalates further up to higher management. The unintended side effect of this is more centralized decision-making.

Perhaps Coolblue has found a way to deal with the common dysfunctions of the matrix, in which case we could say, "Never change a working system." But I consider it more likely that the dysfunctions have not yet emerged because the Tech department is not big enough. With thirty Domain Bosses and five Development Managers, there are "only" 150 possible connections to be nurtured. Granted, not every Development Manager coordinates with every Domain Boss, so the actual number of relationships is smaller. However, when the company has three times more Domains and twice the number of Development Managers, they will be facing 900 possible connections in the matrix. When personal coordination turns into a more formal approach, the dark side of the matrix will rear its ugly head.

It won't surprise you that I strongly suggest companies change their matrix into a network because networks scale better than matrices. Coolblue made the first step already. I was told that Team Lead responsibilities existed initially outside the Domains, but they moved into the Domains not long ago. I say, let the Development Managers follow suit and form management teams with the Domain Bosses. Ditch the matrix before it kills you. (See scenario 1.)

Leadership

A network organization has fewer managers and more leaders than a traditional, hierarchical structure. Only a small number manage the system while enabling many to lead the people. By delegating as much as possible to non-managers, network organizations enable leadership development without anyone trying to claim management powers.

In my work, I advocate Captains leading Crews and Chairs leading Forums in a self-organized manner. Similarly, leadership will be needed when it's time for Domains to self-organize into Clusters and Assemblies. Leadership roles reduce the upward pressure of employees aiming for a management position because of the desired status, influence, and better compensation. It also offers management teams more ways to evaluate candidates for management positions because they can assess their earlier performance as leaders in the network.

It seems to me that Coolblue has already taken various small steps in this direction, but there is more to be done to become a company with a network structure.

Let's discuss some possible scenarios.

Options and Scenarios

I wouldn't dream of telling Coolblue which direction the company should evolve. I have nothing but great respect for the journey that brought them to their current way of working, and I am in awe of the company's growth and success. However, like a Principal Developer, I am willing to share my opinions and suggestions on what a possible future can look like, even when nobody asks me. ;-)

Scenario 1: Introduce Management Teams for Domains

Management is teamwork. Figure out which Development Managers work most often with which Domain Bosses and get them to form management teams (Governance Crews) of their Domains. During a transition period, the Development Managers may have to sit on multiple management teams, but (as the business keeps growing) they should aim for involvement in only one or two Domains. (Some Domains could merge so that two or three Domain Bosses team up with one Development Manager.)

The Management Teams need to have complete responsibility for their Domains, and nearly everyone in that Domain should be their direct report.

Scenario 2: Make Domains larger and more flexible

A team of three or four managers can easily manage a Domain of up to a hundred people. There is no need to add more Domains (and thus hire more Domain Bosses) when the Domains can increase in size. Besides, larger Domains have more ways to reorganize themselves depending on context.

Move HR responsibilities away from Team Leads and Development Leads to the Development Managers and offer the Leads a job on the Management Team or nudge them to become Guild Leaders or Principal Developers. Removal of management territories makes team structures more flexible and provides the benefits of dynamic reteaming within the Domain.

Scenario 3: Create Guilds for disciplines and interests

Managers should manage cohesive systems, not arbitrary functional groups. Allow Software Developers to cooperate across Domains through Guilds (Forums) led by Guild Leaders (Chairs). During a transition period, the Development Managers can still lead these Guilds, but the role is best offered to Team Leads, Principal Developers, and other informal leaders.

Guilds are also easier to create and destroy than functional disciplines, making the company even more flexible. Software Developers can decide to participate in one or more of the Guilds. Similar Guilds could be created by Product Owners, Interaction Designers, Customer Journey Specialists, etc.

Scenario 4: Turn some disciplines into separate Domains

With Hosting & Deployment (a Platform Domain), Coolblue has already discovered the benefit of having some Domains focus exclusively on infrastructure. The same can be done for specialists with rare expertise (Capability Domains) and Agile Specialists offering agile expertise (Facilitation Domains). In each case, these teams provide a valuable service to others in the organization.

Such Domains have their own managers or management teams, and their internal customers should judge their performance (as in-house suppliers). (In a later stage, the company could even open up the market and allow Domains to procure selected services from outside if they find them cheaper or better. Likewise, the in-house suppliers might professionalize and offer their services to some external clients.)

Scenario 5: Let Domains collaborate in Clusters

Clustering of Domains means "teaming up" without adding unnecessary management layers. At Coolblue, Product Owners already coordinate their roadmaps with POs in other domains without management intervention. Instead of expecting this to happen organically and spontaneously, the company can be more deliberate in nudging self-organization and the clustering of the Domains.

Domains that collaborate on offering a new product or service to customers can form a temporary Value Cluster (similar to team members collaborating on Development Teams). Such clusters can be either temporary or permanent. Right now, the various Domains that offer infrastructure services can already be treated as a Platform Cluster. Likewise, Facilitation Domains might form a Facilitation Cluster, and Capability Domains could form a Capability Cluster (Figure 11).

Scenario 6: Let Domains cooperate in Assemblies

*Figure 12: Assemblies of multiple Domains*

Finally, Domains always have things to coordinate with each other. While clustering is about Domains collaborating as teams, assembling is about Domains cooperating so that they don't get in each other's way (Figure 12). Multiple Domains can cooperate on a typical customer journey so that their efforts at optimization do not negate the steps taken by any of the other Domains. Domains might also cooperate on the adoption of new technologies or the expansion into new geographical regions so that they are implemented in the various Domains in similar ways.

The difference between Clusters and Assemblies is similar to the difference between Teams and Guilds. Collaboration happens in Teams and Clusters; cooperation happens in Guilds and Assemblies. The difference is that clustering and assembling happen at the Domain-level, with representatives chosen from each Domain. And all is accomplished with informal leadership roles and no extra management positions.

Reminder: What I describe in this article is based on my conversations with people from the Tech department, including around 400 people out of the 7,000 employees of Coolblue (Figure 13). The rest of the company works in warehousing, customer support, physical stores, deliveries, and more. These other departments have different organizational structures, but I'm confident that most of the patterns mentioned here are applicable elsewhere too.

Roadmaps and Epics

What I discussed so far concerns only the organizational structure of Coolblue. But what about the processes?

The company leaves decisions about what processes to follow mostly to the Domain Bosses, their Development Teams, and their Agile Specialists. As I said earlier, most teams follow Scrum practices, but there is a wide variety in the details. However, one process stands out because it's practiced across all Domains: the quarterly roadmaps.

Each Domain has ownership over its roadmap. Every quarter, Product Owners and Domain Bosses fine-tune this roadmap, which uses a rolling wave planning with a horizon of half a year. For example, the road map finalized in June shows the plans for Q3 and Q4.

The Domain Boss and Product Owner present their ideas to the Head of Technology and the company's top management. This means that company management has dozens of roadmap sessions each quarter, one with each Domain. The Product Owners will usually already have discussed their ideas with their peers in other Domains, but management might still have suggestions for modifications and further coordination. (It's important to note that plans usually originate in the Domains, not at top management.)

*Figure 14: M = Maintenance, I = Improvements, A = Adaptations*

Each Domain's roadmap typically consists of prioritized epics. These epics always need a business case in the form of a problem, a suggested solution, and an expected return on investment as a measurable improvement either in NPS (for customers) or EBITDA (for the business). For the implementation, they obtain rough estimates from the Development Teams to offset expected revenue or cost savings against expected investments. Over the years, Coolblue has developed advanced formulas to calculate the anticipated effects of new features. For example, "How much money do we save when five percent fewer people return a product because of a wrong size?" (It's probably a lot of money when the returned products are giant project screens.)

I find it particularly admirable that the company's management does not expect Domains to commit to delivering prioritized epics. The environment will change, customer needs will change, and therefore it's pretty reasonable for Domains to change plans halfway through a quarter to address a more significant risk or pursue a larger opportunity. It signals a level of maturity that the company treats roadmaps as best intentions, not as a baseline for delivery.

Additional note: maintenance work (including technical debt) is handled by the Development Teams themselves, and minor issues and operational requests that don't deserve to be on the roadmap are prioritized separately by Product Owners. A small part of each team's capacity (between 10-20%) is reserved for maintenance and minor improvements. (Figure 14)

Experimental Culture

Despite its rapid growth, Coolblue has retained much of its startup mentality. The company is very flexible, experimental, and open-minded, and many young people have quickly taken up a lot of responsibilities. Agile was never implemented at Coolblue. It was there right from the start.

One of Coolblue's core principles is that everything starts with an experiment, and they only scale something up when it works on a small scale. For example, the expansion into Germany began by sending one package to Düsseldorf, not far from the Dutch border. They used what they learned from that first experiment to plan the subsequent more extensive investigations. As some employees said to me, "We don't implement; we experiment," and "We nail it before we scale it."

This experimental mentality also comes with a healthy skepticism toward suggestions and best practices applied elsewhere. Quite often, Coolblue does the opposite of what others suggest, and then they make it work too. For example, it's a "best practice" in the e-commerce industry to outsource warehousing, customer service, and package deliveries, but Coolblue does all this in-house. They make it work through experiments, and they enjoy the benefits of owning the entire solution at scale.

Note: As an example, a new Domain is developing a mobile app for their delivery personnel. The company is not satisfied with the products offered by external vendors and decided that great delivery experiences, using an app that's fully integrated with the rest of their platform, is something they want to have complete control over.

Employee Experience

In addition to my admiration for Coolblue's agility and experimental mindset, I have a weak spot for the company's attitude toward the employee experience.

Coolblue does not work with gig workers. Everyone is officially on the payroll, meaning that people working in warehousing or delivery benefit from standard Dutch worker protection, sick leave policies, and so on. The company has not embraced this policy merely for the benefit of workers. It believes that every touchpoint with the customer should be handled by someone who truly represents the company. When the doorbell rings for the delivery of your package, it's probably not a DHL guy with a truck; it's more likely a Coolblue employee on a bicycle. (Though I was happy for the delivery guy that he didn't bring my three-meters long projector screen on a bicycle.)

In the Tech department, the employee experience has a priority too. Team members are expected not to want to work in the same job for too long. Management regularly checks in with everyone to see if they would enjoy moving into other teams or leadership roles with extra responsibilities. Nobody should find their work boring or unchallenging. On top of that, despite the significant shift to remote working, there is a strong push for teams to get together at least once per week to see each face-to-face and maintain and develop their personal connections.

Disruptive Innovation

After hours of conversations (and even more time writing this article), I have one final thought to share about Coolblue's future potential.

From all I heard and observed, it seems that innovation at the company happens continuously, bottom-up, and almost exclusively in small steps. There is a relentless drive in the business to always make things better for customers, which is a great thing. For example, the feature to use augmented reality on smartphones to check if a TV fits in a room was not created from scratch. It was the seventh iteration of a solution that began its life as "sticking sheets of A4 paper across an empty wall".

Coolblue relies on Domains to understand real customer problems ("Does the TV have the right size for my room?") and to keep iterating on NPS and EBITDA. This sometimes means throwing out earlier solutions and replacing them with new ones. So far, so good. (I would suggest also helping customers to pick better-sized projector screens.)

But what if entire Domains deserve to be replaced with new ones? What if it's time for a larger part of the company to reinvent itself? What if, in order to survive or thrive, the business needs a radical, disruptive change instead of a gradual, continuous one? When you only improve in small steps, you often cannot see the forest from the trees. Sometimes, you need to take a higher-level view and wonder, "What if we started all over, solving tomorrow's big problem instead of today's small problems?" Mobile phones and TV sizes become irrelevant when we live in the metaverse.

It is tough to make disruptive innovations happen with existing Domains that have a vested interest in their current customer problems. It is even harder to make this happen with multiple Domains that all have their half-year roadmaps to care about.

Most management literature agrees that disruptive innovation finds the most fertile soil in new business units with no shared history or existing customers to care for. To ensure long-term survival, Coolblue could benefit from having one or two Domains acting exclusively as incubators for genuinely disruptive ideas, unencumbered by cross-Domain dependencies and not bothered with quarterly planning cycles.

Conclusion

I have great respect for what Coolblue has achieved in only two decades. To be honest, it is one of the reasons I picked the company for a case study because I wanted to learn if there were some yet-to-be-discovered recipes for success. (And the company is based in Rotterdam, like me, which was a good sign too.)

Overall, my impression is that Coolblue is a truly agile company with an unwavering obsession with the customer experience and a relentless drive to try and experiment. With such principles in place, one does not need a scaled agile framework to become a fast-growing scale-up.

In the way Coolblue organizes itself, I recognized nearly all patterns I advocate in the unFIX model. Granted, they come by different names, and some of the practices are still emerging or are in transitionary states. Still, my overall impression is that the Tech department of Coolblue is, to a significant extent, unfixed.

The only serious question marks I have concern the long-term viability of the matrix structure, which has served the company well up to now, and the company's appetite for disruptive innovation, which might benefit from a more structured approach.

But, as I stated earlier, Coolblue has a reputation for doing the opposite of what people suggest, which is perfectly fine with me. I will leave any follow-up decisions to them. Meanwhile, I will be at home, enjoying movies and games on our (third) projector screen. 😁

Join us for the unFIX Foundation Workshop

Big thanks to Willem Koopmans, Sonja den Biggelaar, Freek Gerritsen, Dennis Barendrecht, Aarti Sewmar, and Vera Lusink.

Coolblue Unfixed (Case Study of a Scale-up)