The Hagakure #83: Don't Copy/Paste From Other Companies
Back in late 2015, my boss, colleagues and I decided a re-org was a good idea.
Too many dependencies across the different functional teams. The pace of development was grinding to a halt. A good headache to have as this was a result from the enormous business and team growth we were experiencing.
So we did what thousands of other growth companies did. We copied Spotify and pasted it right there.
Now we had tribes, and squads, and guilds and all the rest of it. We even copied the idea of leaderless squads. I suppose we thought teams could simply self-organize. Or maybe we thought everyone was senior enough.
We were brimming with excitement.
In hindsight, I don’t think it was an entirely bad idea. The cross-functional setup we ended up with still remains, almost a decade later. It helped scale that organization from ~70 to multiple hundreds of engineers. But it did so through a lot of pain and turnover over the years, because we tried to look like Spotify while remaining exactly who we were.
While the org chart transformed, our thinking and level of awareness did not.
Management and leadership practices remained the same, people still lacked coaching, and the top-down, controlling nature of the company culture persisted. Sure enough, it didn’t take long to institute squad leads. There needed to be someone to shout at, “hold accountable.”
We also took Spotify’s org structure and ran with it, while leaving the rest behind—a certain way of thinking about complexity, how to build products, how to work truly cross-functionally rather than a disguised waterfall, feature-factory kind of way.
In The Real World…
When I make this type of point using a certain subset of companies as an example (Netflix applies almost equally well here with ideas like “increasing talent density”), I often get push back:
“Not everything is rosy in those places either.”
“The real world is not like the books.”
True, true.
The real world is the real world. A book is a book. The map is not the territory.
But maps do provide us with some fundamental clues about how to make sense of the territory. We ignore them at our own peril. We can also be consumed by our confirmation and survivorship biases (plus a bunch of others) but I wouldn’t recommend it.
The point is that when we look at the Maps app in our phone, we don’t pretend to ourselves that the map is the territory. But whenever at work we copy/paste from other places, that’s essentially what we’re actually doing. We copy the end result—or at least how it appears to us—and we forget to deeply consider the thinking, the mental models, even the values that generated it.1
I have observed a similar pattern with hiring executives and directors from FAANG companies. Many 2nd and 3rd (and even 4th…) tier companies obsess with that. More often than not those executives come so steeped in the intense cultures that shaped them, with a mandate to reproduce those methods in the new place, yet possess a sheer lack of self-awareness and adaptability to a wholly new reality.
Often what happens is that the host rejects the transplant.
But the rejection happens slowly, silently, insidiously. It’s hard to pinpoint. There’s just this general air of malaise. Good people leave. And we’ll blame it on something (or someone) else.
How To Avoid Copy/Paste
In This is Lean: Resolving the Efficiency Paradox, Niklas Modig and Pär Åhlström tell the story of three researchers who went to Nagoya to visit the Toyota Motor Corporation office there.
They wanted to learn how to implement “lean” in the service business. So they met with the senior manager for the internal special unit that Toyota started in 1995 to develop concepts for increasing efficiency in sales, distribution, and service of Toyota cars.
The whole chapter is brilliant and highly recommended reading (and so is the whole book.) But what really struck me was the clarity those people at Toyota had about what’s what.
After building up on a whiteboard, step-by-step, a visual representation of how everything is connected at the company, the senior manager turned to the researchers and said:
”Our values define how we should be, regardless of the situation or context. Values are the basis for our very existence and the state towards which we continually strive.
Our principles define how we should make decisions and what we should prioritize. Just-in-time and jidoka define the direction in which our operations should develop. Towards the customer! Towards that beautiful tree!
The methods define how we should perform different tasks. Methods are the motors that propel us in the right direction.
Tools are what we need to have and activities are what we need to do to realize a specific method.
Everything is connected in a system that, continuously and in small steps, develops our business into a very beautiful tree.”
We have a tendency to copy methods and tools because it’s easier, and because our brains are wired to not only pattern-match but to think linearly in cause and effect. If this, then that. We generally prefer to use analogies rather than to think using first principles.
And when workplaces have a million things in progress, with most people stressed and anxious out of their minds, many fearing for their jobs in the current environment… no wonder we try to bypass as much thinking as we can.
Thinking is hard, as the saying goes.
But the paradox here is that while we should absolutely get inspiration and learn from others, we need to come up with our own methods and tools—if we want them to be effective in our context.
Toyota is an incredible, durable company because it started from values it never wavered from even when—especially when—it was hard. It understood that it needed to define principles that constrain decisions to be aligned with those values. And it understood that methods and tools are nothing but the embodiment of those values and principles.
Interestingly, as I also learned from Modig and Åhlström’s book, this is so transparent to them they don’t even call it “lean.” That is a concept foreign to them, a label created by Westerners who have studied Toyota over the years trying to understand and bottle the magic.
Tribes & Squads (And All The Rest of It)
So, back to Spotify.
You’ve surely heard of Spotify’s famed “tribes & squads”. But did you ever wonder why they designed their organization that way circa 2012?
The reality is that the famous Scaling Agile @ Spotify document by Henrik Kniberg & Anders Ivarsson itself doesn’t shed any light on that all-important question. They themselves just presented the end result, and marketed it extremely well:
But looking from afar, and knowing a little bit of Kniberg’s work at least, I suspect these people were already well-versed in complex adaptive systems, value streams, flow efficiency, and also understood the psychological and neural implications for good communication and collaboration design.
For now, I’ll leave it at that.
And, if nothing else, I hope this post helps you question why you’re doing what you’re doing and what it is serving. It might be the right thing to do. But then again it might not.
Thinking not optional.
Any resemblance to how consulting companies earn their living is… purely coincidental?
In the general case I think you're right.
However, org templates can be useful in the very early stages to avoid arguments over process. For example, you find people coming from Companies A, B, and C. They may have very strong differences of opinions and find themselves wasting a lot of time arguing over structures that the company isn't even ready for yet.
It can be helpful for very early leadership, such as the CTO, to say: "For the first year we're adopting these specific patterns -- we'll pursue these by the book with no adaptations. At the end of the year we'll retro, inspect, and adapt."
Yes! We did something similar in my past; less Shopify-style explicit, more Autonomous Teams. There needs to be some infrastructure for orgs to make that transition.
What's super valuable about your graph—from Values to Tools & Activities—is that it provides a visualization the elements to define that organizational infrastructure & processes. It loosely resembles a tree-diagramatic version of Pace Layers, too. Super cool.