(2024-05-12) Cutler Sociotechnical Maestros With Gene Kim

John Cutler: Sociotechnical Maestros with Gene Kim. I recently finished reading Gene's latest book Wiring the Winning Organization which he co-wrote with Steven Spear. The themes of slowification, simplification, and amplification have already started to seep into my day-to-day conversations. The book is filled with case studys, but also creative metaphors like Gene and Steven moving a couch, which is where our chat starts.

I stumbled on the chapter about simplification. And as someone who talks about the beautiful mess and how we often oversimplify I found myself initially resisting the framing. And so I was curious how you would explain it to someone if they're interested in the difference between simplification as you laid it out in the book and maybe the trap of oversimplification.

90 seconds of performance art around the couch metaphor... you might think that this is all brawn work

Just by picking up the couch, fast trial and error, um, but most importantly, communication coordination, we can have some confidence that Steve and Gene will be able to achieve what they want to do.

But there are all these things that we can do as leaders to make their work more difficult.

We can turn off all the lights

introducing a lot of, uh, noise, loud music, or even introducing an intermediary, where Steve and Gene can no longer talk directly with each other

we can imagine scenarios where they will not be able to achieve their goal. So it's so interesting, right? We haven't changed the nature of the couch. We've actually changed what we call the Layer 3 wiring.

So to your point about simplification, I can now, I feel like, you can now characterize almost every organizational sort of dynamic through the couch.

It's either, the couch is like coupled to too many people, say 1500 people at Amazon, where like even small actions require like superheroic effort of communication, coordination, escalation, cajoling, politicking, you know, daily war room meetings, because no one has independence of action. So Amazon is a great example of this that led to the thou shalt use APIs. But it can also explain, I think what could be viewed as mutually contradictory, like in 2023, that prime Amazon prime video article where they said "We went from microservices back to a monolith." And reduced cost by 95%. And I feel like the couch metaphor explains that as well.

The phrase I learned working with Dr. Steven Spear, you know, famous for his work in the Toyota production system, was the word independence of action. (agency?)

So the question I now I'm starting to phrase and ask is how much would you pay to gain independence of action, right?

And I think the answer is a lot, right? And there's even a whole hing about economic theory, the whole option theory, was that how much would you pay to be able to defer a decision, right? That was Merton, Black, and Scholl. So it's like, it turns out a lot, right? Because if you can defer a decision, it creates optionality.

How does your advice to companies differ based on whether they are this sort of complex mega brand that doesn't sell digital products versus maybe, you know, an upstart newly public tech company.

we're all the same now, right? I mean, if you talk to someone at Spotify or LinkedIn or Shopify or an Amazon, they have the same socio-technical problems as, anybody else. you know, large, complex organizations like Barclays have been around since 1695

a couple of examples in the book, that there is an element of culture in the companies that are actually able to refactor while the train is barreling down the tracks

Dr. Ron Westrom, famous for his work on culture-- we leveraged his work so much in the state of DevOps research with Dr. Nicole Forsgren and Jez Humble--but he also introduced me to the term, the socio technical maestro. And it's like five things, high energy, high standards, great in the large, great in the small, and they love walking the floor.

you need that in large organizations and small. Not just at the very top, but, you know, at every layer in the organization

And I think what that does is it, is this constant quest for greatness and meeting a high standard leads to this need to have a lower cost of change.

one of the key nerdy aspects of the Toyota production system is they make small changes all the time in the context of daily work, you know the andon, the number of routing changes and so forth, and it's not being done from the home office. It's being done by everybody all the time at high frequency.

how we perceive time in the sense that I don't know if many people can even wrap their head around a decade's worth of change. Most people aren't there for a decade.

Fernando Cornago, he's VP of Digital at Adidas. And the story started for them after they heard Jason Cox from Disney present in terms of how they built internal platforms and what was their sort of like staffing model and how they saved the day for business units. And so what that led to was a certain meeting, I think at like 2 AM, by the elevators at this hotel lobby where they finally got what they wanted. They approved, you know, the top five business units agreeing to donate, or give 300 of the best engineers to create this shared centralized capability.

• When the pandemic hit in 2020, Adidas had to rapidly pivot. With physical retail largely shut down, e-commerce became the primary sales channel overnight. The investments in digital infrastructure paid off, allowing the company to meet the sudden surge in online demand.

if you're not able to at least understand that you're making some incremental progress, that part of the feedback loop, it can be very, very difficult to sustain that effort

imagine a two by two and on the bottom, it's work, small work, big, and the other one is think big and then think small. And if you're, if you're working big and thinking big, it just takes forever.

one of the most unsung stories at Spotify

getting ready to go public, they would have essentially have to start showing effectiveness controls for how they deploy software.

every team deployed software differently using different tech stacks

led to this initiative to create a shared service around, uh, deployment and so forth.

One topic that comes up a lot in the product community is the idea of empowerment. An observation however, is that the strategy is in place and people are relatively excited about it and the architecture is the blocker. The empowerment people really need is more structural, it's more architectural.

When you have like empowered teams that don't understand the goals, they are pivoting and iterating to oblivion. (Agility, Context, and Team Agency)

How much would it be worth to create the system where everyone has genuine independence of action, where every one of these capabilities is self service? And I think, for Amazon, I mean, it allowed them to not just thrive in the eCommerce capability, but those capabilities arguably, led to so much option value that it became AWS

what we're observing is this kind of co evolution or convergent evolution of, practices that show up in startups, that shows up in tech giants, that shows up in enterprises. You know, things like shifting left.

So it means decoupling from the security function

It means decoupling deployment away from the deployment engineers

Similarly, you know, cloud, build your own VM's, anything where you can get self service on demand to enable decoupling that's happening.

So it means that we have to have this ever more sophisticated layer-three wiring, in our organizations. And I think this explains why we have this kind of convergent evolution

you maybe get this pendulum swing between solidifying around how things are working. But then when there's some element of disruption you have to expand out and take a bigger view.

For an internal combustion engine, there's actually no reason for the battery team to talk to the brake team. They can work totally separately. Even if you put them in the same room, they have nothing to talk about. But an electric car, right? Like now they need to be talking all the time. In fact, they have mutual dependencies for fuel efficiency, regenerative braking. You have to reconfigure systems so they can actually talk to each other

One story that comes to mind there is Brian Chesky recently did this interview about Airbnb. That almost perfectly describes the pendulum swing, right? It's, it's Airbnb... it hits the pandemic. And then it forces them to think about, " Oh goodness, we have an end to end Airbnb experience. What, what have we done here? Why have we created all these competing teams?" And it turned out they had way, way, way more dependencies than anyone would care to admit. And I've noticed that a lot in tech companies is that, when things are in the ascension, people downplay the dependencies because they don't want to necessarily contribute to the collective good... super high WIP, there's all these dependencies, and then he needed to kind of exert this top down shock to the system to reset it back in that direction. ((2023-11-14) Brian Chesky's New Playbook)

But one could imagine that this pendulum swing will go in either direction.

thinking about feedback loops.

wouldn't it be amazing if there was some way to detect when, like, the wiring is no longer working with us

you just convinced me. These are the exact same concepts on orthogonal planes. One is on the product. One is, you know, you have the product, you have the process and you have the organization and architecture. What you can do to one, you can do to the other two

I asked Jez what was your biggest aha moment writing Lean Enterprise? He answered right away. He said, " The same sort of experimentation that you do, like with Lean Startup and pivoting and so forth, you should do to your processes as well." (Gardening Your Product Process)

And you should be able to do the same thing with your organizational wiring.