Ben is joined by Ryan Wold for the very first episode of the Hired Thought Podcast. They talk about the sociotechnical nature of organizations, and what it’s like to integrate a larger view of the system across functional boundaries.

Follow Ryan on Twitter:

Find Ryan on GitHub: https://github.com/afomi

Transcript

Ben [00:00:00] Hello everybody. My name is Ben Mosior. I run a company called Hired Thought and I’ve decided to start podcasting. And even better, I have a guest with me today who is brave enough to be on the first episode.

Ben [00:00:19] I don’t know what I’m going to call this place or this show, I don’t know what it’s going to be. We’re going to see, we’re going to find out. We’re going to explore it together. Today I’d like to introduce Ryan Wold. He and I met each other on the Map Camp Slack. If you’re watching this you probably have some inkling that I know some things about Wardley Mapping. I like talking about about it a lot. So I hang out on the Map Camp Slack, and you should, too. But I met Ryan there. We had some interesting discussions one on one in DM and just talking through some interesting topics, and just he’s a really interesting person, and I’m excited to introduce him. Ryan, who are you? And what do you do?

Ryan [00:01:01] Yeah I’m Ryan Wold. I am a software engineer and product manager by trade. I have a deep background in the public sector. I started my career in a financial auditor’s office doing information systems development and financial reporting automation. So basically using basic things like scripting Excel and like SQL reporting tools to help automate financial reports. And ever since then I’ve been drawn to leveraging technology to make organizational life better and that’s kind of manifested in all sorts of different ways. I’ve had the opportunity to to be a manager at a charter school and do some consulting. Most recently I work for the federal public sector doing open data. I’m a software engineer there. My title is innovation specialist which is a pretty fancy title but it’s really a generalist role, getting to kind of explore different ways to improve the customer experience for citizens for a bunch of different federal agencies. So that’s been been really fun. And before this I had a chance to do some consulting at a company called Neo Innovation where we did early stage Lean Startup work, and then we were acquired by Pivotal, where I was an engineer there and did some product management as well and had the opportunity to work with some really amazing folks and amazing clients as well.

Ben [00:02:38] That’s such an excellent introduction. So many questions come to me just wanting to learn more about the background. I know we’ve talked about some of some of that before, but I I’m always interested in the story that starts with, “I’m really interested in using technology to make organizational life better.” That is something that resonates so deeply with me. I also worked for state government for a little bit. Way back and that was the bug that really started to bite me. It was like OK I’ve gotta I’ve got to make things better and I have all these tools that I’m learning how to leverage. But talk to me a bit more about what makes you tick. Why technology? Is it taking things apart and putting them back together. Is it the kinds of problems that you have to solve. Tell me a little bit about what makes you work and what motivates you in this sort of scene, in this industry.

Ryan [00:03:34] Yeah yeah a little bit of both you know taking things apart putting them back together again. You know technology I found just to be a high leverage tool to solve things. So I think my first project in the public sector way back when I was like 20 years old was taking this huge financial report that would get spit out of a printer each night, it would come out on the dot matrix printer you know based on this huge ream of connected paper, and and then that would basically that would get fed to some analysts and they would go through and redline it and do all sorts of things, and I mean we’re talking hundreds and hundreds of pages when it came budget season, and and so they would take literally days, so two to three days to go through it all like red it and then basically feed it up the chain to the auditor and more senior analysts, who would then finally get to do the value-add work.

Ryan [00:04:27] And my first project was to see if I could make that better. And so we dumped an ASCII file. I was able to import that into Excel, write this pretty gnarly macro that would clean it up but within a couple of weeks I was able to take that process that would take several days for each iteration and literally boil down to a couple of minutes. And ever since then I was like, wow this is awesome. It felt like really low hanging fruit to me I kind of grew up with computers, and at that point I wouldn’t even call myself like an engineer or even a technologist. It was just like, hey I know how to do this stuff. Everybody knows how to do this, right? And that is not the case. And it’s still you know almost 20 years later I’m still learning that. Like you know a lot of the skills I take for granted aren’t necessarily as widespread as I I believe. So with that said I really enjoy understanding user problems and user needs and a little bit later during that experience I got to do a lot of cool things like implementing purchasing systems and implementing grants management and implementing a workflow system, which was really kind of a transformative experience in my life, doing formal business process management systems or workflow systems, basically boxes and arrows but actually modeled in a system.

Ben [00:05:53] Yeah yeah. I want to get into that but the thing that I’m curious about right now is that you sort of pointed at this impact that you saw. So, days to minutes like this is not an uncommon story when people start to discover the wonders of technology, and actually like how how to use it, which requires not only the actual writing of the code or the automation or whatever it ends up being but also changing the rules of how you do that thing how you do that activity, because in order to take advantage of that automation you actually have to do the work differently. So I’m curious, that first taste of the impact of changing a process and then seeing how someone else, how their lives are different as a result of that. What was that like? Did you really get a chance to sit down with someone and learn what was going on like? Tell me a little about that.

Ryan [00:06:45] Yeah. So yeah during that process automation, first off you would sit down next to an analyst and try to understand what they were doing when they were doing the red-lining work and just started developing a kind of understanding and domain experience of… what do they do on a daily basis, how do they approach the work, what are the things that are common, what are the things that are more intuition or fuzzy, what are the things that are procedural or like policy driven.

Ryan [00:07:26] Yeah. And ultimately being able to codify the things that I could and being really explicit about the things that couldn’t be done. But the thing that really I was attracted to was getting the deliverable into the hands of the people who who needed it.

Ryan [00:07:44] And so frankly the role for the mid-level analysts at that specific job actually kind of disappeared. They no longer needed to usher one set of data into another. They were able to move on to other, higher-value tasks, but ultimately the decision makers were able to provide more value more often. And that to me was my a-ha moment.

Ben [00:08:10] That’s huge. Yeah. I think back to a story that I had, an experience that I had where I was kind of… there’s this generalist thing right where you pick up a domain of knowledge you learn about what people are doing and then you ask some questions about, and the naivete that you bring actually is an enabling thing, because while you have deep expertise, the questions that you have about the domain actually reveal the the design of it, like what is really going on here. I had an experience where I was working in an organization and someone was at the end of a release, for the software that we were building, taking their laptop home and going through this whole like complicated process and sometimes it wouldn’t work. And like they would lose nights and weekends to this process and it would also delay the release of the software. And I was really curious about what was going on there and I wanted to learn more about what they were doing and what their expertise was. And they were just like this was part of their life, like they were resigned to it and we took a look and we found out what was going on and we actually did something similar where we just automated that section of it and made a machine do that really rote, manual, annoying task, and they were just so happy, they were so grateful, they were like ahh, OK! And what was great about it I think is like a month later it was so far faded from their memory because they were focused on all these other things. They actually put their attention on things that mattered instead of moving bits around or whatever they were having to do. So I deeply resonate with that kind of experience and also with the picking up of the domain and making sense of it. So shifting into BPM, into thinking about workflows in business… I feel like it’s cranking up that kind of experience up to 11. Tell me a little bit about that.

Ryan [00:09:58] Exactly. Being able to, number one, identify an organizational problem or what was perceived as an organizational problem, whether it be the approvals of payroll or processes around compliance and procurement. The organization had an intuition that there was room for improvement, to be able to bring those stakeholders together in a room and really just ask them to model this out in front of a whiteboard. Making the process explicit. A piece of paper comes in. This person touches it, basically reviews it initially, gives it to another person. Then you have to put a stamp on it etc., then it goes to another person for you know an approval if it’s above this threshold. or below this threshold, or if it has these characteristics, and then so just a lot of that. I always come back to making the implicit explicit. And once you have kind of a current state understanding of something and doing it in a visual way I think is really transformative because it really creates literally a same page for people to operate on. When people are deep into a domain they have a tendency to internalize these things and there are a lot of assumptions made especially when there are multiple people involved that may not necessarily align. And so having the same pages is just such a huge win. Being able to map out that current state the opportunities almost reveal themselves. I used to think I was really clever because I would be able to see these things but the more and more I have done this over my career, I’m just just more just a fan of having the discipline and process to bring people together, allow them to sort of own the… Yeah I guess sketching out of any given process, and the opportunities are really quite evident. You know when people can declare what their assumptions are and see how X connects to Y, or not, then things really pop out.

Ben [00:12:16] That is such an insight. I’m reminded there’s a book called The Secrets of consulting… and I think there’s a lot of of other literature that sort of points at this phenomenon as well…. the entrance of a consultant into a process is not a particularly straightforward thing. The consultant on their face they’re entering into the system, supposedly with some sort of solution to a problem. Right. So they’re coming in with their toolbox and they’re their hammers and their saws, and their one frame of this is to think of them as they’re basically diagnosing the problem, then prescribing a solution, and coming in and implementing it, and getting the people to do the implementing, and all this kind of stuff. And there’s a common problem around that version of events which is, the consultant comes in with the perfect solution, why won’t you just change, why won’t you just actually do what I say, and because “don’t you see?” And the answer is… they don’t see, and so there is this other model of consulting which is, just by entering into the system, you change it. So just by being present, by being another pair of eyes, you are actually changing the system that’s being observed, which can be good or bad. If you’re trying to find the truth to something, like if you are a Sherlock Holmes, and you’re you’re talking to people, suddenly that changing-the-system part isn’t so great, because you’re trying to understand the truth, and actually your own presence becomes a barrier to that unveiling of the truth. But in a consulting situation like by showing up and saying, “That’s a thing we should talk about.” And just holding the space for the people to do the work can work wonders on its own, because they are a forced to reckon with the system in a new way that they weren’t before. It’s almost like the consultant is an event. It’s like you get everyone in the room, and the only reason that you could justify getting everyone in the room is you’re paying a high paid consultant to do work here. That whole thing is just so fascinating to me. And the derivative version of that is, doing something random as a consultant in an organization is enough to cause this effect to occur.

Ryan [00:14:34] Reminds me of Heisenberg a little bit. The Heisenberg Effect for organizations. And just by observing you’re changing the system.

Ben [00:14:45] Totally, and the other thing I think about is… I haven’t talked about the Theory of Constraints yet… the Theory of Constraints comes from a book called The Goal by an author named Dr. Eliyahu Goldratt. He wrote this book in 1984. And one of the sort of key principles of the system is basically making things obvious. It’s actually a sign of success if at the end of the process or whatever work that you’re doing, people look at the system that you’ve all modeled and you’ve talked about and the decisions you made… and you go, “Well, isn’t it obvious? Like obviously we’re going to do that!” That’s a sign of success, even though as a practitioner or facilitator really it feels a little bit like you’re being diminished. Like, “Hey man, my process worked!” But no, holding the space I think is such an important part of our role in helping people figure out what’s going on. So you facilitated that kind of process and what came out of that? What was the outcome, the impact of those kinds of experiences?

Ryan [00:15:50] Well in each case it was different. You know sometimes it was… well a lot of times I felt like it was well received. I think that’s why I enjoyed it so much. And to get back to one of the points you just made, was you know it wasn’t necessarily being clever or creative. It was actually more of a discipline. You know you’re distilling the truth out of a situation, rather than creating some solution from outside. And so the experience you know most of the time was simplification. And I guess another thing that really pops out to me is, any technical change has a people component. That was something I really took for granted as well. I was like “Of course you’re going to need these people. They’re the ones who are using the system, and these are the people who are doing data entry all day and having to look at dozens of claims every day and make decisions. This is their life.” I can go and implement a new module and provide training around it, but like what we’re really talking about is user experience and there’s a user experience aspect of their system, but it’s really the user experience and design of their workday and ultimately their career. And I think there is a lot of things there, I’ll kind of put a lid on it for now. But just having those insights, I really was struck about the socio technical aspects of systems, because as I proceeded in my career I had an opportunity to work with a lot of amazing engineers where their life was just the system. I sometimes struggled with the fact that… wait a minute… the people are really at the other end of it. And 15 years later you know there’s service design and user centered design and all of those user centred practices which I think are are evident. You know coming back to exactly that topic that you just mentioned.

Ben [00:17:55] My career was kind of an inversion… I started out very technical doing systems administration stuff, and I kind of went through that same realization and was like, “Wait a minute the people are the ones that are actually doing the work, and I can I can talk to them!? And then when I talk to them they tell me things, and sometimes they change what they’re doing as a result of me talking to them, and sometimes I do the same. I change what I’m doing.” And that little piecing together of the larger system… I was so stuck in my little technical world. I was taking care of the servers and making sure they were well-fed and named and all this kind of stuff. And I had my world broken when I went to devopsdays Pittsburgh. I think this was like 2014 or so. First of all, devops is a weird thing. It’s a name that has become an abstraction that points at many different things now, but concretely my experience was with other practitioners, recognizing that hey you can actually go talk to the person who’s doing something different than you, and you’ll learn something, and you can make the whole system better as a result. And it’s kind of like that getting people into the room effect yet again. How you facilitate that is an interesting question. So it was kind of like a… really one of the first mind-bending moments in my career. And over the last several years I’ve really kind of completed the transition. I do like hacking on things and doing the technical work, but I am I am primarily interested in the socio side of the sociotechnical, which is really interesting to go through technical dynamics with that new lens now. I’m curious do you feel… being a generalist… I know that you integrate a lot of different domains into the world, or your frame for the world, your view of it… Do you skew towards the social or the technical? Or does it matter?

Ryan [00:19:57] I am kind of drawn between both. There’s this notion by Walter Russell… he talks about rhythmic balanced interchange, and that’s very much informed my life. But you know as I apply it to work, I sort of keep a foot in both camps, and sometimes I have to lean on one side of the teeter totter, and ultimately back. So I think there’s times where I love doing the technical work, but I’m always user facing. I always come back to the users, and ultimately I think nowadays I’m more drawn to the organizational, which is kind of the macro socio stuff. And getting back to what you said about getting people in the same room. I really enjoy crossing boundaries or what are perceived as boundaries, because I grew up playing a lot of sports, and the notion of teamwork is so inherent there… Everybody has a position, but we’re all aiming for the same thing, and I think in organizations, roles and divisions and departments and bureaus and all of those things can get very siloed, and ultimately viewing those through the system engineering lens, I think about things like cohesion and coupling and message passing, and I view the organization very much like a technical system, although the dynamics are different. But that’s sort of an example of that interchange. I have a very expansive mind naturally, but the integrative approach, trying to integrate these disciplines… I think that’s actually one of my superpowers… being able to bring that perspective, but then also bring people along with it, and I think is… where I’m at now in my career is that it’s one thing to have these insights but it’s another thing to share them with folks and get them to say, “Oh wow, why are we shaped like this?” Or, “Is that really a barrier? Or perhaps not.” And so that’s what I really enjoy.

Ben [00:22:16] It makes a lot of sense. The integrative approach, in particular the ability to bring other people along I think, is a rare combination of skills. It’s really hard… it’s like, you can’t teach that. It’s something that you have to live and experience and really pay attention to. And I also appreciate that even when you’re looking at the technical sense of things, whether it’s like code or if it’s actually the organization… what is what is the way that these things are disposed around each other… if you’re still oriented towards the people I think that can be quite clarifying in the kinds of decisions that you make.

Ben [00:22:52] So yeah that kind of brings me to the Wardley Mapping question. We started interacting on the Map Camp Slack. We’re both kind of interested in this weird way of doing… like a lot of the things we just talked about are relevant in the Mapping context as well. For mapping it’s not unique to get people in a room and to have a shared model, an artifact that you’re all pointing, and making our assumptions obvious, making the implicit explicit… Stepping through all that same kind of stuff, I’m curious what your impressions of mapping as an approach, versus other techniques that you’ve leveraged in the past, and I’m kind of curious what your exploration with mapping has been like so far.

Ryan [00:23:37] Yeah so, Wardley Mapping, when I saw it, it just kind of blew my mind. And getting into it was actually really tough. It took several iterations. Like I sat down and tried to sketch out a map and I quickly kind of got stuck, and I was like, “Well where do I go?” And I started asking all these questions that I’ve since learned, you know, it’s not a science it’s more of an art. You know it’s a very iterative process. And in the vein of making the implicit explicit, just getting the nodes down, getting the objects down, being rooted in the user experience… all of those things really come to mind. Doing it in a group has been quite challenging, because the notion of making thinking visual is sort of one level. The notion of doing it in a Wardley Mapping format, unless users are familiar with that… that’s like a whole new, like a whole other layer. And even just thinking about things in value chains and making that explicit, and then the horizontal axis of the Genesis, Product, all the way through Commoditization… like that’s something people can nod at, but I don’t think people think about that very explicitly. And so more recently I’ve come to grips with strategies about sharing several examples, and really one of the things I like to do is just go to Google and type in Wardley Mapping and get all the images… it’s like dozens of them, because there are so many great examples now, and share that, because people have to understand that there’s variability and the landscape is variable and that’s okay. And so those are just some of the things that I grapple with, but something that always sort of stands out to me is the distinction between the nodes and then the relationships between the nodes and the kind of conversations that that drives… I mean I think that’s another thing that I get from systems engineering… it’s really the relationships and the objects. So yeah, being able to just get the things out on a piece of paper and then… Well how do these things relate… and the conversations that just emanate from there I think are so valuable and kind of taking on a life of their own in a group

Ben [00:26:15] Yeah I’ve worked with a lot of people one on one, and I’ve had enough group situations right now where… like I’m not the world’s best facilitator, it’s something that I’d like to get a lot better at… but mapping in particular I think is a challenging thing to facilitate, because it’s a lot all at once. I recently had an experience where it was a group of about 15 or so people and I only had a couple hours to really get them introduced to the concepts and start working through the process. And there’s a lot of normal facilitation stuff that you kind of have to just do and figure out how it works for the step of the process and all that kind of stuff. Really tactical annoying stuff like… how many stickies should you tell them to make? And that kind of stuff. But what people really get stuck on is the systems part, at least in my experience. I actually found it easier to get people excited and get their energy levels up around talking about evolution and how things change and what the implications of that change are. It’s like the process of defining the parts of the system and the relationships between them and then trying to talk about evolution relative to that system… that whole thing… it’s just a lot to take in all at once. So I’ve really started thinking about what it looks like to do kind of a minimum viable learning cycle. And there’s something that… my mentor, his name’s Jabe Bloom and he has this kind of interesting like philosophy background, but he’ll send me papers every once in a while about things, and one of them was just like the learning loop. I think it’s called like the Kolb cycle… It was basically, to give the most oversimplified version of it, how do you help people have concrete experiences that they can reflect on and then integrate into their understandings of the world? And so when it comes to teaching people Wardley Mapping, I also had the same experience you did where it was just like how do we even get started with this thing. A co-worker and I locked ourselves into a conference room for weeks on end and just smashed our head against the problem until we kind of figured it out. I was like “Oh this is how it could work.” There’s a lot of variability there. But teaching it now, and trying to get help people get into it, I’m all about compressing that…  What’s the minimum path for getting all the way through a map? How do you just compress, compress, compress, until it’s almost not a useful artifact, but you get the idea of what it’s supposed to do. And then you come back for iteration two.

Ryan [00:29:01] The minimum viable experience.

Ben [00:29:03] Yeah. That’s really what I’m interested in figuring out right now, and I love that you mentioned all the images because I’m very much the same way. I have a giant folder full of image after image after image of mapping related stuff, and I just sometimes go in there and rediscover things and re-remember things like, “Oh, yes!” But yeah that I think being able to see many examples of the kinds of artifacts that we’re talking about, and even like artifacts that are relevant to our own experiences… like not even just the industry stuff, but if you’re a startup the way you map is gonna look a little bit different than if you’re an enterprise. The whole thing’s gonna look different.

Ryan [00:29:49] Are you generating it new? Are you discovering it or distilling it from an existing landscape?” For sure. Having enough familiarity in order to get started is a challenge, and so sending across a bunch of images, at least it helps prime them…. There’s usually a couple basic articles I send… one of Simon’s… the beginning one, and then the… I can’t recall the title, but then the 100 Day Get Fit Plan as well. That seems to really resonate with a lot of enterprises, because it speaks a lot of their language and gets them attuned to… essentially risks and opportunities, and that’s where I like to start with maps is identifying opportunities and to show, “Hey when this specific thing ends up evolving, what does the organization look like then?” And now you’re engaged in a conversation, now they are starting to reframe this within their own context. And they have an experience that resonates not just with their logic understanding, but you sort of get their emotions and heart involved, and I think that’s just a general tip for facilitation is you have to be able to engage both sides. The heart and the mind.

Ben [00:31:16] Yeah. Absolutely. One of the hardest things I’ve experienced thinking about Wardley Mapping and using it practically is the question… what kinds of decisions you make. And I think there’s some of the obvious things, like the doctrinal stuff, like what do you build… what do you buy… all that kind of stuff. But really in particular the question that’s really fascinated me right now is the question of ownership. What parts of the system are you going to own? And what’s the implications of ownership? And like you were pointing out earlier, when you are forced to design the system even for the first time… like you have the idea in your head or you’ve even been doing the work, but you haven’t put names to things and you haven’t really taken it apart into something that you can reproduce and draw… I think the the opportunities start to present themselves. The options almost become obvious just because you have to reconcile it against the framework and reconcile the relationship, and you realize, “Oh no, why are we doing it this way?” What kinds of decisions have you made, and what kind of options have you discovered by doing this kind of work?

Ryan [00:32:37] Yeah I think the doctrinal stuff goes a long way. Being able to talk to stakeholders about build versus buy decisions… I think that’s a very obvious one. Why are we spending the time, why are we building this commoditized solution in-house? What is that really getting us? Is that where the unique value lies? Is that really our expertise? Does that make sense? And then on the opposite end… OK wait a minute. There’s some unique value that we can actually realize here, but we’re trying to take this commoditized solution, and then the fact that we’re hiring a team of consultants to come in and customize it for us, and then we’re feeling the pain around maintaining that solution… like that should be a signal that maybe this is more custom than we thought. Maybe there’s more unique value here than otherwise was evident. So I think that’s something that just comes to mind.

Ben [00:33:45] So I think for this first episode we’re coming up on the end, and one of the questions I think I’d like to ask guests is what sort of things they’ve been reading. And I know you’ve sent me some really interesting articles on Slack, and I’m kind of curious if there’s one that’s really on your mind lately that I could share with people that watch this.

Ryan [00:34:08] Oh yeah. Let’s see there’s a lot of different things. I’m really immersed in bitcoin right now. I think what it does to the Value Chain overall is going to be tremendous. The kind of collapsing of the Value Chain, the reshaping of that is going to be incredible. But yeah more towards Wardley Mapping, I’ve really been thinking about… I have tweeted about the geometry of collaboration, or you know I think about organizational physics, which are kind of abstract concepts, but… Things I’m thinking about are like equilibriums, and there’s a medium article called The Shape of Strategy, and it has a few different diagrams in there that are kind of evolutionary, that start kind of binary, and like this or that, and then evolves to more of a trinary approach, and then evolves a two-by-two axis, and then from there it would just keep evolving. And that really hits at the nature of complexity, and how people will sort of iteratively come to understand that complexity and shape it and articulate it and then ultimately communicate it and take action on it. And you know as a consultant, and even in my own personal life, I just feel like it feels right. There’s a lot of things that we we do naturally. So yeah the shape of strategy is something that resonates with work by Robert Keidel. He wrote a book on organizational patterns in the early 80s, I believe. But that was really influential and just going wow, like people are thinking about mapping and visualizing this stuff. And that’s one of the things I really enjoy about Wardley Maps is that it has a visual framework that is consistent that people can use to communicate better.

Ben [00:36:23] Awesome. I have a lot of questions… This article just has so many awesome like images and just things to look at and think about, and then I feel like we should record a second episode about the bitcoin thing because… I’ve dabbled! I’ve learned enough to be a little out of my element, and I feel like you’ve been doing a lot of learning lately on that, and I’d like to surface some of that, especially in the context of some of the mapping stuff. I’ll put a link to The Shape of Strategy in the show notes, and one final thing is… Where can people find out more about you? Where can they connect with you and ask you questions about this?

Ryan [00:37:06] Yeah I’m @randw on Twitter and github.com/afomi (A Figment of My Imagination).

Ben [00:37:17] All right. Thanks so much, Ryan! I appreciate you taking the time to hang out with us.

Ryan [00:37:22] Ben, thanks a lot. Have a good one!