[Note: please be advised that this transcript contains strong language]
Transcript
Swetel: I'm Cat Swetel, I am an engineering manager at Ticketmaster. Who in this room has heard of Wardley Maps? People who nod knowingly at this, you've seen Simon Wardley's intro to Wardley-mapping talk. People who are not nodding and have a look that's a mix between being frightened and amused, if you would like to generate a strategy, there's an app for that. I invite you to go do that now.
Of the folks who said that they have heard of Wardley Maps before, who has actually mapped something? Yes, that's how it always is. It's a much lower number. I have good news for you, the map is not the thing. You can draw a map, and then, just throw it straight in the trash, that's totally fine; so you should draw your first map today.
I'm not going to teach you how to map in the course of this really, even though I think that's what John [Willis] invited me here to do, but now that I have the mic, I can do whatever I would like to do. Thank you for that. I'm just going to tell you the story of how I came to work at Ticketmaster, and then the story of my first year and a half there.
This is a couple years ago now, I am sitting randomly at a museum in Canada and I get a phone call and it's a friend of mine that I worked with previously, and he said, "How would you like to come work at Ticketmaster?" It's like, "I'm good." Then he said, "We'll have a couple words for you, Cat [Swetel]. Emulated VAX." I said, "Ok. Where do I sign?" That's how I came to work at Ticketmaster. Why did I sign up for that? I think Wardley would tell me that I am a settler. You don't have to read this whole thing, you can go read it later. One of the weird things about Wardley is that he is an old man who lives in a swamp and he believes that intellectual property is not a thing and you should just give away all of your thoughts for free. His whole book is online there, and you can just go read it at your leisure. I like the bottom part there that says that settlers, in this model, we have pioneers and they would be the people who make a 3D printer out of Legos. Then, the settlers would be the one that would take that 3D printer made out of Legos and say, "How do we actually turn this into a thing that people can use, and people would want to buy and all of that stuff?" I think that's where I like to be and that's why I'm fascinated by an emulated VAX.
This is a VAX, but it's not running VMs. Whenever I tell this story, people are, "So you love VMs, best operating system ever?" No, it's not running VMs. In fact, the people at Ticketmaster say that VMs stands for "VAX made slow." At this point, you're saying to yourself, "Cat [Swetel], where do you get parts for a hardware VAX? That seems like a tough auction on eBay." You would be so right about that because you would be bidding against the federal government and I hear they have kind of deep pockets. It's not a hardware VAX, it's an emulated VAX. It is a VAX, an emulated VAX, custom emulation and a custom operating system. We have this VAX but it's custom emulation, custom operating system.
Evolution
If you're not familiar with this, it's the X axis of a Wardley Map and it's the evolution axis, so it goes from Genesis, these things that we have no idea what they are, if they're even going to pan out. No one has any idea. Then it goes all the way to commodity. I use the word custom about a bazillion times in my overview of the platform that I manage, so I think you can tell that it's custom.
Anyone know what this is? We're in the Wayback Machine. I've now alienated all of the audience except for two people. I hope the people with the reading pads are ready for this one. This is a PDP-11, and the original Ticketmaster software was programmed on a borrowed PDP-11 in the 70s. I'm 31, so this is a real adventure for me. Anyone familiar with Conway's law? One or two people at this conference, I think it's the most cited thing here probably. Since Conway wrote his law, he's actually continued to think about things, and this is one of the things that he has thought about. I think it's a wonderful way to describe the evolution of the industry that we probably all work in. Why is this a custom operating system written for PDP-11, and then, a VAX? Because of the specific time in which it was born. I pointed out that that says, "Computer ticket service." Why is the word computer in there? Because in 1976 you don't take computers for granted. There may or may not be a computer present in any of these businesses. That's when Ticketmaster was born, it was born at the liminal state between this period in our industry where you weren't selling software - selling software was not a thing - you were buying hardware, and then, you employed programmers who programmed that hardware, and then, shifting into this model of you can purchase software that was built by professionals elsewhere.
At this point, the folks at Ticketmaster, the original founders, they were saying, "We think computers are going to be a thing." Yes, bold prediction. They were counting on the fact that computers would become more ubiquitous and you would have computers in a venue, or in a record shop, or whatever the case may be. If that's going to be the case, if computers are going to be ubiquitous, then a lot of the things that we do manually today we would do with computers in the future. That's the bet that they were making and they understood the needs of the ticketing space. They understood that VMs wouldn't fulfill those needs, that at this very unique point in history, they would need to make a custom operating system that could handle a bazillion people lining up to buy tickets, or whatever the case may be, and printing tickets and all that jazz. I won't talk about this a whole lot more, I'll allude to it, but Conway thinks that we're at another big shift where we are now empowering users to create the things that they mean, and we probably have all dealt with that in some respect. If we think about reporting, it used to be that a developer would develop a report, and then people would generate it. Now we've pushed that out to the users to create their own reports.
That's how we end up with a custom operating system, because at the time, it was the only move that made any sense at all. Now we think, "Why would you write your own operating system for that?" but at the time, it made perfect sense.
The first lesson here about Wardley Mapping is that we want to identify how we treat a component in our value network versus how the industry treats the same component. At that point, the industry wasn't fully treating computers as a product, something that you just buy, they were treating it a little bit more custom. You still have to put "Computer" in the name of the thing because people are still, "I don't know if that's going to pan out." Actually, one of the developers who is on my team right now, he fully admits that, at the time, he just was like, "Computers are not going to be a thing, this will be like a fun hobby for a short time." If we are treating a component in a different way on that evolution axis, so if we're treating something compute, if you have a beautiful baby server that you nurture and love with all of your heart, you name each one of them, they have a birth certificate. That's very different, you're treating "Compute" in a way that is much more custom or product. People who are using the cloud, or whatever else, they're treating it as a product or commodity. This could be an advantage. If you are betting on evolution, it could be an advantage. If you're behind the curve, it could be a disadvantage. It's important to just have a reason for the things that you're doing.
How do you know where whatever you're looking at falls in this whatever? You can look at this on your own time, I'm not going to read it aloud to you, but Wardley, and now other folks, have come up with these questions that you can ask yourself to say, "How am I treating this component versus the rest of the industry and whatever the case may be?" The component doesn't have to be software, it could be a practice, or it could be whatever else. That is nice. It's nice to have those definitions for that access. I still think it's difficult to understand sometimes.
If you're having a difficult time with this, I propose that you substitute the word "Conspicuous" instead of "Evolution." The things that are in Genesis, they stand out to you like a sore thumb, you don't even know what to make of them. They're highly conspicuous and you probably are saying, "I don't know how to use that, that's stupid," whatever the case may be, but highly conspicuous. How are you enjoying the electricity in this room? I'm enjoying it very much, it's working out quite well for me. Now, the things that are in commodity, those things only become conspicuous when they're not working in the way that we expect, and that happens very infrequently. The things that are in commodity are things that you take for granted. It's another way to think about that.
Minimum Useful Map?
Once you have that lexicon, I think that perhaps even just having those words and that shared understanding of what evolution is, that is the minimally viable math. This is a picture of Jimmy, one of the developers on my team. He can hold a lot more information in his head at any one time than I can. Much more information in that man's head than will ever be in my head at one time. When I first started working with him, I said, "I don't know how I'm going to do this. I can follow maybe 10% of what you say ever." What we decided is we'd have to come up with this shared vocabulary, and we use the Wardley Mapping vocabulary for that. Now, when I just tell him, "I'm completely lost, I have no idea what you're saying we should do next," we can come back to that language and he can explain the moves again using that language. I think even just having the words is a pretty good start at mapping.
This is a very high-level map of what we've got going on. You want to sell tickets? If you want to do that, you have to have content. People don't generally buy tickets to see nothing. You have to have tickets, those are pretty well-understood. We need to have that operating system, some way to sell the tickets, we have to have the actual hardware. Then you have to have reports so you know how much to pay clients and how much to pay the artists, or whatever the case may be.
Why did that man call me and say, "Do you want to work at Ticketmaster now?" Why now? Because Ticketmaster, at the time, and now, are going through a change that is affecting pretty much all of our industry and I think it comes back to this. This is Ashby's law of requisite variety. It says that basically, if you want to be able to weather the storm, you have to be able to meet the individual needs of consumers in your market, or businesses within your market. You have to build a channel that is capable of supporting the diversity that exists within your market.
We want to invest in absorbing variety from the market. We have just one big bag of money to invest across the entire firm. I think when we're looking at investment, we're looking at investment in two different types of activities. The metabolism, I talked about metabolizing that variety, the useful information in the market, what are the individual needs of all of these consumers or firms or whatever our customers are. That's metabolizing information. Then we have maintenance, "Why do things die? Why do organisms die?" Because the balance between maintenance and metabolism is off. If you're investing a lot in just maintaining your physical self, then you will be less able to absorb perturbations from your environment. That's why, when you are already compromised, your body is devoting more to maintenance. You can catch a cold and become terribly ill because you don't have the ability to metabolize in a way that would keep you going.
Manifesto for Agile
Does that sound familiar to anyone? What did we do in our industry? Agile came along, some dudes all wearing freshly-pressed khakis got together in a ski lodge, drank a bunch of scotch, looked into an orb, came up with a manifesto. What was that about? It was about metabolizing information from the market more quickly. How do we metabolize information from the market? How do we as technologists metabolize information? We write code. That's how we metabolize information, we write code. Then what happens to that code? We have to then devote more and more of that one bag of money to maintenance. We write more and more code, we're doing great, we're metabolizing all of this information from the market, it's totally rad. Then we discover that we have this maintenance debt in the form of all of this code that we now have to maintain.
Then what movement enters the scene? DevOps. What is the DevOps' message? It's that we have to find a balance, between the metabolic rate of the organization and the investment in maintenance. Why do we have to do that? Because we would like to continue to live and receive a paycheck. That's where we land on that.
From Transactions to Relationships
If we want to be able to absorb the variety from the market and we just have this one bag of money to invest, what we probably should do is decrease our investment in maintenance and increase our investment in metabolism. Why is that important right now? Because of this. We created all of these systems that were highly transactional. That's certainly what the original Ticketmaster was. I sell you a ticket, I don't own the ticket, I don't own the content, I'm just selling you a ticket. I don't care what happens after that, you sell it to someone else, whatever the case may be. Now there's a different set of expectations, not just for Ticketmaster but for firms in general, where in the market folks are expecting a relationship rather than a set of distinct transactions.
Who now has the app for your grocery store? Lots of people do. As a small child, you're, "I can't wait to become an adult and form a better relationship with my grocery store, I'm just dying for that opportunity." This is not just advantageous for the individual humans, but for the firms, so for us. We have these content producers and they want to have a relationship with the fan who enters whatever the venue is, so that ahead of time they can offer things afterwards, they can offer things, "We're going back to that city." The venues want the same thing, they want to be able to say, "We know that you love Taylor Swift, come see whatever else."
Now the expectation in the market is that we support relationships rather than individual transactions. There's a lot more information there, and if we're supporting relationships rather than transactions, a relationship is with a person. People are not the same, so there's just a teeny bit of variety there in our market. We have to build this channel that is capable of supporting the variety in the market. One way that we can do that - we're building a big channel for variety - is a decrease the unnecessary, the non-value-added variety within the bounds of our system. There's a lot of variety here, a lot of things that are custom. If we are devoting our variety budget to absorbing things here, within the firm, we only have that one bag of money. We are less able to support the variety in the market.
Coming up with the Map
How do you actually come up with that map? The basic steps are you list out what the components are, you list out what the relationships are, and then you look at the whole thing together. If you need help stepping through that, I highly recommend this template which you can go look at it. It's the Miro board template, but it has tips and tricks and all of these things from Simon's book are actually embedded in the template. If you just want to get started really quickly, that's great. That's obviously a real map there. What we're saying is that we would like to push some of those custom elements into a more repeatable of state. We have a cheer, a little chant that we do, "Secure, reliable, repeatable." It's very cute, cuter than it seemed just now.
If we know that that's continuing to have the custom emulation, and this custom operating system, we want to be able to treat that, make it more repeatable basically, so devote less of our variety budget to that, then we need to break down, "What does it mean to actually deliver and care for those things?" Then we break it down into all of this other crap. If we want to deliver and maintain and operate those things there at the top, which is the relational operating system, then all of these other things down here, which are not just technical components but they're also processes, even if we just move all of that over magically and drive out all of the unnecessary sources of variability in the operating system, in the emulation, and we keep all of the practices as they are around that, will we be getting the benefit of evolving the operating system and the emulation? No. If I'm delivering things in this highly customized artisanal way, then I won't be able to get the benefits of moving the other stuff more towards product and commodity. I have to evolve not just the technology but also the processes around that, and the skillsets around that. It is a socio-technical system, my friends. It's all making sense now.
We come up with this, this is obviously weird. I took out a lot of the meaty good stuff, but I'm sorry about that. All of these arrows, we decided that those were actually symptoms of us doing stuff that was not good. We said, "We're going to eliminate these things," which are basically manual processes. If we want something to be highly repeatable then we don't want it to be manual. No artisanal deployments for us.
Devops Is Not (Just) a Mindset
How did we do that? I've heard that DevOps is just a mindset, so we all just sat in a room together and we changed our minds and everything's great now. No, of course that didn't happen. Honestly, I find it offensive when people say that. In our panel we had someone who said, "Our executives all read 'Accelerate' and they changed their minds," and the organization has this debt basically - like a debt of processes, a debt of tools - before you can create that change fully. What you hear a lot of times is, "I changed my mind, I have a DevOps mindset now. What's wrong with all of you? Do you not really want it badly enough?" One of the really cool things about Wardley Maps is that we expose that debt, we expose the process debt, we expose the tool debt. We say, "Even if everyone changed our minds, we would still be up against these things that require change."
There's this great quote, I don't know if any of you have seen it before, but I think it perfectly describes what is happening right now in our industry. The systems that we create and deliver, they're systems of people and technology. It's not enough for the people to just change their minds, we also have to change the technology and the tools and the processes. When do you think this quote was uttered first? 1952 my friends. This is the same battle that we are still fighting right now. Let's not keep doing that, if you don't mind. I would prefer to just not. N next time someone says to you, "It's just a mindset," you tell them, "no," they're wrong.
The Map Is Not the Thing
In the beginning I've said, "The map is not the thing." The material that is the map is not the thing. I think we just illustrated that. It's not enough to just have the material that is the map, you must also have the mindset, you must also have the conversation, you must also construct the narrative. Just having the map is not enough, it is not the thing. You are developing a practice around examining your context. That is the thing, whether or not you ever make it material.
Even Wardley Mapping is not just the map itself, if you read Simon's book and you practice these things, there's all of these other elements. There's the map, there's game play, there's doctrine. This is a table of doctrine from Wardley, and doctrine, those are the things that you consider to be generally true in your context. Again, go read this on your own time. I am not going to read it to you, but I'll tell you a little bit about the things that we think are generally true in our context.
The first thing is practice respect for history. It's really easy to just say, "An emulated VAX? That is redonkulous, you should just throw that in the trash." Try thinking about it this way, it's had 43 years to get really good at its job. It's a fundamentally different way of approaching that and that's going to get a lot more buy-in. When you say, "We have this thing, it's the core of the company, it makes most of our money for us," let's show that thing the respect that it deserves, by maturing the way in which we deliver it.
Then, there are other things. We want to buy when possible because we don't want to devote some of our metabolism budget to making our own beautiful thing, we have no reason for a lot of these things to be custom. We try really hard to say, "These are the actual requirements of operating this beautiful emulated VAX," versus, "this is just a weird way that we've always done things."
Visibility is the priority. I mentioned that there are people on my team who were there in the very early days of writing this platform. A big issue that we have is skills duplication and getting that visibility so that we can all provide our unique perspective on what's happening. Visibility is our first priority all the time. Skills duplication is always more important than speed. We can say, "It's going to take us longer to deliver this, but now, instead of having the one person who's worked here for 34 years, know how to fix this thing, or change this thing, we're now going to make sure that there are multiple people who will understand the system enough to make changes." It's ok to sacrifice on speed if we're gaining skills duplication.
Then, like I said, we're trying to get rid of a lot of manual processes. First thing we want to do in our quest to do that is standardize the process and then automate it. Once things are automated, they off-site, they're sometimes harder to change. We want to explore the process, actually understand it, and then, automate it. That's what doctrine is, generally good things. Now you know about that.
Here we are, back to this. How do we absorb that variety? We have to first be able to recognize the variety. We can't act like things are all the same. How do we do that? We begin to value disfluency. We are intentionally not taking things for granted? We believe this to be true, we never even discuss it because everyone believes it to be true. What we're trying to do here is examine those things and not take them for granted anymore. It'd be very easy for us to say, "This platform makes a bunch of money, it's all good." Does it encourage additional maintenance? No, we know how to run it by now. What we're trying to do is create disfluency. Don't allow people to get so comfortable where they're at that they take things for granted, we're trying desperately to disrupt that. There's a great blog post about this written by a monk, "Full Stack Monastic," it's great, you should read it. Highly recommend it, something that I've been working on a lot.
I started this off by saying, "John [Willis] invited me here to teach you all about Wardley Mapping," and I'm going to finish it by saying that you probably don't need Wardley Maps. What you need is the process of mapping. Whether you personally just go through the process by yourself, whether you're sharing that so that you can surface disagreements, you need the process of mapping, you do not need the map. I'm perfectly fine with you creating a map, and then, immediately throwing it in the trash. Or drawing it on the whiteboard and immediately erasing it. It's the practice of creating disfluency that it's valuable, not the material artifact.
It's a Young Industry
Why is this important now? That's a baby. How do you measure the age of a baby? Not years. It's a very tiny baby, you will probably say, "Days or weeks," or a little older baby, I'll say like weeks or months. It takes a while before you're measuring the age of the small human in years. How do we measure time in this industry? At a conference I went to a month ago, someone said, "I don't know how we could possibly deal with this, it's 5-years-old." I'm, "5 years? My goodness." We are such a young industry, we're just getting started, and you can tell that because of the way that we measure time. We are measuring our own age in weeks, that's essentially what that boils down to. Now is the time for us to be thoughtful about how we are setting up our future generations in this industry.
The industry is small now, each one of us has a giant impact, whether you are aware of it or not. If you have that responsibility, what I'm asking you to do is create enough disfluency in your life, in your job, where you can really take on that responsibility and understand the actions that you're participating in and what effect they could have on future generations. At a certain point, we are going to have to commoditize some things enough where we can just take them for granted and build on top of them. Right now, I would argue that there's not really much of anything that we're doing that with.
I don't know what the things that we have now, like mainframe or my gorgeous VAX, I don't know if those are the things that we should be pushing towards commodity, but we have to develop that skill and stop shitting on things because they're old. Some people are, "No, thank you." That's fine, you do you.
What I really like about maps is that they are an invitation for participation in those conversations. We think of those conversations, about the effects of whatever we're deciding as being had somewhere else. No, we have to be having those discussions, we have to feel invited, we have to invite others. If we're going to meet the needs of a diverse market, we probably need a bunch of diverse opinions and diverse mindsets in our teams, we have to give people the tools to express that difference. For me Wardley Maps are a tool that I have to express the different way that I consider some of these things.
This is a picture of me at Map Camp and those are some old guys. That's Dave Snowden and Simon Wardley. We had this panel to close out Map Camp. I mentioned in the beginning how much I love having a microphone, so I invited myself on stage to moderate the panel. I should never be invited to moderate anyone really, but especially those two. This is the genius thing; they were, "You should moderate," and I said no, because I know that Dave Snowden writes stuff down in a handy-dandy notebook. He'll prepare and he has all of these little quips that he wants to get in. You can't do that if you only say yes after they're already on stage. If anyone's wondering, that's how you defeat the handy-dandy notebook.
I think the most interesting thing that we talked about when we were on stage together was the fact that we need to equip the people in our industry with tools to trust themselves. You have to equip people with the tools where they can form ideas and be able to express those ideas to others. For me, that's what Wardley Maps are, that's what Cynefin is. That's not something, "You have to know this magical thing that they're only going to teach you when you get an MBA." No. What we want to do is democratize strategy and enable people to participate fully in those decisions. That's why we have formed the Epistemic Justice League, so few people will get that very niche joke. I'm not saying that you have to use Wardley Maps for that but consider that, "How can we invite everyone to fully participate in fact of making those decisions and the work that we do?"
Questions and Answers
Participant 1: I've never found a really great way to use Cynefin in anything other than development, and I don't do development per se.
Swetel: The question is, "How do I Cynefin?"
Participant 1: Yes, what's the value to it?
Swetel: I think for me the value that I'm most frequently get from Cynefin is similar to what I was talking about with Wardley Maps, where we're just trying to make conspicuous whatever types of decisions we're making. I can talk about the context and say, "This is probably a complex context where the system is acting on itself. I won't be able to disentangle the cause and effect." If I'm reaching for a checklist in order to deal with the stimulus in that environment, then I can predict that that will have negative consequences.
Participant 2: Can you give examples of the wrong usage of a Wardley Map?
Swetel: Sure, I can give you a great example. I'm probably supposed to say, "Well, it depends," or something like that. I won't say that. The wrong usage of a Wardley Map would be, number one, treating the map as if it is the thing. It's not the thing, it's a representation of what a person or people thought were important about the context. Then, my favorite thing is, when people put it in a PowerPoint, and then, they send it out to everyone, and you're never allowed to touch it again. That's the thing, once you make it material, it's actually immediately outdated because we're operating complex socio-technical systems, where the system is acting on itself constantly, and so, it becomes outdated immediately. That's why I actually favor the, "Draw a map, throw it in the trash."
Participant 3: Can you elaborate on "Visibility is the priority?" What kind of visibility do you talk about?
Swetel: What can I say about that? I'm wearing a pin that says, "All my best work is under MBA," and that's very much the truth. The way that Ticketmaster first operated was like a franchise model. This system is its own thing basically. Developers for each of those franchises, or in whatever region, they came up with their own special things. We have a bunch of Pascal programs that are kind of globbed on to that VAX, and so, there were highly-specialized ones out in whatever region. Getting all of those in source control is an example of creating visibility. That's one example that believe I am allowed to discuss freely.
Participant 4: How do you go about generating disfluency kind of conscious? I think you were saying that was something that you did.
Swetel: Yes, that's something I try to do certainly. I think, going through that act of mapping, where we're intentionally making things conspicuous, and just because I didn't get to say this earlier, I'll say this mostly to John Willis because we should've said it in the panel. People have this ability - it's a good ability, and it happened through evolution - that we create coherent narratives. That's what we do. We fill in gaps with things that make sense so that we can continue to make sense with the world and we don't have to invest a bunch of time in trying to make sense of each little thing, we just kind of like our brain's in the background and glop it all together. Things like creating a value-stream map from right to left, you are much less able to lie to yourself in reverse, so you can't construct a coherent narrative in reverse. Things like forcing people to tell the story backwards rather than forwards will force them to examine the things that they've actually observed rather than construct a coherent narrative using the natural powers of their brains.
Participant 5: The ladder of inference.
Swetel: The ladder of inference, there's a lot of techniques around that. If you don't know the ladder of inference, it's started with ArcGIS, and then went from there. Lots of people have adopted it and expanded on it. That's basically, there's all of the stimulus in the world, you can't possibly take it all in, and so, you are filtering the world based on your beliefs, what you think is true about the world, and so, you won't notice things that don't make sense in your beliefs. Yes, a lot of techniques there for examining that.
A book that I really like is called "Examining Your Own Practice," or something like that. It talks about taking an account of before accounting for something and it has actually a bunch of exercises that you can do in daily life to practice taking an account of a situation, what is actually true, what are the facts, before you begin to account for the situation.
See more presentations with transcripts
