The Difference Between Engineering and Design Practices

In which Jesse and Peter dig into a few emerging trends we’ve seen in product design teams, including the rise of the senior individual contributor, the increasingly tangled relationship between design, engineering, and product management, and what it takes to lay the foundation for lasting change.

Transcript

Peter: Oh, shit. Design leaders are spending all their time managing and recruiting and hiring and, caring and nurturing for their teams, but they’re not spending any of their time leading design.

Peter: I’m Peter Merholz,

Jesse: And I am Jesse James Garrett…

Together: …and we are Finding Our Way…

Peter: …Navigating the challenges and opportunities of design and design leadership.   

Jesse: On today’s show Peter and I dig into a few emerging trends we’ve seen in product design teams, including the rise of the senior individual contributor, the increasingly tangled relationship between design, engineering, and product management, and what it takes to lay the foundation for lasting change.

Peter: One of the things that I think is interesting that I’ve seen more of during our break is a legit establishment of this design leadership role that doesn’t assume management.  So, one of the companies I’m working for, a big bank, is hiring up to 20 people who are true senior design leaders. They would be senior manager or director level, but with no expectation of management and direct reports. They are organizational leaders, they are creative leaders, they are strategic leaders. They are there in large part because those folks who do manage are so overwhelmed with their relationship responsibilities, that they need support from folks who can focus on the work.

I’m seeing it more and more, and I’m hearing from other design leaders that I’m talking to a desire to establish that role within their organizations. It’s almost like, wait, can we do that? We can have someone who’s really senior, but not manages people? Will they allow that to happen? And it’s like, yeah, if you want it.

Jesse: Well, it depends on where you are, and it depends on cultural context that you’re in because, in a lot of cases, one of the challenges with the senior individual contributor is, How do you measure the impact that they’re having beyond the work that they’re delivering? How do you measure the leadership dimension of what that person does so that the organization can know if they’ve got the right people in those senior roles?

Peter: How would you measure that if they had direct reports?

Jesse: Well, if they had direct reports, then you’ve got a broader set of data to consider in terms of the contribution that the individual is making and the success that they’re finding in the organization. It becomes about team cohesion, team success, team delivery kinds of metrics.

Peter: You measure these senior IC leaders similarly, it’s just the team doesn’t report to them. So way this is structured, and I think this is why we’re starting to see this more and more, management is functional, you’ll have design managers managing designers, and design directors managing design managers, and often not just functional within design, but like research managers managing researchers, and content strategy managers managing content strategists. This individual contributor design leadership role is a principal designer role, and s leading a team that is cross-functional within design. So there will be product designers, researchers, content strategists. 

So it’s around leading the work, not leading, not managing the resource to put it another way. And then additionally, as they get more senior, they’re very active in leading cross-functionally. So they’re not necessarily directing product people and engineers, but definitely influencing them.

And in terms of accountability, these folks are ultimately held accountable for the output of the teams that they are directing.

Jesse: So tell me about how formal authority works in these situations because what happens generally is that authority tends to hew pretty closely to reporting structures.

Peter: You’re seeing that less and less, I think, in these product development organizations where reporting is functional, but delivery is cross-functional. This is becoming an accepted just way of being. So a design director has less creative authority than the design lead within a cross functional team often, right, because the design lead in a cross functional team, working with the product manager and engineer, is making the design decisions at that level of delivery. And that is where the authority thus resides.

Jesse: Yeah. If you don’t have the ability to actively direct the work of a designer, if it is, as you describe, influence, then how do you assess how much influence you have had?

Peter: It depends on where you locate creative authority within these structures. So you can imagine at the simplest level, you have two structures: you have your reporting structure of design and engineering and product reporting up through their functions; and then you have the work structure, which is cross-functional teams. Think of that as squads, pods, whatever, where you have a mix of product managers, designers, engineers, working together. 

Now in some organizations, they are using that work structure as the management structure. But I’m frankly seeing that less and less. What I’m seeing more and more of is a recognition that we should organize reporting structures by function, because there’s value there: Professional development, recruiting and hiring, there’s value in making it clear how you grow within your function. 

But the work is being organized in these cross functional teams, which have their own structure. 

When I’ve worked in marketplace models, you’ll have a team dedicated to the sell side of the marketplace and a team dedicated to the buy side of the marketplace. and those become these work structures. And so the creative authority resides on the work side, not on the reporting side.

Design directors aren’t coming over necessarily to the work side. They are seen primarily as organizational minders, because there’s plenty of work to do recruiting and hiring, professional development, and one-on-ones, and all that kind of stuff. 

But you still need creative leaders. There can be a different authority structure specific to the work from a reporting structure. And so these super-senior ICs might report to a design director, but they lead a set of work in the work structure.

Jesse: Who looks after design as a practice in this model?

Peter: Oftentimes those leaders will also be practice leads. 

So you’ll have your content strategists or UX writers reporting to a manager of content strategy, possibly reporting to a director of content strategy. Director and manager of content strategy own the practice and the reporting relationships. The issue that arises is: I’m a director of product design. And I have product design leads, who report to me who are in the workstream leading work.

They are the creative authority for work in their area. What is my job as a creative authority as a director of product design?

And my take on it is that the practice leads—director of product design, director of content strategy, director of user research—they establish a framework for quality. So they create the shared understanding of what quality is. The people doing the work are then expected to deliver at those levels of quality.

Jesse: And who evaluates that?

Peter: So evaluation becomes an interesting question, because in my worldview, and this goes back to our work at Adaptive Path, that creative lead needs to be the sole authority over what gets launched. 

That director of product design might look at what that lead product designer’s putting out there and saying, “That’s not living up to our quality standards.” There’s a disjuncture here. In the moment, the director of product design, and unless it is truly egregious and they want to pull the emergency cord, doesn’t really have the authority to stop that work in the construct that I’m putting out there. If the lead in the moment is like, “No, this is what solving the problem. We’re going to launch it.” 

Then, if there is a disconnect between an established understanding of quality and what is actually getting shipped under a particular lead product designer, Then there’s a conversation about what’s going on there. Often, what you find going on there is that there are a lot of conditions within that cross-functional team that inhibit that designer’s ability to deliver at the level of quality that the practice lead has established. So then it becomes this other challenge of, “Do we need to encourage new organizational practices to enable us to achieve the level of quality that we are establishing?”

Jesse: Right, right. This is a thing that I’ve seen organizations struggle with figuring out, where that line is, how involved the senior most leader is in looking at the details of the creative work being produced by the leads underneath them.

And how do they influence practice and process based on that, because a lot of what you’re talking about is stuff that emerges out of the negotiations across a cross-functional team, as they are figuring out how to balance all the considerations in order to deliver. This role, as you’re describing it, that has responsibility for those practices and processes is also pretty far removed from them, and is also really just kind of seeing things after the fact. What I’ve seen is that that loop never gets closed. Energy and attention of the senior-most leader is so focused on things like budget and resources and things like that, that they don’t have the space to be able to actually take stewardship, take ownership of design as a practice in these organizations.

Peter: That is definitely an issue, especially as these organizations scale. 

But, that’s where Design Operations plays a part. 

I was actually just talking with one of the heads of product design that I work with. He has a team 80 or so, and he’s been able to get himself, right now and for the next month or so, where two days a week he’s doing what you would expect a design leader to do: going to meetings, one-on-ones, recruiting, hiring, that kind of stuff. 

The other three days a week, he’s working with a small team, small cross-functional team, on building out a vision, a product vision, a North-Star type work for the company. And he recognizes it’s temporary, right? It’s time boxed. This couldn’t be his job forever because he does need to get back to it. But he’s able, for a while, to only do two days a week doing what people consider his job-job. So he can spend three days a week being the creative leader that no one else can be in this organization.

And one of the reasons he can do it is he delegated all of his budgetary activity to his head of design ops. Just, like, “You own it. You do it. If you need me to check in, provide direction, give you guidance, whatever, happy to. It’s my org, so I care about this stuff, but literally you are going to all those meetings with the finance people. You are in charge of that now.” 

And so I think we don’t do enough to decompose the responsibilities of design leaders, and really recognize all the things that they need to be doing, and, What are those things that really the design leadership should be focused on? And what are the things that they can delegate or put off their plate? 

That’s why DesignOps is emerging, is this recognition that design leaders were spending all their time operating and none of their time leading design. But now this other thing is happening is, “Okay. So we’re delegating design operations, oh, shit, design leaders are spending all their time managing and recruiting and hiring and caring and nurturing for their teams, but they’re not spending any of their time leading design. So how do we shift those activities and responsibilities among a set of leaders so that everyone can deliver well on some aspect of this, instead of one person, half-assing a whole bunch of things.

Jesse: Right. Right.

Peter: And I hear you in terms of we’re not caught up there. And so loops don’t get closed. People are far away from the work and that’s still a problem to solve.

Jesse: It takes a village to lead design, right?

Peter: Essentially. Yeah. And I think we recognized this 20 years ago in engineering, you’ve had a VP role of engineering, which tended to be the org minder. You had your CTO or architect roles that tended to be what we would consider creative leads or technology leads, the ones figuring out how to solve the problems, the technical problems.

So there was that bifurcation happened a long time ago. You had technical program management, is this other function that was then essentially there to support engineering. With the agile revolution, you have agile coaches and scrum masters and all these other people figuring out how to keep the work engine humming.

So there had already been this recognition of all these different things that need to get done and a decomposition of activities across roles to enable that to get done, and design is just behind. ‘Cause it’s taken us longer to get to a similar scale. 

Music break 1

Jesse: Part of this really has to do with the culture of leadership within the larger organization that you’re a part of, especially how collaborative, how consensus-driven, how consultative the decision-making culture of the organization is, because in an organization that broadly asks its leaders to take a more command-and-control kind of stance, approaching leadership in this way can be really challenging, because even if it feels, to the design leader, like there is a better way to do this, that is more hands off, that distributes power and authority at a lower level in the organization more effectively, they may be contending with a larger culture that looks at what they’re doing, and it looks to them like they’re fucking it up because they’re not leading according to the model that the rest of the entire organization, including the CEO, potentially leads.

Peter: Totally. What’s interesting to me– the problem I’ve seen is actually the inverse, where the cultural direction was more bottom-up. It was autonomous product teams. Do whatever you want. The output is crappy, for any number of reasons: it’s not coordinated across these teams, plus there’s not a shared understanding of what quality looks like. And, in this one instance when leadership would review the work of these teams and say, “It’s not good enough, don’t ship it,” these teams would ship it anyway. And there was no accountability.

There was no… 

Jesse: …that loop closing. Yeah. Right. 

Peter: Some organizations could stand to have a little more top-down, command-and-control, to drive quality. 

What’s happened in this organization, is they’re at some stage in their cycle where they need a shock to the system to improve quality, and that shock is not going to come from the bottom-up. It’s too fractured. The amount of effort it would take to kind of dial up all these individual teams would be too great. 

But one of the benefits of hierarchies, when you can wield them appropriately, is to do a hopefully positive shock from the top-down and say, “No, that’s not appropriate. Here’s some new standards of quality. And if your work is not measuring up to these handed-down standards of quality, then it is not shipping,  and we need to take this approach because the problem is so severe that we need to almost explicitly work in a way that we don’t want to work, work to overcome this issue in an effort to reset.”

Try to get a new normal understood within the organization so that after you do this top-down, command-and-control for a while, there’s the understanding, the awareness, the appreciation of that built so that you can then pull back and have some faith that the teams will continue to deliver it, that new level of quality. 

So I, I almost, I long for command and control. Which goes against my, a lot of my philosophy as I was saying earlier, the authority has to be given to the person who has accountability for delivery. And that’s usually someone at that level of a product team, shipping stuff.

Jesse: So, typically, that locus of power either resides with the creative lead for the particular piece of work as you’re describing, or the person who is that person’s manager, that person’s performance manager. And this third element that you’re talking about, this senior-level individual contributor without

performance management responsibilities,feels like this extra thing in these organizations that they’re trying to figure out. How this third center of authority fits in with these other two. And organizations are struggling to give it teeth because the larger organizations are looking at design teams alongside their technology teams and the various other teams that are responsible for delivering all of the functions of the business, and trying to figure out how to make the design team look more like their other teams as much as they can, to simplify their management of a complex cross-functional ecosystem.

Peter: In the case of this one company, they have an engineering team that actually is serving as a positive model. 

What I’m sensing based on this conversation is what we’re all part of, is there is a shift occurring from whatever was standard, let’s say 20 years ago, that I think was much more like you were saying: a lot more command-and-control, the reporting organization was also the delivery organization. Your manager was responsible for your performance and your output, and their manager was responsible, and, and it was cleaner in some way.

And then what happened essentially, is this recognition of, in the 21st century, to succeed in doing work requires cross-functional teams. You cannot go inside an organization that doesn’t recognize the importance of a truly cross-functional team. We’re talking design and engineering and product management and data science and marketing, like true cross-functional teams. And the model before was you didn’t collaborate cross-functionally, you did your work and then you handed it off to the next function, and you handed it off to the next function. And so that, it’s not even waterfall model so much as this kind of yeah, the production line model.

It doesn’t work when you’re trying to be nimble, responsive. When you’re working in a world of software as a service and, you’re constantly shipping and all that kind of stuff. And so they’ve moved to this cross-functional team where you have representatives of those functions present at all times.

We still don’t quite know how to manage complex cross-functional delivery. We know how to manage functional organizations. Certain aspects are still being managed functionally—your professional development and, and your, performance reviews and the skills growth and all that kind of stuff

We don’t have clear, well-understood models of how you manage cross functional teams, particularly at scale. 

To take what you said moving forward: I just think we’re not there yet. There is not an answer. We’re still figuring it out.

And what I think we’re seeing is that issue, the challenge, conflict, that soreness that is happening with design leaders is because we’re trying to manage cross-functional work teams akin to how we managed perhaps in the past, these hierarchical teams and it’s not quite working.

And so now we’re trying, let’s go the other direction and it’s all autonomous and every team’s on its own and that’s not working. And we’re stumbling toward what is a model that allows functions to work well together as teams at scale. And no one has really solved that in a clear, repeatable way that people can feel pretty good about.

Jesse: It’s interesting that you keep referring back to development methodologies, in that I think that for most of my career, if not all of my career, the conventional wisdom among designers would have been that you should not attempt to manage design the way that you manage engineering, that engineering management practices are too factory floor production line oriented.

They don’t have enough flex or space in them for the creative exploration that’s necessary for design. That design as a practice was fundamentally incompatible with the way that technical development gets managed. And it feels like you’re saying that if that was true, that maybe is not as true anymore, or even perhaps that the folks who have been doing this work to define these approaches to technical development have lapped us basically, and gotten out in front on these issues of how to get multiple functions actually integrated together effectively, which is really different from, frankly, most of what I’ve heard from most designers for most of my career.

Peter: So they’ve lapped us. I wouldn’t say that they’ve solved it though. If you ever hear of a designer embedded in a product team, squad, scrum, et cetera, that is a model created for engineering delivery. And, it is not a model that leads to good design, but they got out in front of us.

They’ve been dealing with these problems longer because engineering orgs tend to be bigger. The value of engineering was more evident to internal leaders. And so they built out engineering orgs sooner.  But these, what are meant to be cross-functional, organizational frameworks definitely skewed towards  supporting engineering over the other functions. That’s actually one of the reasons we wrote the book, was I saw this occurring and I was frustrated because you are right. Design works best in its own way, not by adopting engineering processes. But when design got subsumed into these, what were supposed to be cross-functional, team structures, that were really about how do we help engineering be as effective as it can be, and to heck with anyone else,   design suffered in that regard.

People often forget that much of what we think of as agile is simply a way for engineers to to assert the authority over their work, because it had gotten away from them. They were being told by managers, who didn’t actually understand what it took to deliver, what to do. And the engineers were like, no, we’re taking the reins back. Right? It was their own form of, frankly, a kind of quasi-Marxist maneuver. What’s happened, though, is designers haven’t yet done that themselves. Designers haven’t taken those reins.

Music break 2

Jesse: All of this makes me very curious about the work that was done by technology leaders, you know, 15 years ago to start pushing the

process and organizational change in these organizations, away from the way that software had traditionally been made up to that point. And how they were able to make the argument for such a radically different style to their leadership.  Because, frankly, that is one of the things that we as designers and as design leaders have had the hardest time doing, is simply convincing our leaders that there is a different way to do things and we should be given the permission to try.

Peter: Part of their ability to make that change is the phrase, “Double the work in half the time.” And what CEO isn’t going to like pause for a second. 

Jesse: “Tell me more,” 

Peter: “Yeah. I want some of that.” 

I think the challenge, I hadn’t thought about it this way, but it kind of goes back to what you were saying about the difference earlier, but just between engineering practices and design practices, engineering is measured on productivity and how they define quality, which is uptime, no bugs, stability, performance. All very mechanized outputs. 

Engineering is not held accountable for business success. Engineering is not held accountable for customer engagement. Engineering is not held accountable for all those fuzzier, squishier impacts on users and customers. Engineering is held accountable for, Are our machines able to do what we want the machines to do?

If all you want from design is more design, then, yes, you can put design in a similar context and you will get more design, but that’s, yeah, it’s laughable ‘cause it’s meaningless and, there’s just this fundamental difference in the paradigm of what the value is that design delivers and the value is that engineering delivers.

Jesse: And I think it comes back to how that value is communicated to and understood by the senior business leadership.

Peter: I thought tou were going to say, “Senior bean counters.”

Jesse: That, yes, those, too. So, as you describe the agile transformation, it sounds like those people were able to speak to value in a way that their nontechnical leaders could understand, right? You didn’t have to understand the ins and outs of technical development processes in order to be able to understand the value of “double the work in half the time.”

And we don’t even have ways to talk about the value that we’re delivering now, nevermind talking about increasing that value in the future. They already had a reference point for engineering when agile came onto the scene. They had ways of evaluating. They were maybe not the best ways, but they had ways of evaluating that were needles that they could see would be moved by a move to a different approach.

And they don’t have that for us. They don’t have needles that they can look at and go, well, this, and this, and this will obviously change if this works the way that you guys say it will.

Peter: They do and they don’t. Unfortunately the needles they have for us are productivity needles. That’s why I think much of design as it has scaled has also been reduced to output. My question or my, my wonderment based on what you’re saying is, nor do they have metrics to justify more product management, but they invest in it.

Jesse: Okay. So what’s that about?

Peter: That’s a good question. I think about this.. I found myself thinking about it again more recently. I find myself wondering why companies keep hiring product managers. They love hiring product managers, but what ends up happening is from a ratio standpoint, you get these ratios out of whack, where you get multiple product managers for a single designer.

And I’m like, “Why do companies keep hiring product managers when they don’t have the team to deliver what the product manager is working on?” And I think the reason they keep hiring product managers is that product management is a promise of future value. 

Jesse: And design is not even that, is it?

Peter: It’s not recognized as that. We know it is, but it’s not recognized as that. So, by hiring a product manager, you believe you are enabling the ability to deliver more product, new product. And with that delivery of more, a new product, the generation of increased value. So, you hire product managers because for every product manager, we can launch another feature and another feature.

For some reason, what’s not fully understood or appreciated is when you have product managers, the job of a product manager is to make work for other people.

Jesse: Hmm.

Peter: And so you have all these product managers generating work, but if you’re not also hiring engineers and designers and others at a similar clip, what ends up happening is, and I’ve seen this, I’ve been in environments where product managers almost literally are walking the halls with requirements, looking for someone to execute on them, just like, “Do you have time? Can you, can you help me build this thing?”

And now everybody else is somehow pulled into this person’s insanity. It leads to all these problems. That said, thinking about what you were saying in terms of design and the ability to cleanly and clearly value design, design’s value is

essentially the same as product management value. When you want to look at it from a business lens, designers help you with acquiring new customers, help you with retaining customers, help you engage customers, help you potentially get those customers to spend more while they are engaged. So, you know, unlocking more revenue or whatever, right?

Those are all metrics that a business cares about. That doesn’t take a lot of imagination to connect a designer’s work to those metrics. Those metrics though, tend to be owned by product, but product doesn’t actually deliver on those metrics or do anything to make those metrics happen.

Usually they rely on their teams. And their job is to coordinate the efforts of those teams towards those business goals. As we said, though, the engineers, their metrics aren’t really product metrics. Engineers’ metrics are engineering metrics with this assumption that, I guess, a magic in the system, that if the engineers focusing on their metrics keep machines running and product is focusing on their metrics and value creation, then it’ll all work out. 

Now, this is a thought I hadn’t had before. And I think that the hidden connection that hadn’t been realized was the designer is the person who turns that engineering quality into value realized by the product manager.

Jesse: And is cut out of the equation altogether themselves.

It feels like there is, is a lack of things for designers to uniquely own that have value beyond the aesthetic, beyond the subjective.

Peter: That is basically true. There is no meaningful design metric that isn’t also a product metric.

You’re making me want to look up a tweet. Hopefully it won’t take long. 

On February 23rd, 2020, Jared Spool wrote, “I’m of the belief that in a few years, product management and UX design leadership will be indistinguishable. In some orgs they already are.”  And that, I think, speaks to what we’re talking about. 

Jesse: Yeah. I think most of the time, if you look at two different functions in the organization and they are impacting the same metrics, that seems like a pretty good argument that those functions should be combined in some way. You know, maybe design is an adjunct to product management, maybe there is a space for a design practice that is more fully integrated with product management as a way of sort of borrowing that understanding of value and being able to transfer that to the design work. Should designers be reporting to product managers?

Peter: Product managers. Hmmm, no. At least not the way that it is typically practiced in most organizations. I think this is another area, as the tweet suggests, we’re seeing change and evolution. 

There’s no reason that that product manager can’t be a designer or could not have once been aa designer. And we’re seeing that all throughout the industry, more and more designers are turning into product managers. It’s still the vast minority, but we’re seeing a greater and greater acceptance of designer as product manager, as opposed to historically it was MBA as product manager or

engineering lead as product manager. We’re now seeing companies realize like, oh, the product is this thing that people use. Maybe the person who’s managing the product should have a ability to understand that use.

Jesse: I have been advocating for at least 10 years now that designers who actually want more authority, want more power, need to move toward product management. They can do product management from a design sort of stance. I don’t think it means leaving behind that creative influence. And in fact, I feel like there is something missing in the practice of product management, as I’ve seen it, that designers bring, which is this holistic experiential sense. That is not something that I’ve seen a part of how product managers do their jobs. 

Peter: Right. No, that’s and, that is, I think, largely true. It is changing, but still largely true. It was probably about 15 years ago that you created a talk called The Experience is the Product. Which I don’t think we realized at the time what we were saying. Organizationally, we were just commenting on what we saw in the world, and that instead of focusing on products as these one-offs, we wanted to encourage people to think about a broader experience context in which these products sat. 

I have a 2020 version of that talk still called The Experience is the Product, which makes much more explicit that connection between user experience of the word experience, and product management of the word product and that user experience and product management are essentially the same thing.

Music Break 

Peter: One of the companies I’m working with has come to a realization that the quality of the product that they are delivering is subpar. A few years ago, they brought on a very senior design leader who came in, was given a mandate, looked around, was like, “This isn’t great. I gotta do a lot of stuff. I got to fix this,” and wasn’t able to get traction. Wasn’t able to make kind of change happen that they realized needed to happen. And three years later, this team is still producing crap. As I started digging around, I found out that there had also been, within the last couple of years, a new head of product management and a new head of product marketing hired, who similarly came in, looked around, said, “Oh, I gotta make some changes.” And realized much greater success in making changes in their part of the organization. 

So, my initial concern was that it was some type of broadly cultural thing, but no, this new head of product was able to do a real reorg, make some real changes. Their new head of product marketing basically changed how they do product marketing, like the processes by which they operated. And I was like, “Why is it that this new senior design leader wasn’t able to realize their vision, the way that this person’s peers did?” And as I unpacked it, I found out that this new design leader, their leaders didn’t have their back the same way that the product management and product marketing leaders basically ran cover for these new leaders that they brought in. 

So when the new product leader or the new product marketing leader is making these changes and ruffling feathers and pissing people off, and the message is going back to their boss, “What’s what’s going on here? So, and so’s doing all this stuff. This is new, it’s different. It’s not right.” Those leaders were like, “You know what? That person’s in charge. If this is what they think needs to happen,  they have my full support.” in this design context, when that happened, those super senior design leaders told this new design leader, “Hey, Hey, you need to back off a bit. You’re upsetting people. You’re not doing it the way we work here.” 

And what it pointed out to me is, however senior you are as a leader, you need another leader to support you in the change that you are trying to make.

We tend to think that leaders are almost operating on an island or like if they have a strong enough vision they can just carry people forward. 

And in reality, leaders need leaders to protect and cover and enable and support them. And it’s not something I had been as cognizant of, until seeing this side-by-side compare-and-contrast of a leader who’s been given that cover and the change they were able to make, and a leader not given that cover and them getting stonewalled.

And now years later, I’m hearing that this leader maybe isn’t delivering up to what would be expected. And it’s like, “Yeah, because they weren’t given the support they needed when, they were like, ‘Hey, we should do these things.’”

Jesse: You didn’t let them optimize the environment for their own success… 

Peter: Yeah, yeah…

Jesse: …so don’t be surprised when they’re not successful. Yeah. Yeah. And, this goes back a little bit to what we were talking about a few minutes ago, about the early days of agile and how those folks made the case for that change in those organizations.

And it did eventually take somebody up top who didn’t understand the deeper implications, who didn’t understand the reasons for all of the changes, say, “I don’t care that I don’t understand it. I believe in you. And I believe in what you’re doing and I believe you’re the right person to orchestrate this.”

And that I think is a level of credibility and trust that engineering leaders had circa 2005 as they were starting to push agile as process change, as cultural change, in these organizations, that designers haven’t gotten to yet. And in fact, product managers have stepped in and they’ve already got more power than we’ve got and they just showed up.

Peter: Yeah, I think it ties back to what we talked quite a while ago about trust and about relationships. And I think a lot of design leaders don’t know how important it is to manage up and manage those relationships well, in order to then manage down to get what you want.

They come in, look around, they see the problem. They feel it must be evident to everybody and they start trying to make change and it tends to be out and down. ‘Cause that’s where they’re seeing problems are. And they haven’t done the work to manage up, to play the politics, to get the relationships, to get the connections, to get the cover so that when they then do manage down, it’s going to ruffle feathers, right? Change, upsets people. So you need to have prepared yourself and others for that disruption and seeded the ground appropriately to make sure that when there’s the hue and cry about change, you are enabled to continue that change.

Not encouraged to just roll it back.

Jesse: And I think it’s on the design leader as well to accurately assess the organization’s true appetite for disruption. 

Peter: Appetite for disruption! 

Jesse: Our new album. 

By the way, you have to know that your leadership is already on board with the chaos that’s going to come with change before you start trying to make it, because if you start trying to make that change when you’re not sure if your boss wants it or is ready for it… I mean, we ran into this over and over again, as consultants at Adaptive Path, where would come into organizations, we would be working directly with a client who was very motivated to create change, had gotten the budget to bring us in and had spun up a whole bunch of work around creating that change. But had not accurately assessed their leadership’s appetite for it. And the work ended up dead in the water as a result.

Peter: Totally. Totally. Yeah. and while it would be easy to point fingers at the super senior leaders for not providing the cover for this new leader to realize the changes they wanted, I did also realize that this new leader hadn’t done their diligence in making sure they’d had the relationships established.

They had gotten very problem-focused and “I’m just going to solve the problem,” which designers do and had lost sight of the people parts around that. 

Jesse: And this is really what was behind my pivot toward leadership coaching,  helping individuals maintain that level of awareness and that level of engagement beyond the tactics of delivery, toward: look around the room, who are the people in the room and how are you engaging with them? Because it’s very easy to think that these problems can be solved with more process when actually what you need to be doing is having conversations with people. 

Jesse: Well that wraps up another episode of Finding Our Way. Thanks, Peter.  

Peter: Thank you, Jesse. 

Jesse: He’s @peterme. I’m @jjg.  

Peter: You can find us on our website at https://findingourway.design/, where you can also find past episodes and complete transcripts of every episode, as well as a contact page where you can send us your thoughts. We read everything that comes through, and those submissions have often spurred further discussions.

Jesse: Thanks, Peter. 

Peter: Thanks, Jesse.

Peter: Me me, me, me, me… Do you have a top knot or back knot or something?

Jesse: I have a, I have a high pony.

Peter: Is that what it’s called?

Jesse: That’s what I’m calling it.

Peter: So you have a pony that is high.

Jesse: Yes. Yes.

Peter: It’s those Oakland oats.

Jesse: It’s, it’s wandering around my backyard. Just sort of like eating everything.