In this episode, Jesse and Peter are joined by Greg Petroff, Chief Design Officer at Cisco Secure, and former design executive at GE, ServiceNow, and Compass, who shares with us his experiences in elevating Design’s voice in the product development process, the importance of partnership, relationship, and communication, and why he’s hopeful for Design continued influence and impact.
Transcript
Peter: I’m Peter Merholz.
Jesse: And I’m Jesse James Garrett,
And we’re finding our way
Peter: navigating the opportunities and challenges of design and design leadership.
Jesse: On today’s show veteran design executive Greg Petroff, formerly of GE, and now head of design for Cisco Security, joins us to talk about how to be the first design executive in an organization, the role of design in defining products and transforming organizations, and some reasons for hope in the evolving relationship between design and engineering.
Peter: So we have with us today Greg Petroff and Greg, the reason we wanted to have you join us is Jesse and I are pursuing a topic in particular around what does it mean to be a design executive, like a true design executive, not a make-believe design executive that I think a lot of folks are, but like real deal, very senior, in board meetings, access-to-C-suites kind of design executive.
And when we were thinking about who to have on to address this type of topic we thought of you. You’ve done this role in a few different firms. You and I, when we’ve…. just over lunches and, and whatnot, I found you to be very reflective in thinking about what it means to be a design executive.
So that’s why we wanted you on, so thank you for joining us.
Greg: Thanks for inviting me. I’m happy to be here.
Peter: It’s an interesting time for you, ’cause you’re about to start a new design executive role and I’m wondering, and, and you’ve had a moment or an opportunity to reflect, I think on just what it means to be a chief design officer, an SVP of design. I don’t know if you have a favorite title, even we can get into that, but like what is, what, what was that journey of considering a new role?
Like and how did it inform kind of your definition of what it is that you do.
Greg: Yeah. I mean, it’s interesting. I had an opportunity this summer to take some time off and spend a little bit more time entertaining offers than I, I probably normally have in my career. That I think helped me get the right kind of perspective about what would be the right next role for me.
And, you know, if you remember Peter, you and I actually met in, in Berkeley and talked a little bit about this a couple months ago, you know, in that early part of that thinking. And I think it comes to a couple things. One, there’s sort of what I’d like to do, but there’s also what I’m good at. And, you know, you kind of have to recognize the two and you know, there’s one thing that, you know, I’ve done successfully over the last few years is create balance teams that perform well.
And, you know, I sort of see my role as being someone whose design problem is the practice of design in the organization I’m in. And and as much as I love being in the details of the individual design decisions, which I like doing, you know, my, my strength is more in empowering other people to, to be successful.
And of the opportunities that were sitting in front of me there were, there were sort of small, medium and large. And you know, I was really intrigued with the role that I am taking, which is I’m gonna be the Chief Design Officer for Cisco Secure, which is the secure business at Cisco. Very large organization, actually fairly mature with a lot of strong design leaders already in place.
But also some challenges from a transformation perspective, you know, Cisco went through a whole bunch of acquisitions over the last five years. They’re, they’re, they’re struggling with coherency. Some parts of the business are, are really effectively managed really well from what I can tell, and other areas, you know, need some TLC and, and some nurturing to help them get better. And at this point in my career, you know, I feel like that’s a good spot for me, like an environment where I can be an advocate for the other design leaders in the organization and, and hopefully set them up for success.
Defining the role of Chief Design Officer
Peter: Well, what does it mean to be a chief design officer? Was that something that they said they were looking for? Was that how you kind of shaped the role? What, what, what is that?
Greg: Wow. I, I think we’re early in trying to figure that out. They defined the role as chief design officer, so that was interesting to me because they, they had thought through a, a certain, you know, executive leadership level. The CDO has sort of three interfaces, you know, they have the interface up, which means that they’re spend time in relationship with senior leadership and an organization all the way up to the CEO and board and are advocating for design to, you know, people in the organization who may not actually understand the value of design as much as they could. And, and if they understood it better, you know, the organization probably would be more successful.
And then there’s a second interface level, which is, you know, you’re sort of leadership peers. So you know, your head of product, head of engineering, research, the, the marketing team, but people who are, you know, the SVP and VP level in the organization, and working with them to, to recognize how to successfully, you know, implement and empower their design team so that they’re getting real value and impact out of them.
And then the last interface is really about creating the conditions for the design team to be successful. And, you know, and that’s really connected to making sure that, you know, people’s incentives are aligned, right, that you’re, you know, growing your people and your talent, that you’re empowering them, that you’re finding ways to give them agency and, and you’re kind of building a growth mindset culture.
And I, I think a big part of a CDO’s role is to be actively engaged with the whole product life cycle. So not just design’s role in the product life cycle, but, you know, co-creating that with your product and engineering peers, so that there’s a shared understanding of everybody’s role in creating great product and, and, and really trying to, not build a us versus them culture, but you know, a product culture that really wants to drive impact. And, you know, CDO’s job, I think, is really to kind of wear that hat as a, you know, a partner in the organization towards, you know, really try to make impact.
Being an organization’s first true design executive
Jesse: I have the impression from the work that you’ve done, that you’ve often been the first person in these organizations with that level of executive responsibility over design. Is that accurate?
Greg: Yeah, that has actually sort of been my M.O. You know, when I joined GE which was 11 years ago, which is amazing, you know, I became a chief experience officer at GE Digital and, and there definitely was a vacuum in terms of the understanding of design and, and it was the first time for that role.
You know, I think along the path, it’s similarly, you know, ServiceNow, my time period there was a new role. They consolidated a couple of different design groups under one leader. I was the global head of design for that team and, and started build a, you know, a singular culture for the design organization. Compass, where I was most recently had a leader before I arrived, but not an executive level support leader. So it was sort of, again, a new role. And at the, in Cisco again, yeah, this is the first time that they’ve actually are building a CDO into the role. So who knows. We’ll see what happens.
Jesse: What are some of the challenges for being the first one to step into that executive level leadership of design?
Greg: I, I, yeah. Wow. I, I’ve certainly made lots of mistakes. Yeah. So, I think you need to build trust with the team, right? So the folks that are working for you, have to feel that. The things that they’ve brought to date are, are valid, that you know, that you’re not gonna rock the boat too much. You may shift things or change focus on areas, but you know, you need to gain trust of your design colleagues and the design organization as a whole. So that’s kind of a first step.
I think selling the story of design, the narrative, and getting that story, you know, so that people understand the value is something that every senior leader has to take great care at, and it’s a balance because design— the impact of design can take time. Yet senior executive attention span can be quite short. And so you have to find ways to show demonstrable quick wins and benefit, while leaving room for the things that, you know, that are actually more substantive and impact-driven, that are gonna take more time. And, and in a way, like you have to move chess pieces before you can actually get to the, you know, the outcome that you’re looking at.
And the, one of the things I’ve learned is that you have to make sure everyone understands each time you move a chess piece on the board. And you can’t just do that in a vacuum. I, I made that mistake where I’m like, you know, I’m responsible for the outcome. They got me here. I don’t have to tell ’em everything we’re doing as long as I deliver. And the reality is no, you really do need to spend time and say, “Hey, we’re gonna do this. And here’s why we’re going to do it.”
Peter: Who, who do you need to spend that time with? Are you, is that your leadership? Is that your team…
Greg: That’s with leader. That’s that’s with leadership. Yeah. Specifically, you know, I think it’s, it’s, multi-level. One, it’s with the, your direct. So, the person that you, you know, report to you know, and in, in every instance I’ve always been reporting to a chief product, you know, officer in, in the relationships I’ve been in.
So, making sure that the relationship between you and that person is airtight, that you are communicating regularly, that you’re aligned, that you understand their objectives very clearly. And that the things that you’re going to do are going to connect to their objectives. And at the same time, you have the, hopefully, the transparency and trust with that individual to bend those objectives if you feel that it would benefit the outcome that they’re looking for, like to, to sort of say, I understand what you’re trying to accomplish, and to get there, maybe we take this path because, you know, my experience says that this might get us there in a more fast or, or effective way. So that’s, that’s, it’s really important to be crystal clear at that level.
And then at some point early in your tenure, you have to sort of set a vision for your team. Because design teams in general have to feel like they’re connected to something. They have to have a sense of purpose. And, and that adds clarity, actually gives them autonomy because they can see how they might contribute to that broader perspective.
And so it, you know, at some point in, you know, as I’m imagining myself going into to my new role, which starts next week, you know, I don’t know, will, it’ll be six months or nine months, but some point in we’ll come out with a picture of what the future might look like. And we’ll, co-create that. It’s not gonna just be, it’s not coming from me. I’m gonna actually have the team help us build it. But then we be very transparent about that so that people can identify with it and align themselves towards it and say, okay, here’s how I can contribute towards that.
Setting a Vision for your team
Peter: And when you say vision is this, like a literal envisionment, some future state experience, or is it more a direction we’re heading in and desired outcomes and impact, something kind of a little more, maybe a little less specific, a little more vague, but that allows folks to fill in the picture.
Greg: It’s a little bit of both. You know, I’m a big fan of north stars. I don’t think you actually execute on a north star. You use north star to drive the art of the possible and to, and to scratch the itch on like, tough questions. And you know, words are valuable, but artifacts are more tangible and easier for people to, especially our community who are visually oriented to, you know, identify with. But you have to do them, you know, in a way where people have permission to break them and, and change them and, you know, and, and, and, and challenge them and say, you know, we’re gonna come up with something different based on, you know, the results that we have.
And then I think there’s a fair amount of of brand work. I think, you know, working with the marketing team is actually really important to sort of understand how they want to sell the product, how they want to pitch products. What’s the, what’s the, what’s the onboarding process for customers?
I mean, it’s not enough anymore just to design great product. You have to actually understand how people learn about the product, how the product is sold to them. What’s their first set of experiences using it? What happens, you know, after they’ve used it for a period of time? And a lot of that connects to the overall narrative, the story you’re telling as a company, not just from the, you know, the UX perspective, but the brand perspective and a big part of what I will work with you know, with my marketing colleagues is understanding how they’re positioning, you know, the security business at Cisco and, and making sure that the work that we’re doing aligns with that as part of that strategy. And, and so we’ll probably have a, a, you know, a couple of documents, one that sort of like a brand house with very descriptive kind of levels to it that, that describe the kind of experience and the principles around that experience that we’re trying to deliver that’s connected to how we’re gonna tell the story and the narrative, and then we’ll have some future looking artifacts that tell a story about what it could be. And then, you know, we’ll look at the period in between that and start working towards it.
Peter: At GE, Beth Comstock– it was, my understanding was Beth was a, a main advocate for building out this design and UX center of excellence. And I also believe she was a chief marketing officer. Were you, what was that? Were you in her org? Were you reporting up to her?
Greg: Yes. When I joined GE, I reported to Linda Boff who worked for Beth. And I had a very direct relationship with Beth. She was one of the great mentors in my career. She, there’s a really funny thing. My very first day at GE, I met her in, you know, GE’s corporate offices in, at the time were in Connecticut in this just sort of, you know, massive complex.
And she had one of those offices that, you know, was just enormous. And, I walked in, I had the temerity to ask her this, uh question. I said you know, “on a scale of playing it safe or getting fired, you know, like where do you want me playing in this role?” And she said, “as close to getting fired as possible. And I will give you a couple of get out of jail cards.”
Um, and uh, it was awesome. It was like a really, you know, empowering thing for a leader to say. And, you know, we, we, we did some things in the first two years when I was there that were difficult to do and, you know, were sort of courageous acts, but were the right things and, and it was really great having a leader who really supported you in terms of doing that.
Peter: You mentioned you’ve been, I guess, more recently reporting up through a chief product officer, but there you were in marketing. And I think that’s a different experience than a lot of design leaders have. The ones at least that we engage with, right, ’cause we tend— typically are talking with UX and product designers who are, are reporting up through product.
What, what, what, what was that experience like? I know that’s a weird question, but, to report up through marketing, but, you were also responsible for creating product and doing user experience work. Was that a, a happy and healthy relationship? Was it weird and, and kind of fractious, because there were different masters that you were trying to serve or how did that all shake out?
Greg: Yeah, well, it did shake out. And you know, the history of GE was kind of interesting when they did made the decision to, know, become a software company, which they already were. You know, when I joined in 2011, they were like the 14th largest software company in the world and didn’t know it, because they had so many conglomerates in different divisions, but if you looked at just the headcount of engineering it was enormous.
And so they, they recognized that they had to build in a more platform approach and and the way they started it is they built a, a software center of excellence and a user experience center of excellence. And the software center of excellence reported to GE Research and the UX center of excellence reported to global marketing.
And we were supposed to work together, hand in hand and, and we did but we had some independence at that level that you know, was one of the first early friction points, but I think ended up being a good thing for everybody. In that what we ended up doing at that point was there was, it was a really interesting role building the role at GE.
Building design systems before they were cool
Greg: There was no way for us to hire enough designers to do all the work. And so the position that we took was, all right, we are going to make the engineering teams have a toolkit that allows them to at least do reasonably good design. And so we built, you know, a design system. This is early days in design systems. You know, now design systems, everybody builds one, but in 2011 there were, you know, maybe a few out there and you really didn’t see internal houses having their own.
And we we built a design system, but we didn’t build it for designers. We built it for engineering and we built a site for engineering that was really kind of snarky and inside baseball and very GE and, and we, we built full reference design. So it wasn’t just components, but all the way to like, Hey, you’re building an analytics application, you can download this entire kit of software and just connect your APIs to it and build a key software.
And, and then we launched it in a very open source model inside of GE. So there was no perm— you know, that you didn’t have to check in if you used it. There was no review process. It was just intended to like, you know, use it, if you want to, you know, don’t, if you don’t. And early friction point for us was the software center of excellence was trying to build a platform and they were trying to get the rest of GE to use the platform. And they wanted us to only allow people to use the design system with the new platform, which I thought was a silly idea because GE had many platforms in all of its different businesses and it would benefit from having more cohesive user experience across all of its applications, and then they could fix the platform later.
And so that was a little bit of early conflict. We actually resolved it. The, the head of product who later became my boss, ’cause of consolidation of the two centers of excellence into GE Digital recognized that it was actually a good strategy for the company and it was really successful and like it grew like fire in the company.
And you know, we had all kinds of really interesting metrics. We saved the company a ton of money just in speed of development and the quality of the experience that GE customers were getting improved, you know, remarkably. Even without designers being involved. And then one benefit out of it was that teams started to recognize that, Hey, if we have this system, it would be good to have some additional designers on board.
So the organization started hiring more and more UX people because of the work that we did.
Changing the organization itself
Jesse: I’m noticing with that story, the way in which vision that you were pursuing for a particular product offering or thing that you guys are putting out in the world led to a shift in the organization itself into how it organized itself and approached its work.
Greg: Yeah.
Jesse: How much of that do you feel is necessary in order for design to be successful in organizations in terms of…
Greg: Oh, I, I, I think it’s critical. Yeah. I think you know, one of the things I think’s really interesting right now is the tools have changed so much in the last five years that the roles in software are all open for some degree of redefinition. And, and so that conversation, you know, for instance, for me, I only wanna work in organizations where leadership is willing to, to not stand on its laurels, but really is willing to look at how it works and is continuously sort searching for how it can be better.
And and that goes for how product managers work. It’s how engineering works, how design works and that they’re in constant conversation with each other. Defining that relationship and are willing to explore the boundaries where they overlap a bit and define what makes most sense for them in terms of who owns what, and, you know, one of the things I think we’re seeing more and more of is the framing of the actual outcome or the project that we’re, you– you’re trying to solve.
Design is showing up more and more in that inception moment, whereas they didn’t used to, there used to be, you know, product managers would kind of go out, canvass the market, figure out a, a product outcome, figure out like the business model for it, might even do some early kind of thinking about what it might be, and then they bring their design partners in and ask them to kind of start working on it.
And you know, what we’re seeing now is that you know, the design teams don’t have all the answers, but we have a set of tools in our toolkit that are really good at framing outcomes. And. If we’re involved early, then we can co-create, you know, together more effectively.
And so I think a big part of any of these kinds of things is transformation. It’s about helping organizations grow. It’s about changing hearts and minds, ’cause sometimes you have people who have been really successful and, and there’s, and, and, and there’s nothing wrong with that. And yet the knowledge that they have may not be what they need to move forward in an organization.
And, and so you have to be open to both listening, to like, how our profession should change. But also promoting how, what we do could help others be more successful in, in their roles. And, and that’s that’s not an easy task. Sometimes you have to be a little on the, down low to do that.
And sometimes you have to be very open and public about it, but you know, it depends on the culture of the organization and, and it’s maturity and, and sometimes it’s not, sometimes parts of the organization are great and others aren’t, right? You know, and like, you know, in GE one of the things we did at the beginning was we only worked with two kinds of, of teams in GE.
It would change later, but at the very beginning was either they totally got us and they totally understood design, and they were all in, or they had tried everything and were failing and the business was about to die. And, and, and, and those are the two teams we work with, right.
And if you’re in the middle, we didn’t have the time for you. We were sorry.
We, you know, we were growing the team. We only could work on certain sets of things, but our reasoning behind that was if we could take a, a business that was, like, struggling and make it successful, that had currency in that culture. Like, people would go, oh, I want that too, you know? Wow, can you replicate that?
And so and, and we did that a couple of times. And so, and then, because we had success, we promoted the heck out of it, and that gave us currency inside the organization. And then the net promoters, the people from the beginning, they were our friends, they were the ones who like, you know, if things were kind of tough, they could kind of support us in a moment.
So we were always, you know, willing to help them be successful. And, and there were a couple of really great people early on you know, specifically a guy named Tom Gentile who I think no longer is at GE, but he was a very senior executive in the company and had no design background, but went to school to learn it and then was all in with us.
And so, you know, like that was fantastic to have, you know, like a, a customer inside of that organization that you could have a trusting relationship with.
Building trust as an executive
Jesse: Trusting relationships I feel are such a critical part of what you do at the executive level more than anything else. Just working and maintaining those relationships and that foundation of trust. Especially early on when a design leader steps into an organization for the first time, it can be slow going to build that level of trust, to be able to do some of the things that you want to do. How do you approach that stepping into an organization for the first time building trust with your peers and with the senior executives?
Greg: Well, some of it’s just breaking bread, right. You know, like, Hey, let’s go have a beer or, you know, a meal and learn about, you know, what’s important to each other. Sometimes it’s listening to what challenges they have and offering help, even if it’s not in your alley. And, and, and, you know, supporting it.
And then, you know, obviously trust is earned. So, you know, you’ve gotta do some work and your early work has to be, you know, you know, clear and smart and you know, people have to attribute impact to it. Right? So, you know, it’s a combination of things.
I think, you know, you always wanna make sure that the, your partner is the one who gets the attention, right. So, you know, at GE, one of the things we did very early on is, you know, we, we celebrated the wins, but the win was not us. The win was the business unit. Um, And the team that made the decision to work with the UX COE.
When I was at ServiceNow, you know, I built a, a, a shadow comms team inside my org. I, I hired a young woman straight out of college with an English degree into our content design practice. But really what she did in the beginning was she wrote a monthly newsletter about all the things that we were doing. And it was always a story about, you know, someone else in the organization that we promoted, you know, SVP of product does this, you know, and, and, and here’s the decisions that they made that were great around design work, because you want to celebrate them, too.
They want to feel like they’re getting value, but they also want to feel like you’re supporting their career objectives. And so, you do it in a sincere way, an authentic way. It’s not, you know, you’re not trying to pump up somebody who doesn’t deserve it. You’re really just trying to recognize that, you know, the good decisions are happening at every level and not just within the design team that impact how the design team can work. And if you have good partnerships, you wanna celebrate that in some way.
Peter: So earlier today, I gave an internal design leadership workshop for one of my clients and one of the activities I encourage of design leaders is evangelism, is, is celebrating your team’s success. And what you said is not that, right, you’re saying we wanna celebrate our partner’s success.
And so I guess my question is, When is it appropriate to crow about yourself, to shine the light on yourself? ‘Cause if no one else is doing it, the, the risk in only celebrating partner success is people don’t realize the role that your team in, in making that successful and, and it might get lost in the organization.
So how do you make sure that your team’s work is recognized and celebrated it?
How Design’s ‘voice’ can best be heard
Greg: Yeah, absolutely. And, and by the way, I mean, the answer to Jesse’s first question was how I communicate. What I try to do with my organization is the organization communicates its role authentically at every level. Right. And so you know, one of the things I always encourage, you know, an IC 2 designer is take your engineering and product partners out to lunch, like get to know ’em well, you know we should have a really strong design culture, but it shouldn’t be so strong that it alienates the rest of the organization.
We really should have a really strong product culture of which design is a member of. And that’s what I’m really interested in, is building really great, you know, cross-functional relationships and make sure those are solid at every level. Like that’s it from a career perspective inside the team, you know constantly be celebrating the work.
So, you know, you have an all-hands meeting. It’s not about me getting in front of talking about people. Take a, a team and have ’em show their work to the rest of the organization as a whole. If there’s a product meeting where you’re showing the product to product, engineering, and design, make sure that the cross functional team is represented when they present that work, so every member of that team has a moment in front of everyone to describe what it is that they’re doing.
And you celebrate that as a, you know, a, a, a group of equals or, you know, a triad that’s solving a problem for a customer together. And you know, I made the mistake earlier in my career of, of over amplifying the design culture and alienating some of my cross-functional peers.
Like you guys are so strong, but you, you know, you don’t let us into your house. Right. And, and so, you know, for me I want to be able to build a design culture that is… people feel a part of, they feel purpose connected to it. They feel like their careers are growing in it. They feel like they’re doing great work and everyone else is invited to the party too.
And, and we’re members of a bigger party, which is the product culture that celebrates engineering success and product success and design success. Because if you start building you know, silos in the, in the roles, you know, when you have adversity or challenges or things that happen, people fall back into that versus coming together and solving the problem together.
So you know, I think for me, I’m really a, a big fan of, of, you know product as the category. And then we each have a role in it. That’s really important towards a successful outcome and, and we should celebrate everybody’s contribution.
Creating culture for your teams
Jesse: I think for a lot of leaders, especially when they get to that senior executive level, it can feel challenging to influence culture when you’re not sort of in the weeds with people. And it can feel like you’re kind of trying to send culture down from on high, you know? And I wonder, how has that gone for you?
What has been effective for you in feeling like you actually are connected to creating culture for your teams?
Greg: Yeah. That’s a great question. ‘Cause it can be very lonely sometimes in leadership roles. I, I think there, I think you have to give autonomy to your team to do grassroots thinking. Right. And and then you can build opportunities for you to have connection with your team.
So, you know, as an example, and I may do this in my new role, I don’t know, but in my previous role at Compass, I used to do a couple of things. I had this thing called Leadership Club and it was IC-4 and above and all managers except my direct reports, and we would meet once a month and they could ask me anything and they would set the agenda and we might read a book or we might, or we might invite an outside speaker and ask them questions.
But it was an opportunity for people to just sort of have a question about, you know, what does influence mean? Because you don’t have to be a manager to be an influencer. And in fact, for me, the definition of like uh IC-5 or IC-6 designer, someone is not managing people, but is very senior in their role, is that they are a massive influencer in the organization, that they have, you know, networks of people and impact.
And so that’s one vehicle that I’ve done before. You know, I’ve always supported, you know, culture initiatives where, you know, we give a budget and a team and we ask the team to, to come up with ideas. I certainly have some, but at this point I try to stay out of that and and just be a catalyst when they come up with something that sounds like a good idea.
And, and, and we can do that. You know, other things, when I was at ServiceNow, we, brought in an outside group to bring a lecture series in for us and workshops. So we had Josh Seiden and Jeff Gothelf you know put together, you know, kind of a 10, eight or 10 episode, you know, thing, which was open to design and product and engineering, by the way, right. So we had topics that were about, you know, about design mostly, but they were set in a way that we could include, you know, others into it.
And I’ve done other things. I– one year at GE I took our education budget and I spent it on the product managers. So I told the design team that we weren’t gonna go to conferences and we weren’t gonna do training. But it was gonna benefit them if we sent our product managers to design thinking bootcamp and they would actually understand us better and therefore ask for more of us or, or ask better questions of us or work better with us and…
Peter: How did that… what were the results of that initiative?
Greg: Totally worked. It was awesome. Yeah. It, it, you know, and it wasn’t that expensive. We did a couple of different workshops. There were half day or one day events and, and I’m sort of joking. We didn’t, I mean, I still had some money for education for my team, but I took a, a big chunk of our education budget and spent it on the PM community.
‘Cause they wouldn’t, it was ridiculous, but they wouldn’t. But we convinced them to come. And then after that, had sort of, you know, these A-ha! moments where they were oh, that’s why you do research, right? Like, you know, like, oh, okay. There’s an insight there. And, and, you know, that was the biggest thing we were trying to get into GE’s culture was, we had a lot of experts, and they had a lot of expertise, but they might miss a key insight if they hadn’t actually talked to their users.
And we wanted their product partners to be curious about, you know, that aspect of their world. And we wanted them to do that kind of work, but they also wanted, we also wanted them to recognize that there were people, you know UX designers and professional researchers on our team that could help them do it even better.
And, and my hypothesis was at the time that if we sort of democratize some of that process, internally inside the company, it would actually drive the need for more expertise, because as people would recognize the value of it, they would say, oh, I’m okay at this. But you know, I actually want someone who’s really good at it to do this work. Let’s hire somebody.
So, and I’ve kind of used that a version of that trick ever since, you know, at some level is to try to, you know, bring people cross functionally into these kind of a-ha moments that allow them to recognize, you know, the value of, of, of certain things.
Defining outcomes with cross-functional peers
Greg: Like right now, I’m, I’m all about co-defining outcomes. I think that’s like a missing gap in software development. And I think a lot of product teams start without actually having a lot of clarity about what they’re trying to accomplish and they feel like the agile process will help them get there and it’s just nuts. And so you know, I am, I’m all about working with product teams early on to do things like, Lean UX canvas work, or, or trying to understand, like, what are the things we know and what are the things we don’t know and what are we gonna do about learning the things we don’t know, so we can know better so that we can make better decisions. Because if you do that then your design team’s gonna be much more successful.
You know, designers need a box, they need clarity. You know, it’s, it’s funny. Like, I used to, used to say, I love ambiguity. I can surf with ambiguity. It’s no problem. But, and ambiguity sometimes can be your friend, but if you design the box, then the designer can design outside of the box or inside the box. But that frame allows them to use their time productively and really solve a problem, versus sort of meandering around lots of different solutions and wasting time. And it’s the product and design team’s responsibility, and engineering at some level, too, because engineering may have an impact on that to have as much clarity at the beginning of a project as you can possibly get because then you’ll move faster and, and the outcome will be better and it’s something you can test for. And, you know, there’s all these things that kind of benefits from doing that.
So right now, I think if I was thinking about my soapbox, it’s really about properly defined product outcomes before you, you know, invest too much time and then they, this can always change as you learn. But that’s the one thing I think that helps teams be more successful.
Peter: I hear this from the design leaders I work with, they would love to be co-defining outcomes, but they’re quote, not invited to the meeting. Things are happening before they even realize what’s going on. And by the time it gets to them, some definition has happened. It’s often not super rigorous, but, but some, some work has been done.
And I’m, I’m wondering you, you mentioned earlier, you used the word transformation. I’m assuming you’ve had similar experiences where your teams weren’t necessarily at the outset of your time there in those upfront meetings.
Greg: Yeah.
Peter: And so what, what strategies did you use to help encourage your team to, to get involved earlier that worked, and maybe what didn’t, like, did you try stuff that you thought would work and it didn’t work at all, primarily what are those things that actually get your team in the room when they should?
Greg: That’s a Peter, that’s a really hard question to answer.
Peter: I– I always default to like, complain to your boss, right? Because like elevate it, right? Because your boss, theoretically, the bosses are bought into three in a box and all this, but that always feels like running to your parents or something. Right. It’s not, it’s not a satisfying solution.
Greg: No, I think, I think this is why I think I’m… defining the PLC, the product life cycle, is super, super important for a senior design leader to be actively involved with their partners on planning, on looking at the ratios in an organization of the different roles very carefully, defining budgets together instead of in silos, right?
Instead of saying, Hey, engineering gets this budget and design gets this budget and, you know product gets this budget. What you really should say is, this outcome gets this budget and design, product, and engineering get together and figure out how you wanna spend your budget towards that outcome, ’cause you’re co-responsible for delivering that outcome.
So the first thing I’m always trying to do is get triad leadership in an organization aligned, meaning that there are three co-owners of the outcome and they have equal voting rights. It’s not easy. It’s a big cultural change. We did this at Compass. It was really difficult. But I think it made a lot of sense.
And, and, and it wasn’t like a two against one, like all three leaders have to agree and if they couldn’t agree, then they could escalate it up to the next level of a triad. And usually the next level would just push it right back down and say, well…
Peter: figure it out.
Greg: figure it out, right? And, and then, and then when you’re looking at your budget and staffing, you’d be like, okay, seems like you don’t have enough design to do this, or you don’t have enough product to do this, or you don’t have enough engineering to do this. So, you know, like what are you gonna do with the resources that you have and how are you gonna allocate against it?
And you know, that’s why I talk about like whole product teams is really important for that kind of conversation. And, yes, it’s new for design to be in that conversation. But it’s also, I, I feel like there’s a generation of product and engineering people, now, who are, they wanted to work that way because they’re tired of the, the handoffs that don’t work or you know, the finger pointing that can happen in an organization if something doesn’t happen, like design isn’t delivering on time, or engineering’s taking too long, or product doesn’t know what they’re doing, you know, and those are kind of common memes that happen in large organizations.
And, and, and then what invariably happens when you don’t have that co -ownership model, if a problem does arise, the reporting goes back up the food chain in the individual roles.
And so all of a sudden you get an, you know, an email or a phone call from, you know, the CTO, this isn’t going right? What’s going on? You know, we need to make dramatic action, right, or something. And it gets escalated and then the partners lose trust with each other because they ask their dad to get involved or their mom to get involved versus working it out together in the triad model.
You’re co-owners like, you’re responsible for an outcome and if you don’t do it, you know… So that’s a big part. So a big part for me is like making sure the incentives are aligned. And it’s really hard because each of our roles has different incentive structures.
Developing common objectives across functions
Greg: You know, designers are incented by doing great work. Product is incented usually by scope. Meaning that the more scope you have, the more seniority you have in an organization. So that can be very challenging because people from a career perspective could be just acquiring scope to grow their influence when maybe some of that scope is irrelevant or not necessary for an outcome that you’re trying to drive.
And then engineering gets measured on all kinds of metrics of like, you know, how many lines of code are written and, you know, quality defects and you know, a bunch of other things, right? And so when the, if the three sides are measured by different outcomes, then you’re gonna have challenges.
And so the conversation that I’m always trying to have in an organization is, how can we move towards a common set of objectives for every product that we’re working on? And can we organize our teams around an outcome, not a feature and not cross functional features, where I have to depend on two, three different teams to, to kind of pull things together so I can be successful. I own everything I need and we’re all on the hook. And if we deliver it great, if we don’t, we’re, you know, we’re accountable.
And it’s, it’s uh… it’s not easy. And, you know, we’ll see. I mean, I think every culture’s different. And I’m super curious, you know, when I enter into my new role, what that new culture will be like.
And, you know, I, I, at this point in my career, I probably won’t shut up about like getting ratios right. And, and getting teams their work the right way, because it creates the conditions for success. It really does. Like, it creates the moment where you can say, you know, and, and everybody wants it. Right. And everybody is keenly aware now, that the outcome of your, the, the, your product’s success in the market is connected to the outcome it delivers. And, and if there’s a comparable product in the market, how effectively and beautifully and delightfully it does it.
And so now, not everyone knows how to get there, but if you can tell the story about, well, these are the steps we need to take as an organization, and, and these steps will give us the highest probability of landing that outcome, then let’s go do that, right. And if you have skeptics, then what you do is you say, okay, let’s take a part of the organization and try it.
Jesse: mm-hmm
Greg: And then if it works, you demonstrate it and then you bring it back and, you know, kind of tell a story to everybody else about like, Hey, this is cool.
Jesse: it seems to me that driving the scale of impact that you’re talking about requires a great deal of oversight, much more oversight than you personally can provide to these processes that you’re orchestrating.
Greg: Yeah.
Building your leadership team
Jesse: And this is a, this is a topic that comes up with my coaching clients, building an effective bench at that… at that next level down below you as a leader. What are some of your thoughts about getting that team together that you can trust to run the big machine that you’re orchestrating?
Greg: Yeah. I think that, well, first of all, there’s a couple things. One, you still need to kind of know what’s going on. And so you know, I, I need to see work, and you know, I will try to find a way in this new role to continue to see work. I used to spend all day Tuesdays looking at work and it wasn’t a design review by the way, it was just so I could see everything, so if someone asked me a question, I could, I could make connections between things, but also if I saw two teams doing something similar, I might say, Hey, team A talk to team B.
Jesse: Mm-hmm
Greg: And in that role I never critiqued the work. If there was something I saw I might talk to the design leader, you know, in the background, after a meeting. And it was always about supporting the ICs, asking what was fun about what they were working on, what was exciting, pumping them up, being really celebratory in that conversation. But, you know, the meeting was really, for me, it was for me to have kind of a picture at the leadership level.
I think there’s a couple things. One you want to give your leaders as much autonomy as possible and ownership of the area that they have. And you wanna hire people who are smarter than you. You know, you know, a couple of people that I hired at GE all, you know, my first two hires could have easily had the job that I had you know, that Andrew Crow and then Dave Cronin ,you know, Dave later took over the team and Andrew later kept, stayed in marketing at GE for a period of time and took on brand for GE, which was an awesome opportunity for him.
The team I had at Compass was one of the best teams I’ve ever built. It was just phenomenal group of people. And we just look for really smart, you know, folks. I am now and, you know, kind of at this point in my career, trying to find people who don’t think like I do. And so I have some diversity of opinion and also some people who can kind of push back and, and challenge.
And so that’s one. And then I think the role that you have as a senior leader to those leaders, is mostly as a coach. And what you’re trying to do is unblock them. If they have any blocks, walk them through, you know, their strategy hold them accountable for delivering, you know, what they say they’re gonna deliver.
And as I said earlier, you know, give them as much autonomy to do whatever they need to do, including getting in a little bit of trouble, like, you know, that’s okay. Right. You know ’cause you don’t learn otherwise, you know how to do that. How to move things forward.
Peter: Kind of related to Jesse’s question, something I noticed, or reflected on, as I was thinking about the roles you’ve had over the years, is that there’s an intent in how you compose teams and I, I find you are also building particular, like, within the realm of design or user experience, cross- functional teams.
So…
Greg: mm-hmm
The composition of design orgs, and when to roll out what functions
Peter: Not just design, but research, content teams, you’ve led content teams, not every design team has content teams, but you seem to have made that part. You mentioned design systems earlier, maybe design operations. I’m kind of, I’m wondering how you think about the functions within the, this organization that you’re building and what— what’s important to you to, to establish.
As you look out, what, what are new roles or new functions that we should be considering, or just kind of curious how you, how you think about the intentionality of those practices within your org.
Greg: Yeah, some of it has to do with the size of the organization, too, right? So if, you know, you know, you’re zero to 50, it’s pretty hard to make an argument for a content practice. You can have a content designer designer on your team, but you know, it may not be a practice. If you’re a hundred then, yeah, absolutely. Have a content design team, you know, hire uh… first leader and maybe one or two people who can do that.
It also depends on the content, you know? So, you know, like if you think about Compass you know, it was a real estate technology platform that had a very specific audience and a very specific way, way of talking and a very strong brand yet the brand’s voice wasn’t in the product. So the argument for content design was incredibly important. And so, you know, we hired Morgan Quinn out of ServiceNow. Someone I had worked with before, who helped build a content design practice and, and she did an amazing job and, you know, Morgan’s now at Google and you know, thankfully she was with us for, you know, the time I was at Compass and did a amazing job, you know, building that practice.
I think you have to be careful, you know, I think you need to look at the culture of the organization, like roles, like the design ops role. You know, there are other roles in organizations like technical product manager, TPMs, PMMs, et cetera. And you wanna make sure that you’re not overlapping in responsibilities and you don’t wanna make, you wanna make sure you’re not having, like, design needs an interface to work with engineering’s interface.
It has to have an interface that works with product’s interface, like that’s… that, that, that becomes a little nuts. Right? So what you want is, you wanna look at your organization, look at the needs, look at your leaders and say, what are the set of tools that we need in place that will allow us to use our resources most effectively, right?
So I’m a big fan of design ops, but I think it needs to be about resource allocation, about visibility, and how fast the team’s working. So that when an executive comes with a, “and I need you to do this,” you have the ability to say, well, then what would you like us to stop doing? Because we’re at capacity, right?
And historically designers get screwed because they don’t have that information. So they end up saying yes, and then they try to do everything. And you know, you have to actually have the discipline to be able to say, what should we take off the board? If there’s a new thing we need to drive into because there’s a customer issue or, or, or a new marketing thing that, or, or new business outcome that you need to get to market quickly, for whatever reason you know, you gotta have that ability.
So it’s a little bit dependent. Some of it depends on, you know, are your other cross-functional partners, is the brand and marketing team really strong. If so, then, you know, you don’t have to lean in there. If they’re not so strong, you might have to build, you know, a little bit of a practice inside of your own practice that works with them to help their message show up in product.
So and then, you know, certainly in design systems, you know, I’ve managed design systems teams where I’ve had the engineering on my team and it’s been in the engineering organization. I think that there’s models that work in both. But you know, getting, getting that right, you have the right, have, you have to have the right kinds of people to do DS work, right?
You have to have designers who understand tech, and engineering who understand design and, and they have to be, they have to love working together. And, you know, the reporting doesn’t really matter as much as long as you figure that part out.
Lessons learned on the path to design executive
Jesse: So you’ve been working at this executive level for a long time now across a number of different organizations. So this question might be, might be a little hard for you to reach back and remember what it was. Before you took on these kinds of roles…
Greg: hmm.
Jesse: What did you get totally wrong about what this job actually is and what it entails?
Greg: Okay. So I, I think there’s a couple things that happen. I, I think as you grow in design leadership from a manager to a senior manager, to a director, to senior director, there’s this feeling that you get to direct the outcome and the design work and, and that you’re dictating to your design team, like, how to do the work. And there’s some truth to that.
Like, you know, if you’re in the earlier parts of your, you know, your more a player/coach, you’re in the work, you’re doing the work. And then you hold onto that for a really long time. And that can be unnerving to your own leadership. Meaning like you’re, you’re in their work, when they own it, you know, or you want them to own it, but you’re in their work. So that’s a mistake I’ve made, which is not given my, my, you know, they might do it differently than the way I would do something, but that doesn’t mean it’s wrong. It just means it’s different. And, and it still might satisfy the outcome that we’re trying to address. So learning to have that ability to detach from the work is really, it’s, it’s hard because, you know, I, I, I like designing work. I like designing things. I have lots of ideas. I have, you know, plenty of things to do, but I don’t have enough bandwidth to see most of that through so I can nudge, I can course correct, I can encourage, I can offer things to look at. But you know, you don’t want me in your Figma files. Right. So , so that’s, that’s something I’ve had to learn.
And I think one of the things I learned in my last role was to really get out of my director’s way and let them have ownership and, and, and, and let them have those relationships and let them be the person who presents that to senior leadership and and talk less.
You know, and, and that’s hard, hard, hard to do. So that’s one thing.
The other thing that I’m trying, and I don’t know if I’ll be successful at this, I have, you know, I’m very stubborn about sometimes with the way I think things should go and and I hold onto it. And and you know, you have to recognize that you have product and engineering leadership that you have to work with that may not always align with that.
I think at this point, my career’s super important for me to have like a really tight relationship with the person I report to, his peers and my peers at the leadership level, and to be really aligned with them about what they’re trying to accomplish, even if that’s challenging for the rest of my team. Because if you’re not aligned there, I can’t help my team.
And and so and, and I think that’s a hard thing because, you know, sometimes, if you’re only talking about design in those leadership meetings, you know, what you really want to have happen is you want your peer to talk about design and you want me to talk about a product outcome or an engineering issue, and you want engineering to talk about design, right?
You want to have that kind of relationship where, you know, together, you’re kind of sorting things out. And you know, and, and, and that’s hard because you know, there’s so much work to be done to, to empower designers that you feel like any opportunity in any moment that you can tell the story you should. But if you overtell that story, then you just become kind of like a, a, a parrot, right? Like people think you’re just, you know, they, they, they tune out.
And so that’s something I’m… I had to learn the hard way, you know, at some point I, I actually remember being in a meeting where someone, just out in front of me and the leadership, said, you only talk about design, you know, stop.
Balancing cross-functional peer and team needs
Peter: Stop it. But you mentioned something as part of that, you said it’s important for you develop those relationships with your peers, your boss, their peers, even when it could be challenging for your team. How would it be challenging?
Greg: Well, I mean, one of the challenges in leadership is you can’t always tell people everything that’s going on, right. You know, organizations make decisions that take time to mature. Leadership is fallible. It makes mistakes and course corrects and, and sometimes those things have to be orchestrated carefully to you know, protect the business and to support the objectives.
And sometimes those narratives don’t feel like, to everybody, like you’re really pushing the design, you know, like we’re gonna do A+ design all the time, right. And, you know, and you know, one of the conversations I’ve, you know, I have with people, which is, is, is a really hard one, but it’s like, it’s in the knowing of the project that you’re working on.
Like, are we, are we trying to hit, like, this is a bad baseball analogy, but are we hitting singles? Are we trying to get a home run? Right.
Jesse: Mm-hmm
Greg: This is a project where we’re hitting singles and it’s gonna take us two to three years to, to score a bunch of points. And that can be, for early career designer, like, horrible, right, because they’re just like, you know, I know this sucks and we’re making it incrementally better when we could really make it really better if we really, really tore it apart and, and built it the right way and did a home run. But the organization may not have the resources or the institution to, to execute on that, right. And so it’s in the knowing. Right.
And, and so you have to be able to sometimes present information in the organization to say, here’s where we’re putting a lot of attention and here’s where we’re placing good intention and good attention, but it’s, you know, we know it’s incremental in nature and, and that that’s okay too, you know, I mean, engineering makes compromises, product makes compromises, design has to make compromises sometimes.
And you know, the important part about doing that is that that’s not a consistent part of your culture and that you’re transparent about that decision making with your people, to the extent that you can be. So I don’t know. It sounds sounds that sounds completely underwhelming at the moment. Cause I’m always trying to push for us to do amazing work.
Peter: That’s kind of the challenge between idealism and pragmatism, right? I tend to be a very pragmatic leader. And so when I’ve been in situations, like what you’ve talked about, I’ve pissed off my design team because what engineering built was better than what was currently out there, but didn’t meet the specs of whatever was on the design files that, that we had created. And I’m like, well, it would be irresponsible for us not to ship something that is better than what’s out there, even if it hasn’t hit this ideal. And so, but yeah, you also want a culture of greatness and so, so trying to figure out how do you navigate pragmatism and idealism…
Greg: Yeah. And you know, and the, but there are some weird things happening right now. I mean I don’t think people have quite figured out the impact that Figma is making in our community, but engineering gets incredibly perfect specifications for pixel accurate location of every aspect of their build from their Figma files. So it’s almost impossible for them to come back and say, I did it a different way.
Jesse: Mm.
Greg: You know, if they did, you kinda go, dude, check this out, it’s right here. It tells you, you know, two point, you know, two pixels here, bup bup bup bup bup, you know and it’s even got code enabling built in it, if you built it the right way, right?
Like, there’s like a one to one to your design system, like, boom. And so some of the, the quality outcome issues that, you know, you experience with engineering teams are starting to disappear because the tooling is getting better.
And then there’s another aspect, which is we all experience great software every day. All of us do, regardless of role. And so, you know, I, I personally find engineering teams want to deliver really awesome stuff. And so, you know, like in my mind, you know, the partnership that you… that’s super important is, you know, it all three are really important, but have a great relationship with your engineering team. Like make sure that you know them, you understand what pressure they’re under and how they work. And you know, they’re just trying to do great stuff and you know, if you make their life easier, they’ll love you for it.
To your point though, sometimes there are compromises along the way and you know, that’s and you know, and those compromises invariably happen when you have legacy platforms that you have to munge together to deliver a new outcome and refactoring and rebuilding.
Some of that technology is just too hard, or there’s not an economic viability to do that. And so you put together the best possible solution you can, and it’s useful for customers, but it may not be as delightful as you would like it to be. But you do your best.
An optimistic view of where things are heading
Jesse: I’ve noticed a couple of times through this conversation that, unlike a lot of folks in the design industry, the ways in which things are changing are giving you reason to hope and reason for optimism. I wonder, what’s got you feeling the most optimistic about the future of this work.
Greg: Wow. That’s a great question. Well, I’m always half-full person. Glass is half full. And I think you have to come to the table that way with your partners.
Personally, I think some of the stuff I’m a big fan of Jeff and, and, and Josh you know, the Lean UX canvas, because I think it’s a really great model for very early on at the inception of a project of defining everybody’s insights and understanding of the program and what you’re trying to accomplish and what you don’t know and what, how you might go about learning what you need to know. And I just find that if we do more of that, then everybody’s job is more fun. Product’s job is more fun. Engineering’s job is more fun, design’s job is more fun.
And so you know, I spent a lot of my attention on trying to teach that practice, whether I bring those two guys in to do workshops, or I teach them in times of organizations. But I think that that sets the foundation for curiosity amongst the team and and builds trust. And so if you can do that, then you have a chance of doing great product and, you know, we all wanna work someplace where we have good working relationships with the people that we’re working with and that we’re proud of the work that we’re doing.
And the other thing that that activity does is it, if you define your work the right way, it also creates boundaries. Like it, it… the more clarity you can drive into a project means that you can actually deliver on timelines, right?
And the more ambiguity you have, the more likely that you’re gonna be spending weekends working on stuff, because you still have, you know, an executive has publicly said, this is gonna be delivered on, you know, June 1st. And you know, we’re ready and, you know, teams burn midnight oil trying to, to get it done.
And, and you know, sometimes you have to do that, but, but you don’t wanna do that all the time. Right. You know? And, and so I that’s, what I’m optimistic about is I think the tooling is helping. And I think that, the conversation around how we work together is changing. I do think, you know, and this may sound a little controversial, but I think that Product’s role is changing.
Jesse: Mm,
Greg: A lot of product people like to figure out how a product worked.
Jesse: mm.
Greg: I think personally Product should let Design figure out how a product should work and Product should figure out the business and the outcome and the, the value that it creates for their customer. And then orchestrate and understand what are the minimal set of things that you need to deliver that outcome, you know?
And, and that’s their role and and they should do it together. And, the, the, the Product people who understand that are a delight to work with and the people, Product people, who, uh, struggle with that are harder to work with.
Balancing clarity and partnership
Peter: Earlier, you talked about co-defining outcomes and the importance of that kind of co-ownership, that kind of three in the box ownership of product, design, and engineering,
Greg: Yeah.
Peter: and, just now you kind of distinguish between what, at least product and design, we could talk about engineering, if you wanted to add, each of them owns, because you also talked about clarity…
Greg: yeah.
Peter: … clarity of like role, clarity of function. But I find that in organizations, when you’re building something, there’s a desire for a single owner, right? ‘Cause that’s clarity, right?
The one throat to choke, which is a terrible metaphor, but often spoken. But you see it in other contexts, filmmaking, there’s a director, there’s not multiple directors, there’s a director. You are trained as an architect, there’s an architect. They, they decide ultimately what it is. How, how do you achieve clarity when you have multiple owners who might not necessarily agree?
Do you actually need, is one of them the real, even if they’re a shadow, leader, is one of them the shadow…?
Greg: Lead? I, I, I don’t know how to answer that question, Peter. I think it’s cultural, you know I understand the need for SPOA right. You know, that’s, single person of AOR accountability.
Um, you know, uh, I think that’s the, the acronym.
Yeah, right. Yeah, that’s right. There’s and I understand that. And, and certainly historically product has been the, the, the, the owner of that. So I, I think the way I think about it is, I think probably it’s still Product, but the best Product leaders share it, right. And, and they say, Hey, we’re a triad, and we’re gonna work this out together, and, and you have an equal voice.
One of the challenges you have is that, you know, historically we haven’t been in that conversation. And so learning how to be in that conversation for designers is hard. And, and including the compromise, right? It’s easy, if someone else says we’re not gonna do something, but if you say I agree to not do something, and then you gotta go back to your team and say, you know, you can’t blame anyone else but yourself in front of your team, whereas in the past you say, oh, Product, they made this really bad decision, right? But we’ll get through it. Right.
No, you have to say, collectively we came to this conclusion and here’s how we’re gonna deal it. And we’re gonna roll up our sleeves and figure out how to work with it. And you know, some of it’s hierarchical, right? So I think one of the challenges in our industry is that we are under-leveled across our, against our peers. So, you know, a director in design is usually working with a senior director in product or a VP in product, right? And, um,
Peter: and you, you are reporting up through product,
Greg: I am I report to the CPO…
Peter: That shows, right. Product is… the, the head of design is reporting to the head of product.
Greg: Yeah, that’s right. But I, I, I personally, I think that you can create the conditions for that. And then, you know, if there needs to be a, a, a, a decider I guess that’s okay.
Peter: When, when will design be ready to report to the CEO? I mean, you’ve had a lot of opportunities probably, or, I mean, you’ve been at that, that near that level for a decade now, right? Since you started at GE, you’ve been really damn close, keeps not quite happening. How do you think about that?
Greg: I, I don’t know the answers. I think it has to do the size of the organization. You know organization like Cisco, which is a hundred thousand people with, you know, sales organization and a marketing function and accounting and you know, all the other different functions that happen.
There’s a part of the organization that builds product, right. And then, and so the, the, in my mental model, it’s sort of like, you know, I report to the CEO of product and, and, you know, and, and so in a very large organization, I think the CPO is probably the right leader. I think, there, I do think there will be CPOs that were CDOs, right?
So chief design officers who become chief product officers, right. That they become, they own, they own the whole thing. I think there’s evidence of that. I mean, you look at Airbnb, you know, that pro– that’s a company that was created by a designer, right?
So I do think that you’ll start to see product, the ownership of product be there, but ultimately product has to have a leader for it. And whether that’s the product or the designer, you know, I think it’s situational as a whole.
It could be in some future incarnation that there’s a role for a CDO who is kind of, you know, looking at next level down CDOs that are working in different business units. And that person reports to a CEO. I haven’t seen that model yet. Maybe that’ll happen. I, I don’t know. I don’t know. I’m not, I’m not that worried about that kind of stuff.
Like, you know, I think my biggest thing is just make sure you make great product and the way you do that is, you know, work as hard as you can to influence the organization to practice good practices.
Jesse: Greg, thank you so much for being with us. This has been fantastic.
Greg: Hey, I appreciate it. I was really fun. I I was like thinking like, what would I talk about? And you guys asked a lot of great questions, so you got me yaking away, I’m sure. You know, all the people in my new organization are gonna be listening to this to try to figure out, figure me out. Don’t worry, guys. I don’t bite. Um, And um, uh, thanks again for hosting me today.
Peter: Thanks for joining us. Do you keep a public presence? Is there a way that people can engage with you out there in the world, on the internets, et
Greg: well, on Twitter, I’m at @gpetroff, and I’m on LinkedIn. And so those are my two kind of spots that you can kind of see me. Sometimes I’m active, sometimes I’m not. But you know, I’m out there. If you want to get ahold of me, you can just, ping me in one of those two platforms.
Peter: Excellent. Well, thank you so much.
Greg: Thank you.
Jesse: Of course the conversation doesn’t end here. Reach out to us. We’d love to hear your feedback. You can find both of us, Peter Merholz and Jesse James Garrett on LinkedIn or on Twitter, where he’s peterme and I’m JJG. If you want to know more about us, check out our websites, petermerholz.com and jessejamesgarrett.com You can also contact us on our show website, findingourway.design where you’ll find audio and transcripts of every episode of finding our way, which we also recommend you subscribe to on Apple, Google, or wherever fine podcasts are heard. If you do subscribe and you like what we’re doing, throw us a star rating on your favorite service to make it easier for other folks to find us too.
As always, thanks for everything you do for all of us. And thanks so much for listening.
Finding Our Way 