John Rauser

Hey everybody. Hi. Thank you for joining us. Welcome to the final breakout session of day three of ETLS 2024. Bring it home with the Breakouts.

Steve Pereira

That's right, that's right. After this, there are a couple cool things happening. I'm gonna be leading a Birds-of-a-Feather Gen AI thing. You wanna plug your thing?

John Rauser

Oh yeah. I'm running a workshop on value-stream mapping. You should all come too.

Conversation

John: So last year Steve and I were sitting down to lunch at the DevOps Enterprise Summit, talking about things we like, and we found out that we are kindred spirits in a sort of way — aren't we, Steve?

Steve: In many ways, but in one very strong way.

John: Steve and I both look for adjacent domains to find isomorphic ideas that we can apply into our context and see if they can help us with what we're doing. And one of the places that we both investigated and connected on really quickly was the application of computer-networking principles to organizational networks — organizations as networks, I should say.

So, um, I work for Cisco, the largest networking company in the world. Steve?

Steve: I work for Visible Flow Consulting, so I'm always interconnecting all kinds of things and trying to visualize big systems of communication.

John: That's right. And he also wrote the book, Flow Engineering, which talks about how to achieve flow.

Steve: Well, it's really all about enabling communication and workflow across silos and complex organizations, right? At scale.

John: That's right. And we are also reading Gene's book, Wiring the Winning Organization. So we're looking at how we can bring these things together. And so we're gonna tell you a bit about that today. And here's the deal: we're not selling anything. We don't have any agenda. We're just here because we love this. This is fascinating. It's exciting. We want to tell you about it, and we want to hear what you think.

Steve: That's right. It's an invitation.

John: Okay. First of all, interactive part. Who knows what that is? [shows first internet diagram] Put up your hand if you know what that is. This guy knows. This is the first internet.

That's right. Round of applause — you get a prize. You get a book, actually. There is a book for you at the back of the room. Now you're gonna be perking up, aren't you?

So the very first internet — you have four computers that are joined by these giant message processing things the size of a fridge. The very first computer network got packets flowing. And this thing became an absolute game-changer for the entire world. I would say it's one of the most impactful technologies ever — the most widely deployed technology ever.

[next slide: blank, then global BGP backbone visualization]

So the internet — it grew and it grew, and it grew more, and it grew more, and it got even bigger. And it got this big. This is how big it got. What is this? This is the global BGP backbone. If you don't know what that is, don't worry about it — that's not what the talk's about. The global BGP backbone of the internet. This is the invisible network that's connecting all the networks.

This thing — have you ever seen one of those pictures from the Hubble telescope? And you look at it, and it's a deep-space picture, and there's all these dots on there, and you realize all of a sudden that they're not stars — they're galaxies. You look at that picture and holy smokes, those are galaxies. You thought they were... This is what this is like. These aren't computers. These are galaxies of networks. Networks of networks all combined together, passing packets all throughout the world, connecting everything you do.

I'm telling you folks, this is very cool stuff. I think you knew that already.

So the cool thing about this is that it evolved. It evolved by people trying things, people making mistakes, people doing things, taking action, learning from that action, and then adjusting, course-correcting. It's empirical. And we love empiricism here, don't we? Who said yeah? Give a book.

It's empirical, it's evolutionary, and it scales. It is the most scalable technology we've ever seen. It's resilient, it's diverse, it's all these things.

Now, I wanna tell you something cool and interesting. Back in the 1980s, we had this thing — some of you may have heard of it. It was called the Great Congestion Collapse. The internet started to slow down. It started to get sticky. It started to gum up. It started not to work anymore. Packets couldn't make it to the other side, they'd get latency, they wouldn't even make it there at all.

Sounds like something else that we work on. System problems that we think about. Systems that slow down and get gummed up and work can't move through it. What do you think, Steve?

Steve: I think you're totally right. We talk about this a little bit in Flow Engineering — the challenges of scale and collaboration at scale, and the things that happen when you scale up and you have incredible diversity and incredible interconnections between collaborators, systems, points of entry, points of exit, all of this diversity through systems.

And when we think about Wiring the Winning Organization, Layer 3 is by far the most important layer — but it's the one that we understand the least, right? It has all of the complexity, all the diversity, all of the fuzzy, messy, humaney stuff that is so hard to quantify, so hard to manage, so hard to wrangle.

So organizations are constantly struggling with scale and variety, right? Different perspectives, different goals, different understandings of scope, different time horizons. You have one person thinking about next quarter, someone else thinking about five years in the future, and they wonder why they can't communicate with each other.

We have incredible diversity of communication. We need clarity and alignment between different people saying different things at different times. And then we also have this challenge of information and work being incredibly diverse. And we struggle to quantify it, measure it, trace it, visualize it, and zoom out and zoom in at proper levels that help us understand what's going on at any given moment.

So what does this mean when we think about organizations as networks — having all this work traveling, all these messages traveling, all this communication traveling back and forth from external customers to internal customers, to stakeholders, individual contributors? All of these pieces of a network.

It's not really nice to think about people as nodes in a network, but if you think about teams as nodes in a network — an autonomous unit that's deploying a capability or providing a capability — then you have all these possible endpoints. You have all kinds of complexity in how those are interdependent on each other.

So this model, like all models, is wrong but very useful, right? It's very helpful to think about organizations as networks. Because when we think about the internet, we think about all this diversity that's possible — all these different devices, all these different methods of communication and consumption and production that are enabled by these simple technical pieces, interconnected in different ways. And ways that we don't leverage in our organizations today.

So when we think about the complexity that's present inside of our typical organization, we can think about this kind of unstructured network where you have varieties of scale. We can zoom in and look at what are the value streams that are delivering these capabilities that are consumed and produced by various groups, and how that is part of a large and rich and diverse network of communication and work and outputs and inputs.

You can actually represent this in many, many different ways. We've run organizational networks through Euclidean geometry, Cartesian planes, so you can plot these in multiple dimensions. You can use gen AI to generate them and interact with them and run simulations about how they might behave differently in different ways.

And there's a couple of things that are really challenging from a principles and concepts perspective that we have to think about when we're thinking about how we wrangle this complexity of organizations. A couple I want to call attention to.

How many people have heard of Ashby's Law? Probably not so many. And more people have heard of Conway's Law.

John: You don't get a book for that one, sorry. Books for everyone — no.

Steve: So requisite variety is really interesting. It basically says that if you wanna manage a complex system, your system of management has to be more complex. So what does that mean? That means we have a lot of complexity to manage, and we tend to create more complex systems to manage our complex systems. And Conway's Law — meaning that all that complexity then gets manifested into the things that we build.

So if these things are true, we're kind of screwed unless we find ways of simplifying our understanding of systems, simplifying systems. We need to enable control of systems without constraining them too much. And we need to manage complexity without reducing our optionality. We have to create internets that are capable of doing things that we could never really imagine, and have them be scalable, resilient, and highly reliable.

And the problem is that people are infinitely variable, right? They have incredible diversity. They contain multitudes.

So we have a couple of trade-offs that we have to manage. We have scaling: communication and variety require different ways of communicating to prevent a total overload, right? We can't all speak everyone's unique language. We have to have common languages. We need common ways of coming together. We need ways of converging and distilling all that complexity into something that we can actually grapple with and leverage.

So tell us a little bit about how this looks in terms of a structure — what we're borrowing from networks.

John: That's right. That's exactly what I'll do, Steve. So I'm so glad.

The question we have is — we need, we know we need all these things. We have all these things that we need to get out of our systems. The question that we have is: are there things that we can learn from computer networks? Lessons that we can take away from the Great Congestion Collapse? Structures, architectures, things that we can use and apply here?

So I'm gonna ask you a question. This is for a book. [shows slide with four black rectangles] What is that? Who knows what that is?

Black book. That's it. Four black rectangles.

Side note: it is impossible to get ChatGPT to generate you four black rectangles. It will not do it. Try it — it will not do it. And then you will ask yourself, "why am I asking ChatGPT to generate four black rectangles?"

Anyways, what we're looking at here is a layered model. And that is exactly what the internet is based on. The internet is built on this idea of layers — layering functionality, layering the things that make the internet work and separating those out.

Question for the audience: does anybody know why? What do we achieve when we use a layered model? Abstraction. That's right — we get abstraction, modularity, simplicity.

But in simple speak — because I'm a simple man — in simple speak it's just: the things at the top don't have to worry about what the things at the bottom are doing. Imagine if your applications — if Chrome or something like that — had to care about the fiber that's being run. Is it on copper? Is it on fiber? Is it on wifi? They don't have to care. That's the beauty of a layered model. You have to do things up here that don't impact the things down there at all.

But so the internet is built on this. This is the fundamental principle of the internet. You've heard of the OSI model. There's various different ways of representing this, but the key thing is this: you don't just use a layered model. There's something that's really important when you use a layered model. And that's to introduce what is called a spanning layer.

So we don't want to have a lot of complexity in what's going on in the middle. There's a large infinite number of applications. There's a multitude of different ways of carrying packets on a network. But we don't have a lot of ways of putting them on the internet. Who knows what TCP/IP is? Of course, right? That's how you put things on the internet. There's only one way to get things on the internet. It's really IP. That's the thing. If you have an IP address, you can get on the internet. If you don't, you're getting on some other network — but it's not the internet. That's the thing that makes this work. There's just one way.

Then the transport layer — there's two ways, maybe three. TCP, UDP, right? So again, simplicity of that layer. We're making sure that the applications don't have to worry about what's happening in the middle. And we're actually using a constraining force to achieve that.

So the question is: how can we use this hourglass model in organizational networks?

Steve: Sure. So when we're thinking about our organizations, as we mentioned, we have all this diversity of optionality — things that we need to do, things that we need to accomplish, deliver to our customers, respond to, consume, understand, synthesize. And then we have all of these kind of capabilities. We have systems, we have things that we can use to satisfy those needs.

And if we were to try to connect each one one-to-one, via their unique characteristics, and try to map them together, then we quickly get overwhelmed by trying to connect everything to everything else. So we need to use these common communication protocols, these common mapping paradigms. We need to collapse complexity down to something that allows us to traverse that distance and map all the diversity at the top to all the diversity at the bottom without impacting the diversity. We want that diversity at the top, we want it at the bottom — we just don't wanna have everything talk to everything in their own special way.

John: That would require everything to understand everything else, right? If you want to talk to everybody on Earth, you have to learn everybody's language. And if everybody has a different language, you're not talking to anybody, basically.

Steve: So what we also see this represented as is differences in context. So we can have business and tech, right? What allows business and tech to collaborate effectively? Because they don't, by default, speak the same language. They don't by default understand each other's context. So they need a spanning layer. They need something that allows almost like a Rosetta Stone — where they can come with their context, I can come with my context, and we meet and we're able to pass information back to each other, or work or artifacts or anything that needs to traverse the network.

So what happens with the hourglass model today? How do we see this represented? We talked about IP. You could think about gen AI prompts as a way of spanning complexity. So all possible things that you could want a response to, and then all the collected information that's present in the large language model. Use a prompt to kind of condense that down, and then go and get it and bring it back, right?

The human brain has this between the left and right hemispheres — that Andrew talked about yesterday. This is a spanning layer. This is something that allows the left and the right brain to collaborate and work together. They speak across this very narrow connection that bridges the gap between all the things that this side cares about and the other side.

And then you can think about, like Gregor talked about in his platform talk yesterday, an auto chassis platform, right? If you have an auto chassis platform, it can be used for many different models of cars. And that chassis can drive on any type of road surface, right? So you have this common platform that allows you to consume and produce diversity at either end without trying to create the perfect car for this road, the perfect car for that road, the perfect car for every road.

And then developer platforms are another way of witnessing this in the wild. You have the ability to deliver any number of technical capabilities and products based on common tools and capabilities that are collected into a pipeline that collapses all that complexity down and abstracts away all the complexity that's underneath that platform.

And then the last one that I'll mention is things like weekly business reviews, quarterly business reviews, like the Amazon six-pager — being representations of things that can bridge the gap between business and tech, right? Business doesn't care about every single technical detail of what's happening, but they care about maybe a few metrics, or maybe a statement about status. And so these are mechanisms that are serving that purpose of bridging the gap, and collapsing down that complexity, and modularizing, and abstracting away all the detail that doesn't really matter to the other end of the network.

John: So it's worth noting that you see the hourglass model rising naturally in lots of systems. You pointed out the brain, and there's tons of other examples in biology, physics. It's really interesting that you see this showing up everywhere. And then you see it showing up just by chance — it just happened to evolve that way. And I'll just call out, with the internet, there's a very deliberate decision to introduce the hourglass model in that layered model. It was a choice that was made, a design decision that was made, in order to capitalize on what we're seeing in nature — just out in the world, hourglass model operating all over the place.

Steve: Yeah. So I think an important thing to bring up here is that this is not a new concept. This is not even a new concept to you. You do this. Everybody does this all the time. We're constantly doing this abstraction and simplification. But oftentimes what we do is we do it implicitly instead of doing it explicitly — like by design. We don't intentionally design these things for these purposes of abstracting away complexity, which means that we don't always do the best job at it. And sometimes it makes sense to us, but it doesn't really make sense to other people, because we haven't really created an ideal spanning layer, an intentional spanning layer, that serves a very direct purpose.

So there's some things that are also factors in large-scale networks that we also have to grapple with in organizations. And thinking about how they're handled in the internet and in computer networking, I think, is very, very valuable. So we have things like CAP theorem, where we have to balance between consistency, accessibility, and partition-ability. We have to understand trade-offs, and we have to leverage these choices in order to get what we need out of the system. And we can't have everything all at once. So we, again, have to be intentional about how we design these things in order to maximize the performance of the network and take acceptable compromises.

Another one: quick, cheap, high quality. This is something where you can't have everything all the time. So we have to be intentional about our choices and our compromises to get the best results.

Then another one — specifically about networking, which comes from the book that kind of inspired a lot of this thinking about spanning layers and more stuff that we can't even tell you about that we hint at in the paper and we're still exploring — things like convergence, stability, and then simplicity of a control plane. Basically getting to that Ashby's Law of being able to manage complexity. So this is beyond scope, but this is sort of the stuff that we're kind of getting into, and really excited about exploring.

John: That's right. So tell us more about examples of layers.

John: So to kind of finish things off here — and we are focusing a lot on this idea of the hourglass model today, and like Steve said, there's so many other things to explore — but the purpose of this talk is to get you interested, get the motor running in your brain, and then have you reach out to us and talk more about this.

So I just wanna give a tangible example now of the hourglass model and how we actually implemented this in my organization to control the complexity around planning. We made a deliberate decision. We thought about it in this way. And here's the thing: the hourglass model, like I said, is gonna show up naturally, and it probably shows up naturally in your organizations in the way things you do. But when you think about this intentionally and deliberately, you can get so much more out of it.

So this is my sort of model — a very, again, four-rectangle model — of how we arrive at what we're gonna do in our organization. We have a multitude of stakeholders that are asking us for things. They're customers, it's security, it's the developers. Everybody's asking us for things: "can you do all these things?" And we try to put them into roadmaps, and then we get those roadmaps into planning, and then the teams work on the plans. So kind of a simple way of looking at how work works.

And so if we were gonna apply and use hourglass-model thinking here, what would we do? Well, we would introduce a constraint. We don't wanna have to have all the teams working with all the stakeholders all the time, trying to figure things out — constant thrash, constantly not being able to arrive at sort of a standard plan.

So what we do is we introduce a constraint at the planning layer. And we deliberately constrain the planning into a certain cycle. You probably have a cycle in your organization. You're not thinking about it like this yet, but you have some kind of planning cycle where all the planning takes place and it happens at the same time.

So in our organization, we use a quarterly planning cycle, and we think about it in this way. And actually I presented this to the program committee and to our internal stakeholders who are involved in the planning cycle, and showed them this hourglass model. It was actually like an aha moment for them. Like, "we want this — we wanna have a constrained planning cycle."

We're gonna have more roadmaps that are feeding into that planning cycle. A ton of stakeholders, as usual. But we don't have to — the stakeholders don't have to worry about the teams. They only have to worry about the layer below them. The stakeholders have to worry about the roadmaps, the roadmaps feeding the planning. The teams will have to worry about the plans.

So you get this clean separation. You get some modularity in how your work works. And when you think about it in this way, it works really well. We've had a lot of success with it, and we're just getting better as we think about it this way. What are the interfaces between these things? There's so many things to think about when you start applying more networking to this. What are the protocols between these things? The interfaces, and so on. What should the architecture look like? How should things be connected? There's so much to explore.

Steve: Yeah, it is so exciting. What about error correction, everybody?

John: There's so much. So I hope that you're getting excited too by this, because we certainly are. And so that's just, you know, one example of a tangible real way that we can improve our systems by looking at these other systems.

Now, going back to Gene's model — you wanna touch on this one here, Steve?

Steve: Sure, I mean — really what we're, I know, right? We rehearsed so many times. No. So really what we're trying to do is introduce new models and tools for considering Layer 3 — this most difficult, most complex, least scalable aspect of this layer model — right? The three layers of Wiring the Winning Organization.

You know, it really gets challenging at Layer 3, and we're really in early days of defining these protocols and practices and instrumentation that can help us grapple with all this complexity. We have things like value-stream management that can help us see the end-to-end flow of all the activity that's happening, along with the metrics of how those activities are performing and how much delay is in the system, and what are the quality impacts and what is the value implication of all that activity and the outcomes of what's produced. And we're in very early days of that.

So I think that hopefully we can bring you in at these early days and you can be a part of building this with us. We would love to have you along on this journey to share your perspective, because — as John mentioned — there's so many aspects to this to play with. And we're really excited about getting into... like, don't get me started on talking about control planes. I'll talk about control planes.

John: Oh yeah. For days. It is like my new favorite thing.

Steve: It's heaven. It's heaven. Control planes are heaven.

I feel like I'm just like — you know, a geologist who comes out of a desert and just starts talking about fossils, and everyone's like, "what, why? I'm gonna go get a latte."

But I don't know, this I think will really produce a lot of interesting material for us to put on a different lens and look at Layer 3. And that's kind of the idea.

John: That's right. And so you can have the idea too by reading this paper. Go ahead and download it. It was published in the DevOps Enterprise Journal, last year — earlier this year — which is now called something else now. So download the paper, read it, reach out. There's a couple things you can help us with. I think we touched on them mostly, which is — where do you see these patterns showing up in your organization? Gaps that, from what you've heard today, maybe other gaps that you think this thinking could address. And a lot of keywords on the side here to explore — those ideas that we'd like to explore together that are just fascinating. So come along for the ride, reach out. I'd love to hear from you, and thank you very much.

Steve: Thank you so much.