We need to talk about corporate compartmentalization
Your boxes and arrows are killing ideas
Ideas are awesome. Teams and colleagues generally love bouncing them off each other. Good ones, great ones, bad ones, mediocre ones. As far as team processes go, ideation is generally a creative, quick and painless one that attracts high-energy, outgoing and entrepreneurial people. (Yes, even in corporates.)
But an idea has a long way to go before it becomes a mature product. Product/market fit is still vague. Technical feasibility has not yet been estimated. User testing? We didn’t quite get there yet. Meanwhile, our idea has already been sold to “important stakeholders” or “senior management”.
So, tech team. We did our part. We’ve thought up a solution which has management buy-in. When will it be delivered?
This is where ideation meets corporate compartmentalization. The urge to wall off tasks and responsibilities. To box people in. Jay Malone at Invision knows what happens next:
“It’s nearly impossible — and in the best case scenario extremely inefficient — for 1 team to research and validate problem solutions, and then have another team design and build those solutions.”
Compartmentalization kills velocity and creativity
We humans compartmentalize all the time. We put conflicting beliefs in seperate boxes of our brain. It helps us cope with the complexities of life. It’s how we can be an asshole at work (“I need to be, I’m the boss”) while teaching our kids to be kind and polite to all people.
In corporate life, I see compartmentalization as the need for organisations to draw boxes and arrows. Artificial boxes that contain tasks and responsibilities. That are meant to tackle complexity. To help people inside the box feel a purpose; a clear role. To give managers a sense of control. To help teams respect each other’s contribution to the bigger (company) picture. And to structure work.
Here’s a few examples of compartmentalization I have tangled with over the years.
Example 1: organizational compartments
Boxes, no arrows. The traditional corporate organization. Every department is responsible for a piece of the product puzzle (and to bring their expertise to the table on request). Each department has organized their workflow from their own perspective. It’s clear who can do what, but it’s hard to get continuous commitment from everyone.
Example 2: compartments by discipline
Boxes and arrows. Different teams are responsible for a specific phase of product development. One team is responsible for setting up and validating the proposition, the business case, etc. A UX team picks up the design work and the development team builds the product. Every team can have a “Product Owner” but no-one actually owns the product. They all “own” a small part of a lot of products. Or nothing at all.
Example 3: technical compartments
A more detailed split of the BUILD-box from example 2. The development team delivers the code, testers set-up test cases and validate the code before handing it over to a seperate team that takes care of the release. Processes gone mad…
Drawing boxes and arrows is (generally) a well-meant effort to structure work.
The problem is that more compartments means more handovers between people, thereby killing velocity and creativity in product development teams. The result:
- Compartmentalization leads to contracting. These can be implicit contracts (“UX is responsible for the design, this will probably include user validation”) or, worse, explicit contracts (SLA’s for answering emails or deploying code to DTAP) between teams or departments.
- Contracts will be broken and blame will be assigned. Especially when there’s a lack of shared goals or KPI’s.
- Compartmentalization slows decision making. Individuals (or teams) feel they “own” a proposition and are therefore “in charge”. This is extremely troublesome if there’s more than one self-proclaimed owner.
- I’ve also seen this happen the other way around: Nobody takes a decision because no one feels ownership. No one has the responsibility for the entire product and no one might actually take it. Someone always drops the ball.
- Compartmentalization leads to an implicit (or fake) sense of hierarchy. If things are designed in arrows and boxes, those at the start of the process will feel like their input decides the next teams’ starting point.
- Compartmentalization leads to conflicting goals. Ideation teams want to deliver as many new propositions and validate as many new ideas as possible, while the tech team might need to work on technical debt.
- Compartmentalization limits teams from seeing the big picture. This leads to suboptimal work.
- Finally, boxes and arrows kill bottom-up innovation. Being responsible for a small subset of tasks can lead to task oriented behaviour. If you ask people to do a job they will just do it. If you ask them to solve a problem they will go above and beyond.
Moving beyond boxes and arrows
Every company I’ve worked for was aware of their compartments and spent a lot of time and money to reorganize their workflow. Agile transformations, Lean process improvements, CI/CD programs; you name it. They tried to simplify complexity, but in the end it always resulted in drawing boxes and arrows all over again (but in a different way).
So, how to move beyond them? I’m far from an expert on the subject, but I do believe there’s a set of principles companies should follow. Call it Scrum, Agile, Lean or simply common sense:
- Slash and simplify strategy, goals, KPI’s/OKR’s. Corporate departments or teams don’t need to set up their “own” strategy. In the end they all serve the same purpose.
- Put your product front and central. Organize your teams around your product. Sales, marketing, support, tech, UX, etc. are all part of the same product team. They are united by a common goal and shared KPI/OKR.
- Question every compartment and every handover. How can this task be done by the same team? Every process improvement should lead to less boxes and less arrows. Fight the natural urge to compartmentalize and allow things to get messy once in a while.
- Inspect and adapt. Treat your organizational design like you would treat your product. Try something out, validate and improve.
Most importantly, break out of your own box and be inclusive. Make sure that everyone can contribute to the product roadmap. If you have a good idea you should not just be able to put it out there, you should be able to actually help it grow.
