Transcript
Diana Montalion: There are days in which I wish my biggest problem was the implementation of Kubernetes. I think you’ll feel that with me.
Cat Morris: Yes, that’s the easy problem.
Diana Montalion: We’re going to talk about friction. The most important thing to know is that friction is a systemic issue. There isn’t one primary cause.
Cat Morris: We’re going to start by telling you a little story. You are wrapped around our architecture and product campfire right now. It’s a story about friction and how we try and reduce friction, like these colors have.
Diana Montalion: We’re going to focus on six different areas. Understanding the system. Fire that guy. You’ll see what that means when that comes up. Designing knowledge flow. Becoming learning driven. Architecting relationships. Focusing on goals.
Cat Morris: Actually, this is the theme that we want to tell you about through this whole thing, and that is architecture and product need each other. Our jobs are a lot more similar than we originally thought when we started writing this talk.
Diana Montalion: We ranted at each other about how much the other one was to blame for all of our problems. We’ll start with my story. Once upon a time, there was a software engineer and a systems architect named Diana Montalion. When organizations needed a “transformation”, monolith to microservices, event-driven, domain-driven design, then let’s get Diana, because this is what Diana does. She’ll figure out how much it’s going to cost us and when it will be delivered. This really isn’t what I’m going to do. I always get really excited, because I love to do hard things. I love to solve difficult problems.
My teammates and I, this is really what we live for. The challenge is, the call is coming from inside the house. The organization itself is causing the problems that it has now brought me in or hired me or however they’ve done it to solve. What’s holding back the change? This is my primary question. In order to understand, I begin by asking people about their pain. If I come in as an architect and try and talk about solutions, no one wants to talk to me. If I ask them about their pain, everybody has something to tell me about what’s going on. The challenge is, I hear a lot of blame. In systems science, whenever humans are in a complex situation, we blame. We know this from years of experience. We blame the other guy. It’s someone else and someone else. This leads me right in to the big ball of mud. The system is a tangle that we need to detangle. Also, our thinking about what to do is very tangled in the big ball of mud.
Let’s start with the fundamentals. What’s my mission? What does this system do? What’s the core domain? FedEx, for example, fast package delivery. I want to architect change that improves the system’s ability to deliver packages faster. I will do some version of modeling with leadership to find out fast package delivery. What is the core domain? If there are eight people in the room, there are eight answers to this question, inevitably. This is part of what’s causing the inability to prioritize change, because we actually don’t agree cross-functionally on what fast package delivery means in this situation. How do I dive into the system?
I’m going to dive into the current system and try and understand how it works. In 20-plus years, I’ve never gone into an organization where there was one person that knows how the whole system works together. That’s the thing that I need to figure out. It’s even trickier than that. Because the system, according to Russell Ackoff and every other systems scientist, and my own experience, is that a system is never the sum of its parts. I can’t just figure out what the different pieces of software are and then know what to do. It’s a product of their interaction. We begin to work cross-functionally and ask a lot of questions to try and figure out what the relationships are in this system. I talk to ops. I talk to the people using the system. I’ll model with stakeholders. We begin to see patterns emerging. That even though people are blaming different things and using different language, often, there are these consistent patterns that are reoccurring in the system that are keeping it from being able to transform.
For me, I’m not really looking for a fix, just use Kubernetes. I’m looking for a leverage point. Where can we make a change in this system that will unlock the potential for transformation? It’s often a small change, but a very difficult change. We find the essential patterns. We do prototyping. We do whatever it is that helps us to understand how to move forward. We begin to articulate the leverage point. This is our recommendation.
As Donella Meadows says, that we know from bitter experience that when you do find a system’s leverage point, hardly anybody will believe you. We have a whole pile of information about how to move forward. In that pile of information is going to be challenging the structures of power and the way the organization is currently operating. We’ve gotten the green light. We have the ability. We’ve got the $3 million, and we’re ready to go. In it is an answer to the how much and how long question, but that’s not the most important. That’s not the key architectural decision. This is when the key architectural decisions begin to be ignored. Also, this is when I find out I’m not going to lead this transformation. Instead, we’re going to give it to product because we need somebody to make the trains run on time. We need somebody who can deliver. This is when Cat comes into the story.
Cat Morris: We get really excited in product management as well as the architecture. Diana is super excited when we get this initiative. We have green light we’re going to change something. That’s awesome. Almost inevitably, similar to like Diana was saying, it is that same old song and dance. We’ve seen this before. We know it’s not going to go exactly to plan, but we want to go anyway. We want to give it a go. I am a product manager who has a dream. I have a dream for a delivery that’s going to be value-driven. It’s going to be iterative. We’re going to get fast feedback. We’re going to get user-centered delivery. It’s not always the case when they send in myself and a cross-functional team. It’s never just me on my own. It’s usually a tech lead. We maybe get a QA. We get some delivery management if we’re lucky. We get handed this remit. This is the thing that’s been given the green light. It’s fat and it’s full of words.
The big thing that’s really clear is there is a budget and there is a timeline. Everything else in there is written in a foreign language that doesn’t really make sense to us. There’s boxes. There’s lines. There’s words that don’t really match our understanding of the domain and what people care about. We do know this deadline’s there. That’s immovable because some other stuff’s been built on the back of it. Your delivery needs to get done in two years, otherwise, the business is going to fall over and fail. Really, could you do it in a year, please, just so that we’re certain that we’ll be all right? Fine. That’s ok. I still have my dream, though.
I also start looking. All of these words, diagrams don’t feel like the right thing to me. I want to figure out what’s going on. I want to understand the goal because it’s still not crystal clear. What are we trying to achieve specifically? What would great look like in 3 months, 6 months, 12 months? What do we do to get there? Everyone wants to talk about it. We get infrastructure who come to us and say, it’s never going to work. We weren’t consulted properly. It should look like something different. Engineering, because it’s 3 months later, have 12 million other things they want to do on top of what was already there. We go speak to the operations team. Despite Diana telling me they spoke to each other, they don’t remember that at all. We never actually spoke to them.
Here’s our actual list of requirements and what we want to do. What’s changed? Why, in this short space of time, have we gone from having a remit that was clear with a green light, and a budget and a timeline, to everyone pointing in different directions and wanting to see something different or going somewhere new? That’s when you get introduced to someone. This person’s usually been in the organization for 10, 15, 20 years. They know where all the bodies are buried. They know exactly what skeletons are in the closet. We have a chat to them to figure out what’s going on and why everything’s changed. What they say is, it’s never going to work. We’ve tried migrating. We’ve tried re-platforming. We’ve tried reorganizing. We’ve tried restructuring a million times before, and it always fails. Don’t bother doing anything. There’s no point.
Incredibly unhelpful, and gatekeeping absolutely everything that we’re trying to do and the change that we’re trying to make. Sometimes they’ll sit down with you and go through everything, but they’ll do it in an hour and try to explain their 8,000-line Bash script to you, and it won’t make sense, and then they’ll think you’re an idiot because you don’t understand what’s going on.
These people are rooted in this fear of change. They’re like a broken-down car that doesn’t want to move anywhere. They’re trying to do this old way of thinking, but it’s impossible because they’re not going to go anywhere to do anything different. It’s because change is hard. Because people overestimate the value of what they have and underestimate the value of what they may gain by giving that up. We get a bit demoralized. We’ve had some successes, we’ve learned some new pains, but we still haven’t figured out what that ideal goal is. Maybe it’s us. Maybe we need to do something like it was said in the plan in the first place. Maybe that Gantt chart with all of the lines and all of the dependencies is the right way of delivering. It’s not really how I work, though, because I’m stubborn, and every other product manager I’ve met is stubborn.
We’re often sometimes the problem in these situations because we’re trying to change the way things work, and we won’t really give up on it. We also understand that change is hard, so we try to be integrative with it. We change the roadmap that was given to us with a bunch of deliverables on it and put a nice outcome-flavored veneer on top. We don’t try and split out all of those teams that are hyper-dependent on each other. We just give them a different name so it feels better, because it would take too long to actually turn them into proper stream-aligned teams that are independent and aren’t dependent on each other. We accept the problems because what else can we do to get things done? It’s like fitting a triangular peg, in this case, in a circular hole.
The ways of working don’t make sense. We try and make it work, but we miss our deadlines. We blow our budgets. We do a bunch of bad decisions and blame everyone else. It was the first architectural team. It was the Gantt chart. It’s the program managers for not being clear enough. It’s the other team because we’re too tightly dependent on them. Leadership end up looking really confused and surprised as to why it didn’t work with the new deadline and the smaller teams and the lower budgets. This happens every time, every single project I work on. Why does this keep happening?
Diana Montalion: This is when Cat and I modeled every initiative that we’ve worked on. This is when we discover that every initiative ends like this. It hits the iceberg. Then the moral of the story is everything gets rewritten in PHP.
Cat Morris: Mine is they never migrate off the mainframe.
Diana Montalion: Why does this happen? We both had to become very curious about, because if it was just Kubernetes, wouldn’t that be wonderful? We could just learn more about Kubernetes. The problem is that if a factory is torn down, but the rationality which produced it is left standing, then that rationality will just produce another factory. It really didn’t transform anything unless you can transform the way that you’re thinking about the system. The change we’re really trying to make is to change the mindset out of which the system’s goals, power structures, rules, and culture arises. Because it was the right system goals and structures for the legacy system, but now we need a different way of working, of understanding. Also, there’s so much wasted work in our story. How many times did we both do exactly the same thing? What do you do?
Understand the System
We’re going to talk about six heuristics for how you can reduce this friction, how you can improve this situation. The first one for me, like I said in my story, is to understand the current system. In system science, we use the iceberg model a lot because it’s truth. Meaning that every time there’s a bug in production, underneath it, there are patterns and structures and mental models that led to that bug. The call is coming from inside the house. When we’re making a systemic change, we actually need to understand the way the organization is reinforcing the events that are visible.
The challenge is that we have been taught to think linearly, and we practice reductionism. When we face complexity, we want to break complexity down into smaller manageable parts. That’s great. Object-oriented programming is reductionism. It doesn’t help us. It doesn’t go the other way. We can’t understand how relationships produce effect by understanding a part. We are taught to approach delivery as rational, top-down, procedural, and concerned with control. We need this to code. I want my code to do what I expect it to do. It fails us, it limits us when we’re facing a systems change. Because when we’re facing a systems change, Cat and I are the people in the doorway. I have tried. I have so tried, to translate the complexity into the Gantt chart, and I can’t. That’s not possible.
I have to eventually, but there’s a lot of things in the way. We think of this as like, “This is nice, Diana. Touchy-feely. Yes. Of course, systems abstraction. We want this”. In fact, this is critical to the business, and this actually is the primary reason. Jay Forrester, a systems scientist, from MIT, went to many organizations and discovered that we usually know where the leverage point is, but we’re pushing it in the wrong direction. This is the most common example for us. Adding manpower to a late software project makes it later. We know that if we say 6 months, and the organization says, I’ll give you 10 more engineers so you can do it in 3 months, that isn’t going to work. You can understand how they might think that that math makes sense.
The true system, the real system, is our construction of systematic thought itself. This is the continuation from the factory quote of rationality itself. We’re experiencing the friction of counterintuitiveness. We’re blaming the wrong things and we’re doing the wrong things. In order to figure out what the right thing is, we need to understand the system. One thing you could go do tomorrow to make a difference is go back to your organization and try to understand your fast package delivery and see if people know what that is. Chances are very good you’ll get different answers.
Fire That Guy
Cat Morris: The second thing we want to talk about, and this is one of the biggest blockers to change in any organization, is the resistance or refusal to change in themselves. I told it in my story, but Diana’s got a bunch of these as well. Inevitably, in any change program or any transformation, there will be at least one person, if not a whole team, that is refusing to change. If the org is expecting change to happen, if this person is there in a crucial role, you will never be able to change it. It’s a little bit flippant, but you should fire that guy. Who is that guy? This is sometimes known as the dungeon master, sometimes known as the 10x or rockstar developer. They have a hard hat with all of their ideas where they refuse to change any of them. They won’t think in a new way because, why would I? It’s all in my hat already. They have this belt where they hoard all of that organizational technical knowledge that they will only share with you under very specific certain situations.
They also have a tool belt with that magic script that fixes things at 2:00 in the morning when there’s a bug in production that only they know about. It was that, probably, I’ve had it myself, where it’s been at the expense of their own team. It’s really all out for themselves thinking sometimes with this person. They won’t change it because they are built upon power structures that mean that this has made them successful. They’re in an organization that makes that behavior successful. The one thing that I want to call out most about this individual is they say no a lot. No is their power word. They have the power to say no. If they say no, people listen to them.
As soon as you say no in any situation like this is you’re shutting down conversation. You’re not going to be able to change people’s minds. You’re not going to be able to change the way they think. Why I said you need to fire that guy, I know most people won’t have the power to. I’ve never had the power to. This is a bit cathartic, this section of the talk. It’s because it’s not your job to fix them. A lot of the time we get told, can we collaborate with them? Can we work with them more? Can we empathize? We’re not therapists. We’re not their mother. We shouldn’t have to fix them. You probably can’t fire them. What you can do, and I have done very successfully, and I think most of the people are leaders, is you put them in a box. You find the thing that they get excited about that doesn’t really have impact on the change, and you put them in that box. They’re great. They get to fix that area. They leave you alone. How I’ve done it before is I’ve worked on a transformation project where we had, part of it was pipelines to production.
The pipelines to production were very critical, but they didn’t change that often. They had a fairly static workflow. That became their area. They were the pipeline guy. As long as we didn’t need to change anything about the pipelines, the pipeline guy was happy. My team was happy. We could transform the rest of the platform. It worked pretty effectively. There is some power to no. Something we get a lot in product management is you don’t say no enough to things. I think it comes across all worlds, because we’re trying to be helpful. We’re trying to improve things. We’re trying to make things better for the organization. We want to say yes. If you say yes to everything, you may as well be saying no to everything, because you’re never going to get any of it done. You’re not prioritizing the right thing at the right time.
The thing you need to think about with no is, how do you balance it? How do you say no to the right things? How do you say yes to the right things? How do you make sure you don’t become that guy accidentally? This is where improv can come in. Because in improv, there’s a really classic concept of yes, and. If someone presents you with an idea, you go yes, and, and lean into that. You can use that with no as well. Because you’re enabling other people to solve their own problems. When they come to you with something, “I need you to do this for me,” you can go, “Ok, sure. How can I help you achieve that? How can I empower you to fix your own problems as well?” The other thing that I find really nice about improv is you are doing it with other people. You have a team around you.
Often, the leader of a team feels like they have to be that guard and that shield, but you don’t. You have a team of people that if they’re all aligned, they can support you with this messaging of, what are we trying to achieve? When are we trying to achieve it? Because it doesn’t have to be yes, and right away. It could be, not right now, and here’s when we’re going to do it, or, and here’s how we can help you. Lots of other people around you can do that too. Like I said, put them in a box.
Diana Montalion: We tried to come up with an example of where we didn’t run into this and we couldn’t. With 35 years between us, we could not.
Design Knowledge Flow
The next one is designing knowledge flow. We are knowledge workers. We are not industrialized. We are knowledge workers. Everything in production is knowledge. Code is an artifact of knowledge. We as an industry are very in love with knowledge stock. Knowledge stock is the store of knowledge that you have developed or can access. Whiteboard testing, knowledge stock. What do you already know? Knowledge stock is important because it increases your efficiency. I did not like JavaScript and therefore decided that I was anti-JavaScript and was never going to use it. In fairness, my first implementation was MooTools 101, so I had reason to hate it. Now, of course, I’m behind because my JavaScript skills are not what they ideally should be. I’m not as efficient in writing JavaScript code as somebody who’s doing it all the time. I need to improve that skill.
For systems change and for knowledge work, what we rely on is knowledge flow. It’s our ability to transfer our knowledge between people and into the technology in ways that change and shift the system. This is what increases your effectiveness. The question in knowledge flow is, how do my JavaScript skills enable fast package delivery? How do I apply these skills? How do I help other people develop these skills? How do I help Cat’s team understand the limitations that are inherent in a piece of software in order to be able to come to good decisions? As an architect, I’m not looking to be the decision maker because I try not to be the smartest person in the room if I am in the wrong room.
Instead, I want to have impact. Fast package delivery. I want to do something that really matters. This is business critical. Learning how to enable and empower knowledge work is not just good for our mental health, it’s essential for success. Larry Prusak, a professor at Columbia and has worked with NASA and IBM, and he says that those companies that don’t adapt to understanding knowledge as a force of production will slowly die and they’ll never know what killed them. Every system I’m working on that’s transforming from, say, legacy monolith to microservices are doing so in order to improve their digital knowledge flow. They will not survive another 10 years using their WordPress site, for example. We’re very focused. The friction comes from productivity, efficiency, and control, which are important, but knowledge flow is more important.
The one thing you can go do tomorrow, it seems so small, but it is not small. It’s very big. The next time you share your opinion, your recommendation, include the reasons that convinced you. How did you get there? How do you know that this is a valuable thing for people to listen to? Show people the map of your knowledge. How did you come to this? You’ll find that you increase your impact in really powerful and surprising ways.
Become Learning Driven
Cat Morris: This is a really nice transition to my next recommendation or my next fix for you, because we speak about how the systems that we’ve built are from way back when we were children. I really want to highlight that being learning-driven is one of the best things that an organization as well as individuals can do to improve your ability to get change across and to reduce that friction. This is a graphic from Professor Carol Dweck, Stanford professor, and she talks about the fixed mindset and the growth mindset.
The fixed mindset is one that that guy shows in spades, because it’s, you are intelligent. You are clever. That’s a fixed thing. It can never change. You are dumb. That means that you’re going to avoid conflict. You’re going to shut people down. You’re not going to be open to the influence of others, as opposed to a growth mindset, which is focused on the ability to learn, and that as you learn more, you can continue to learn more. It’s like an exponential curve of learning. Carol did this study in 2007 with students in New York City. She had two groups, the control group, where she talked to them about memory patterns, so the science behind it, very basic.
The other group, she talked about growth mindset, and how as you learn, you learn more, and you can become more intelligent over time. Here are her results on their grade point average on math tests, before and after. Those with the growth mindset have it increased, because they believe they can learn more if they prepare more, if they study more. Whereas the control group had it decreased. That’s just a visualization of that fixed versus growth mindset, and how it can impact your way of thinking, just by changing your thinking about how the brains function. When I was looking at this, and thinking about my story, I was like, I’ve done this. I’m the friction. Because I come in, and I say, product management is the right way to do delivery.
I get handed all of these resources, and all of the things that the architecture team, or everyone else on Diana’s team has prepped beforehand. I go, “It doesn’t feel right. I know better. I’m going to turn this into a product style. I’m going to talk outcomes. I’m going to talk value”. Without actually stepping back with a growth mindset, and thinking, what can I learn here? How did they get to these conclusions? What can I learn from the work of others that came before me?
This one’s really hard because part of the fixed mindset is it can feel like you are an idiot if you ask questions. Those fixed mindset people make you feel stupid for asking why, for being curious, and that is a negatively reinforcing cycle that’s going to force people into this fixed mindset and prevent growth. Avoiding those can be very powerful, because if you’re in a growth mindset, that has always been the most successful things that I’ve worked on. The teams that I’ve worked on where I’ve been curious, where I’ve asked why, where I’ve dug into what’s going to happen has been the ones where I’ve been most successful, not only in delivery, but also in my own personal career development. It’s the ones where I’ve got the promotions. It’s the ones where the team wants to work with me again.
Thinking about that growth mindset and being curious, even if it feels like you’re an idiot, is really important. It’s even more important in product management because a key part of product management is user empathy. This quote by Melissa Perry, who is one of the most famous product management scholars around, talks about, you have to deeply understand your users, their pain points, their frustrations and desires. If you go into those conversations trying to fix the spreadsheet that you’re getting shown by a user or telling them that their script is wrong and could be more efficient, you’re not opening your eyes to the systemic and also their individual pains and frustrations. You’re not going to be able to improve, learn, and grow.
As part of this, this product and tech friction of, I know best, the other people are idiots, you need to have that learning mindset, you need to be learning driven. The way you can do that tomorrow, and it’s another fairly easy one that feels a bit flippant, is, remember that you’ve got two ears and one mouth. You should be listening at least twice as much as you are speaking. It’s very powerful to make sure that you are able to hear what other people are saying and take it in rather than just spouting your opinion at them, because you think you’re best.
Diana Montalion: Because I know, I know what’s right to do.
Architect Relationships
What I do predominantly as an architect is architect relationships in modern systems, because long gone are the days where the bug is somewhere in the monolith. The bug is usually somewhere in eventual consistency which is a lot harder to design and to find. Donella Meadows says that you think because you understand one that you must therefore understand two, because one and one make two. You forget that you must also understand and. What I would say is that and is the art and science of systems architecture. That is where the power comes from, in that if you have one team and another team and you have them work together, ideally you get a third thing, something neither of those teams could do on their own. Same with a service.
If I form a relationship between two software parts, ideally, I get a third thing. I get some benefit, some faster package delivery that neither of those two parts provide on their own. My goal is always to understand how these relationships produce effect. How do the relationships between the parts enable something that the parts themselves don’t do directly? I am always looking at, how does information flow across the technology system? That is pretty much always my first deep dive into the modeling, and it’s where most organizations are stuck from the flow of the distribution of whatever it is they’re distributing.
What we came to through modeling our pain and ranting at each other about how much product is my problem, is that what we need is each other. That if we are able to actually solve these problems together and integrate, then we’re going to be far more successful. We are emergent. We’re going to get a third thing that neither of us have ever been able to accomplish alone. Because what we’re doing, and this is the most critical practice in designing knowledge flow but also architecting information systems, is synthesizing knowledge and experience. Other people’s knowledge and experience with your own, and using sound judgment in order to discern what really matters. What’s going to improve fast package delivery. That we create recommendations based on valid reasons. In other words, we can articulate to you why this matters. Why are we making this? What’s the information? What did we learn with our growth mindset that showed us where this leverage point was?
Most of us are experiencing friction and we don’t even know it because we’re expected to deliver linear pipelines or a platform. I don’t know what that word means because, what is it? I think you know what that word means. It doesn’t mean what you think it means. Because everybody really basically means a pipeline, which is not what either Cat or I would describe. Instead, the fix is to focus on architecting relationships. How do relationships produce effect? The one thing you can go do tomorrow is forming stealth allies. I’ve done this in every situation. Often, I’m not asked to talk to Cat. I’m not asked to watch people use the system. I’m definitely not asked to talk to the ops team. What I do is form groups of people that will communicate, use Slack, get together, form groups that can share their knowledge, can help give you feedback even if you’re not expected to do so, because it improves my recommendations. Because I need that information to be good at what I do.
Cat Morris: These people bubble up as well. If you’re wondering, how do you find them? They often make themselves apparent very quickly and very easily in those group forums.
Focus on Goals
You’ve architected your relationship. You’ve put your product and architect team together. Everyone feels happy. You’re still not delivering the results that you want. It’s because you’re not focusing on the goals. Or worse, you think you are, but you actually aren’t, because what people mean are completely different. You’ve all got different words for the same problem, or you’ve all got the same words for a completely different problem, to platform’s point. How do you build goals that are actually meaningful and everyone can coalesce around and actually get that alignment all the way up so you’re not firing your arrows at a separate target? I think it’s about outcomes. This is another product management specialist, Roman Pichler. He describes a product goal is best used to describe specific and measurable benefit or outcome that a product should create.
The product goal here I think is important because he has a whole hierarchy, that’s through the QR code that you can see, all the way from the vision of the organization that you’re working with through to the specific sprint goal, which is your two-to-four-week delivery target. That vision should align very closely to that core domain, to your faster package delivery, because that’s the top of the tree, and everything you’re working towards should be in aid of that top level target. Like I said, you want to define those goals as the outcomes that you want to achieve, not just a specific output. I’ve got some examples to make that a little bit more concrete. Instead of, implement the payment system, instead maybe we think about reducing the cost per financial transaction by 20%.
Diana Montalion: I’m like, that’s what I want to architect. I don’t want the organization to ask me to implement a payment system. I want the organization to ask me to reduce cost per financial transaction by 20%, and let me and my team figure out how the tech can do that. It was like, that’s what I want. That’s what I want to architect.
Cat Morris: It’s not just from that specifically external customer facing. You can do it internally too. I’m a platform product manager by trade, so you can do it internally. This is one that I’ve got previously, is we want to migrate the pipelines from Jenkins to CircleCI. Fine, you can do that, but isn’t it more impactful and exciting to instead reduce developer toil on pipeline maintenance by 50%?
Diana Montalion: Because Jenkins might not be the problem, let me figure out what the problem is.
Cat Morris: Let’s break it down because people always put examples like this up and they’re like, that’s really hard. How do I do this? I have three tips for you. The number one, focus on the business outcomes. Every business has a fairly small group of targets that they’re trying to do. It’s usually, make more money, reduce costs. One of those two things. Reduce risk is in there as well. Make sure you’ve got a business outcome as part of that. When I was talking earlier about going all the way from the business vision, the fast package delivery, there is some business goal tied to that. Fast package delivery, so we can make more money. Make sure there’s something in there about that, and it becomes very easy to persuade your senior leaders that you’re doing the right thing for the organization.
The second thing is making it measurable. Knowing where you started and where you want to get to is really key in knowing whether you can actually achieve the results. The number of initiatives I’ve worked on where it’s felt like we’ve delivered something improving and then we measure it and we’ve actually made things worse is significant. You need those numbers in there so you can actually track what you’re doing.
Diana Montalion: I have to ask always in this, like, where are we now so I know what 20% is, and find that difficult information to get?
Cat Morris: That’s part of the problem that makes this exciting. The last one, which is trying to bring the product and the architecture world together a little bit, is the capabilities. Here, financial transaction is a capability of your team. That means it’s very domain specific and it means that it’s differentiated. If you are trying to do something that’s very generic, why would you not just buy something to do that for you? Why are you building something rather than just getting it off the shelf? These capabilities briefly describe everything that an organization must do. These are the things that you need to do as an organization to achieve those goals that you’ve set yourself, and to make sure that you can do that overall domain mission that you’ve set. They bridge the gap.
Goals, when written well, bridge that gap all the way from senior leadership, your CTO, your CEO, through to the engineers on your team because it’s a common language that makes sense. You’ve used that language from the business teams. You’ve used it from the architecture and engineering teams. You’ve used it from the product team. You’re all on that same page. We come into this fun, ubiquitous language world again, DDD everywhere. This is one of the things that I think is so important, is bridging that gap so that you can communicate effectively. When you have that inability to deliver, even if you’ve done all the other fixes and you think you’re going great, focus on those goals by making them measurable, capability driven, and outcome specific on there.
Diana Montalion: I can’t tell you how many times I’ve said capabilities to product people and they changed it into requirements. I was so thrilled when Cat and I had the same definition for the word capabilities.
Recap
To recap, understanding the system, fire that guy, design knowledge flow, become learning driven, architect relationships, and focus on the goals.
Questions and Answers
Participant 1: I think fire that guy is really interesting. We definitely put that guy in the box. Do you have any advice for when it’s somebody a little bit higher up that maybe you can’t quite easily put in a box?
Diana Montalion: My job is speaking truth to power, because chances are the intern is right and the CEO is wrong a lot of times in what they’re asking for. Managing up is a really big part of this. The biggest question I get asked at the end of a talk, or a workshop, or whatever, is, why does nobody listen to me? This is a problem we’re all having. I rely on truth. When I go to present something that I know the leader person doesn’t want to hear, I make sure I have very sound reasons. It’s very surprising how often people say yes when your reasoning is sound, when they’d say no if they think you’re just telling them what to do.
Truth, reasoning, all of the things that we’ve talked about here have been very impactful. Also, I never go ask the CEO to approve $3 million for this budget unless I know everybody else in the room is already telling the CEO that this is the most important thing to do, so stealth allies. I’m working towards the yes before I ask for the yes. That said, I’m an American. There are times in which you can’t fix it. There’s nothing you can do. When that is the case, you have to move on. Sometimes you lose that.
Cat Morris: Often, the higher up the org you go, the busier these people are. They might say, no, I’m not interested now with your problem. Or like, no, I disagree with what you’re saying. You can go, ok. You can probably wait it out until they have another big burning issue, and then you might become a little bit more palatable with what you’re saying, because you’re not the thing that’s on fire that they’re focused on in that point in time.
Diana Montalion: We know this. Oftentimes, I just wait for something to break. One time I had spent a year, “No, no, no”. Then they almost failed to produce something that would have cost them $2 million, and suddenly I got an email with my bullet points in it from the executive, “This is what we’re going to do”. Waiting for something to break is often exactly when. Also, one time I had talked to the chief digital officer, this is what we’re going to do for the transformation. I’m saying you have to do this because the business will die if you don’t. I’m focused on fear, but in fact, I’m going to make the system better in a lot of ways. He said, no, stay focused on fear, because as soon as you tell the financial people you’re going to make the system more efficient. Their first thought is, when can we lay people off? Stay focused on fear. To Cat’s point about learning the lingo, as long as I’m telling the truth, I do create different artifacts for different people, depending on what world and context that they live in. If fear is what’s going to get me to yes, I’ll stay focused on fear.
Participant 2: If you can’t influence higher up or can’t influence an entire tribe, would you do the same thing at your team level? Would that be a good strategy?
Cat Morris: I think you have to. As product managers, we have zero actual power. I don’t manage people downwards or upwards. I have no control over anything. Everything I do is influence. Influencing that the roadmap is the right decision and we’re going in the right direction. Influencing that this is the right value we have. I need my team to support me in that because I can’t talk technical. I don’t necessarily talk financial in the same way that all the accountants do. Your team that you’ve got behind you need to be on board as well. I think that’s actually probably where you’ve got the most effective point of change. That’s the key leverage point is all of those people in your team will also have connections that they can influence. It’s very much like a network effect or a graph that sprawls out of that inward influence, as well as looking upwards.
Cat Morris: Plus, you’re exhausted. It’s exhausting. How many times have I said I should have been an accountant, but I can’t do this anymore. It’s exhausting. You need the nourishment as well. We’re alone screaming into the wind all the time. You need the other people who reinforce that it matters to keep trying to find the leverage point. To this, I want to add, the last initiative I worked on, I got to build the entire team. I had complete control over who worked on it. Of course, I grabbed people from previous and brought them in. What I discovered is when all the friction was gone and it was gone for quite a long time, it was still really hard because we’re still eight people with different brains. If I write a ticket, for example, to describe what we’re doing, each engineer wants a different ticket, wants me to describe it different. One of them doesn’t want me to write anything in it. He wants to go have all the conversations, so he can solve the problem.
Another one, and she’s wonderful, she’s the most testing person I’d ever worked with, the most detail-oriented person, she wants me to write an essay of everything I know. If I gave that essay to a different person and communicated to them that way, they’d feel micromanaged. When all the friction was gone, I discovered, we do really hard stuff. It’s hard. It was delightful to try and design information flow, knowledge flow with knowledge workers, and figure out, how can we communicate together as a team so that we can do, because it was a really hard challenge. To do this hard challenge, we had to understand each other’s brains and how to share knowledge and how to work together so that we could be effective as a team.
See more presentations with transcripts
