In 2017 I gave at talk at the DevOps Enterprise Summit and described a sort of frame that my colleagues outlined in the Stella Report. I walked through it bit by bit, and I’ve captured just that 6-minute excerpt in this video here.
However – not everyone likes to watch videos of conference talks, so below is this walkthrough in notes/slides format, thanks to Dan McKinley’s “better keynote export” script. (You can click on the images to get bigger and more legible ones.)
| So first I want to start with a little bit of a baseline, a bit, a bit of a vocabulary that’s going to be important as I sort of walk you through this. I’m going to describe a sort of a picture or representation, like a mental model of your organizations and it’s going to have an “above the line” region and a “below the line” region. # |
 |
| So we’ll start with this. If you imagine what we have depicted here (don’t worry about it being a “cloud”) this is is your product, your service, your API or whatever that your business derives value from and gives to customers.
And inside there, what you see is your code, your technology stack, the data and some various ways of delivering this – presumably over the internet or some other sort of sort of way. Now, but if we stay here with this description, nobody’s going to believe me that this is what we call “the system” because it’s not really complete… |
 |
| What’s connected to this — and I think what’s really what a lot of people have been talking about here in this community — is that all of the stuff that we do to manipulate what goes on in that first bubble.
And so here we have testing tools, we’ve got monitoring tools, we’ve got deployment tools, and all of that. These are the things that we use and you could say that this is “the system” because many of us spend our time focused on those things — not just what’s inside the little bubble there, but all of the things that are around it. But if we were to just stay with this as “the system” we wouldn’t be able to see where real work happened… |
 |
| So what we were going to do here is this: we’re going to draw this line — a line that we call the line of representation — and then if play with this a little bit further, what we see here is you – all the people who are getting stuff ready to add to the system, to change the system, people doing the architectural framing, the monitoring…all of that.
You’re keeping track what the stuff below is doing, how it’s doing it, and what’s going on with it all. Now you’ll notice that each one of these people have some sort of mental representation about what that stuff is and if you look at it a little bit more closely, you’ll see that none of them, none of them are the same. By the way, that’s very characteristic of this scenario – nobody has the same representation of what is “below the line.” |
 |
| So to summarize, let’s zoom out a bit. Your product or service is here in the blue area, the stuff you build and maintain that is here in the yellow area, and in the green is where the work actually happens. # |
 |
| This is our model or frame of the world and includes not just the things that are running there, but all of you: the kinds of activities you’re performing and the cognitive work that you’re engaged with to keep that world functioning. # |
 |
| Now if we elaborate a bit more, we end up with this kind of model. The model has a line of representation going through the middle, and you interact with the world “below” the line via a set of representations.
Your interactions are never with the things themselves. You don’t actually change the systems, per se. What you do is interact with a representation, and that representation is something about what’s going on down below. (You can think of those green things as the screens that you’re looking at during the day.) But the only information that you have about the system comes from these representations. They’re just a little “keyhole” into what’s happening. And what’s significant about that is, all the activities that you do, all the observing, the inferring, the anticipating, the planning, the reacting, the modifying, has to be done via those representations. There’s a world “above the line” and a world “below the line” and although you and we mostly talk about the world “below the line” as though it’s very real, as though it’s very concrete, as though it’s the thing, in fact, the big surprise is this… |
 |
| You never get to see it — it doesn’t exist.
In a real sense, there is no “below the line” that you can actually touch. You never, ever, see code run. You never actually touch those things. What you do is, you manipulate it in a kind of … it’s not an imaginary world, because it’s real — but you manipulate a world you cannot see via a set of representations. And that’s why we need to build those mental models, those conceptions, those understandings about what’s going on. Those are the things that are driving that manipulation — it’s not that world “below the line” that’s doing it, it’s your conceptual ability to understand the things that have happened in the past, the things that you’re doing now, why you are doing those things, what matters, and why what matters, matters. Once you adopt this perspective, once you step away from the idea that “below the line” is the thing you’re dealing with, and understand that you’re really working “above the line,” all sorts of things change. And what you see in the Stella Report and in our chapter in the Seeking SRE book is to try and explore some of those changes, and understand what it means to really take the “above the line” world seriously. This is a big departure from some of the other stuff that you’ve seen, but it’s what we think of as the sort of starting place for the work that we’re doing. |
 |
| In other words, these cognitive activities, in both individuals and collectively in teams, up and down an organization, are what makes the business actually work! Now we’ve been studying this in detail for some years now and I can tell you this – it doesn’t happen the way people — including those closest to the work — think it happens. # |
 |
| And finally, the most important part of this idea is this all changes over time. The mental models, the formation of those mental models, the making sense via those sets of representations…this is a dynamic process that is ongoing and continually being re-calibrated over time.
This is the “unit of analysis” that I want you to have in your mind for the rest of this talk.# |
 |
| Now with this sort of frame, we can ask questions like … – How does our software work, actually? – versus how it’s described in the wiki and our diagrams? (because we know they’re not comprehensively accurate) – How does our software break, actually? – versus how we thought it would break when we put in all those failsafes and guardrails and monitoring? And the most interesting to us (and it should be to you all): what do we do to keep it all working? |
 |
This is what we do at Adaptive Capacity Labs: we have the expertise to look “above” the line, in deep ways.
How adept are you at understanding this? We can help.
Want to understand how to apply empirically-supported methods of understanding what happens “above the line?” We can teach you.
