Greg Petroff
Practical Executive Design Leadership
In this episode of Brave UX, Greg Petroff discusses the practicalities of executive design leadership 👨🔧, why he believes in ‘make to think’ 🏗️, and the ins-and-outs of working with product and engineering 🔀.
Highlights include:
- How much advocacy for design is too much?
- Why do you prefer project-based teams over product-based teams?
- How do you align the engineering, product and design organisations?
- How have your recent experiences in the labour market changed you?
- What does effective compromise look like in enterprise software design?
Who is Greg Petroff?
A 25 year veteran of the design field, for the past 10 years Greg has led significant design organisations at some of the world’s largest and most recognisable companies 👀.
Until recently, he was the vice president and chief design officer of Cisco Secure, where he led the design innovation and transformation of one of the world’s largest cybersecurity solutions providers 🔒.
His highlight reel also includes being the chief experience officer at GE Digital, managing director of Google Cloud ☁️, vice president and global head of design at ServiceNow, and senior vice president of design at Compass.
One of the early members of our emerging field, Greg is a founding board member of the Interaction Design Association 🔷, where he also contributed as the treasurer and as an early conference chair.
A generous contributor to the field, Greg has shared his insights on stages across the world, including at TedX, the Interaction conference, UX Australia, Enterprise UX, and on the most-excellent Finding Our Way podcast 🎙️.
Transcript
- Greg Petroff:
- For those of us who work in enterprise and in tech, we're in this weird moment where the AI story is sort of driving decision making and the decision makers we're looking at that are all focused on the technology.
- Brendan Jarvis:
- Hello and welcome to another episode of Brave UX. I'm Brendan Jarvis, managing founder of the Space InBetween, the behavior-based UX research partner for enterprise leaders who need an independent perspective to align hearts and minds and also the home of New Zealand's first and only world-class, human-centered research and innovation lab. You can find out more about me and what we do at thespaceinbetween.co.nz.
- Here on Brave UX, though it's my job to help you to keep on top of the latest thinking and important issues affecting the field of design. I do that by unpacking the stories, learnings, and expert advice of a diverse range of world-class leaders.
- My guest today is Greg Petrof, a 25 year veteran of the field of design, and for the past 10 years, Greg has led significant design organisations at some of the world's largest and most recognisable companies.
- Until recently, he was the vice president and chief design officer of Cisco Secure, where he was leading the design, innovation and transformation of one of the world's largest cybersecurity solutions providers.
- His highlight reel also includes being the chief experience officer at ge, digital managing director of Google Cloud, vice president and global head of design at ServiceNow, and senior vice president of design at Compass,.
- One of the early members of our emerging field, Greg is a founding board member of the Interaction Design Association where he also contributed as the treasurer and as an early conference chair.
- A generous contributor to the field, Greg has shared his stories and insights on stages across the world, including at TEDx, the Interaction Conference, UX Australia, Enterprise UX, and on the most excellent and my humble opinion Finding Our Way podcast.
- And now he's here with me for this conversation on Brave UX. Greg, a very warm welcome to the show.
- Greg Petroff:
- Thanks, Brendan. I'm happy to be here.
- Brendan Jarvis:
- And I'm happy to have you here. Greg and Greg, you have a fascinating background in terms of where you've come from, how you made your way into enterprise design, and I wanted to just start with what I understand was your first love in terms of professional love and that was architecture and it's coming up, I think it's about 30 years since you last practised architecture and you shared with me you still renew your professional licence every year, and that's a lot of years to be paying fees for something that you no longer do. What's the story there?
- Greg Petroff:
- Yeah, I have two degrees in architecture. I practised as an architect early in my career. I taught, I was an adjunct faculty member at UCLA in the early nineties, and I was part of the first generation of architects who use 3D graphics. Now it's commonplace, everybody uses it, but we were sort of on the vanguard of information visualisation and building visualisation and simulation. And in the dotcom era, I was doing work as an architect and then I was doing work for other architects and then I was doing, all of a sudden I was in the Los Angeles area. We got discovered by sort of the Hollywood scene as people could do pre-visualization for film and television and special effects work. And so all of a sudden I found myself doing that kind of work and then I had a creative company that got purchased by a technology company and then all of a sudden I wasn't doing architecture anymore.
- I was in this space into kind of new media and new technology and really UX before we even knew what UX was. And so that was the path out. One of the reasons why I maintain my architectural licence is I work so hard to get it and it's a passion and a love. I still find great value in being part of that community. I think there's opportunities for sort of things we've learned in the UX community to inform architecture and certainly the practise for architecture can inform the way we do design work. And so staying close to both of those has been meaningful for me and long term, I have a vision of what I might do when I'm older and deciding to not have to work, but it's still working. I have this sort of dream of having a little office with a front door and actually no one comes through the door. I just sit in the room and draw pictures of buildings during the day and maybe have a cocktail in the afternoon and call it a day. So it's always been a part of me and something that I've valued and I've learned from along the way.
- Brendan Jarvis:
- That description sounded very much like college.
- Greg Petroff:
- Yeah, exactly. It would be fantastic to do that. And I actually have this idea for this idea, I'm calling the office of Improbable Architecture, which is something I'm teeing up for the next chapter of myself at some point.
- Brendan Jarvis:
- Well, speaking of things that are improbable and things that are probable, and in this case things that are possible, you shared with me earlier that your spouse calls you a poss, but I wasn't really sure of whether or not they felt that was a good, bad or otherwise type of thing. And I was curious to get your step up on the balcony view here as to what it might be like for them to live with someone who is a possibilitarian.
- Greg Petroff:
- That is a great question because I think there are many positives and there are some challenges for the people around you as well, because I'm a problem solver and I'm also a person who can think of endless possibilities to solve or resolve or create a better solution. And so when someone comes with a challenge, my first instinct is to come with all sorts of solutions like, oh, well we could do this or we could do that, or It's not as bad as you think. It's a learning opportunity. It's with constraints come opportunities, we can create something special out of all of these challenge that we have. I've learned over time that sometimes people are coming. That's not what they're looking for. They're looking for you to say, I understand. And so I think for my spouse, she loves the fact that I am able to envision multiple futures for us and multiple opportunities for us as a family and as a community that we're part of. And at the same time, occasionally for her I drive her nets. So yeah, that's a great way to frame that question.
- Brendan Jarvis:
- That sounds like a pretty healthy relationship. What is the meaning behind Possibil? What does it actually mean? How did it come about?
- Greg Petroff:
- So I have lots of friends from university who are architects. They're still architects. And years ago we were all together in a ski cabin somewhere in the Sierras, and my architecture friends were trying to understand what I do, and they really, they were challenged by what does a UX person do and what's the realm of the things that I am working on? And the first name that came up, one of my friends called me an ethnographer, and he goes, I know what you are. You're an ethnographer. And I said, well, what does that meaning? He goes, well, you're the guy who studies. What if another person dropped in? Well, isn't that the art of the possible? And then my wife said, yeah, he's a possibilitarian. So that's kind of the landing point of that. That was about, I don't know, 10, 15 years ago. And it stuck with me because I think one of my sweet spots is creating space for ideas to percolate and to give them room to grow.
- And I think that one of the things that designers bring to the table that's really valuable is that we're makers. And so we make to think a lot of other people think to make, there's nothing wrong with thinking to make, but making to think. The artefact oftentimes will allow you to explore the space that you're interested in faster and more quickly, and the answers come faster because the actual craft of making and the medium that you're using, you have a conversation with that. And in that conversation, the answers become clear of what is and what isn't.
- Brendan Jarvis:
- It's not that I disagree with making to think as being a really valuable way of creating a product. And I've heard you talk about that before, particularly when you're creating new product, that's often quite a powerful way to jumpstart the process and actually tease out whether an idea is good, bad or otherwise. However, I think we've probably both seen, correct me if I'm wrong here, particularly an enterprise software software that's been made with perhaps not enough thinking or perhaps not enough design thinking at the outset and the downstream effects that can have in terms of the, I suppose you call it UX debt that it can create. How do you navigate those situations with a make to think mentality? Can you use that mentality and that approach to sort of improve the status quo in any meaningful way
- Greg Petroff:
- You can? I think the step one that you may want to take ahead of it is really focusing on the outcome. I'm a big fan of Josh Side's book Outcomes Over Output. Josh is a really good friend of mine, and we've known each other for 20 plus years. We were both founding members of IXDA together, et cetera. But I find that if you can map the way people are solving problems currently, then you can look for the opportunities for how you can make it better. But if you haven't done that map, then you're just guessing and you don't really know. And you also don't know what is the most valuable set of things or activities that customer values. Customers don't really buy features, they buy outcomes even if they can't articulate it that way, but they're trying to accomplish something. So if you can focus on what are the most important things that your product needs to deliver and what value it creates for the customer, and then work backwards from that and sort of look at the flow of work, how the workflow gets accomplished, what are their workarounds right now, what are the tools that they're currently using?
- And then you can start to identify opportunities for improvement that clarifies that early thinking and it helps product engineering and design prioritise. And I'll give you an example of this. At Cisco, when I first got to Cisco, we were building a new product and we had a window in the market to deliver the product to stay relevant. So they knew that that product had to be released last summer. And so they had about nine months of runway, and that's a very short period of time for an enterprise piece of software. And the product team had gone out and done their work and came back with a feature list of somewhere around 480 features that they thought the product needed to be successful. The engineering team was freaking out. They were like, we don't have the capacity to do 480 features. Product can't tell us the prioritisation of these features, so we're just going to start on A and go to BCED until someone tells us otherwise that's how we're going to tackle it.
- And I'm like, well, that's not going to deliver a great MVP or first V one of the product. And so we got everybody convened and we said, okay, what are the top 20 workflows that people are trying to accomplish? And let's diagram them in detail and let's go validate those with customers at how they solve that problem. And then what are the least number of features can we use to deliver on those top 20 use cases or workflows? And then we reduced it down to 10. We said, well, these top 10 actually are a viable product and we'll demonstrate to our early customers that we mean we're building something of value for them and that they'll buy even knowing it's not complete because it's actually significantly valuable for them, even with these 10 kind of workflows done really well. And we reduced the total number of features to about 180, and that was doable within the budget and capacity of the engineering team, and we delivered that and the early reviews from customers were really strong because of that.
- So basically a focus on outcome-based thinking is super, super valuable. And then at that point you can use the make to think effort to like, okay, now we know the box that we're in and the thing that we're trying to accomplish. What are the different ways we could solve that problem? There were a bunch of benefits to this work. First of all, it allowed the engineering team to start and design was no, they were expecting us to show up with wireframes for everything, and we hadn't even started. So we really had to be in an agile model where we were maybe three weeks ahead of their pipeline of engineering work, but they could do core things because they understood the structure of the work that was coming their way and what kinds of backend engineering they could start with that would support that, what kinds of things that they could put into production early. And then product really enjoyed it because I gave them clarity in talking to early customers like, Hey, these are the workflows that we're going to deliver and we believe these are the most valuable and here's why, and then here's the next 10 that are coming after it. And so I think that's a model for building a product culture that can work and get people off the feature train, which can often be where you put in a lot of debt shows up from.
- Brendan Jarvis:
- How did you work with product and engineering to, you mentioned prioritisation and that there were these 400 features and they weren't prioritised. You nailed it down to 180. How did you work with them to figure out what should be made and in what order? Yeah,
- Greg Petroff:
- Well again, it came down to the outcomes. So we said, okay, this is outcome number one. This is the most important one. What are the set of things we need to do to get there? Well, let's focus on those, the screens and the components. And this is an interesting project too because we're in the middle of building a new design system at the same time that was sort of going to be just ready for everybody. And so we had an additional restriction on the project, which is we had to limit the grammar that the design team could use to about 35 components. And you can build almost anything with 35 components, but you may not be able to build the most optimum solution with only 35. But we were very rigorous about it. We're like, we're not going to have any bespoke components. We're going to use the ones that are going to be off the shelf and engineering ready because we have this window of time that we have to get to now we can post launch as we go into V two, the product, we can start to introduce more conditions and we can start to fill in some of the spaces that we know may could have been better, but we know we could build a really elegant and decent solution with the 35 that we had.
- And that allowed us also to move very fast. And it kept the design teams focused on the intent and the flow of work over the shape of the applications. And thankfully the design system we had was very elegant and simple and easy to use. And so the two things worked really well together.
- Brendan Jarvis:
- I've heard you talk about the harsh realities that as a executive design leader that you're faced with. And in fact, this reality that I'm about to mention is faced by the wider team in terms of the practising designers, the craft focused designers that work in your orgs. And you touched on that there, and I don't want to suggest that the product that you were working on, the first version didn't have a great design, but you've previously spoken about times where great design can't be executed because there's a limitation. In this case, it was the design system that was underway and therefore constricted the amount of components you could work with. I believe you've got sometimes it's money as well, sometimes it's organisational will, I believe you've got an analogy that, a baseball analogy that you often use to kind of illustrate this. I suppose the compromise, if that's the correct word, that is faced in these situations.
- Greg Petroff:
- Yeah, I mean I think when you manage a large team in enterprise software, you have to recognise what kind of project you're working on. Not all efforts have equal value to the customer or to the business. So there's a thing that it is sort of a VE diagram. You're looking at what does the customer need, but also what allows you to sell the product. And when those layer up, those are very important to get right and to be absolutely amazing. There may be other parts of your portfolio where you're just not resourced as sufficiently to do the best possible outcome and you set your team up for failure if everyone's trying to do that and you don't have that. So one of the conversations, the analogy I use is don't go for a home run, hit a single and occasionally we can hit a double, but you actually over time, if you hit a lot of singles, you score a lot of runs.
- And so enterprise is a long game and you can evolve a product over time, mature it, make it better, et cetera. And so it's not about making compromise, it's about taking a longer view of the path to excellence and saying, okay, what are the things that we can do now within the constraints that we have? Where do we add value? And yes, there are some parts that maybe we're not proud of as much as we'd like to be, but we'll get to them soon enough. I think that the challenge with early career designers in organisations is they get very frustrated by that because they want to focus on everything needs to be super awesome, and they don't understand that the business has other constraints. They've got to go to market, they've got to be able to sell, they've got to disposition their resources and the decisions that leadership have to make on a regular basis are hard ones. They don't always make the right decision, oftentimes they don't. But we have to be in service of those decisions and the value that we create should demonstrate itself and the quality of the product outcomes that we build.
- I'm always trying to drive us to drive the best possible experiences. I mean, at Cisco, we won two fast company awards in the time I was there, so it's not like we are not doing awesome work, but there is that recognition of where to place your attention.
- Brendan Jarvis:
- And also I suppose that you can't always be doing awesome work that sometimes like you say, you've got to place your attention appropriately for whatever the conditions are. You're right though to suggest that designers have this, generally speaking, have this pull towards disruptive innovation over incremental innovation in the longer term view, those step after step, let's just edge our way towards a better product experience and we'll get there. And perhaps that's an age thing. Perhaps it's a patience or a disposition thing. I'm not really sure. I've heard you speak before about this, I suppose, culture of innovation within enterprise that's needed to enable slightly larger leaps or steps to be taken. And previously, and this is going back maybe a few years now, so maybe around circa 20 17, 20 18, now, you had included in your toolkit for enabling that things like multidisciplinary strategy teams and customer councils. Do you still feel the same way in terms of the tools that you would use to build and foster a company's culture of innovation and to change that behaviour and get them, I suppose a little bit more comfortable with taking slightly bigger steps?
- Greg Petroff:
- I do. I think one of the things, if anything, it's sort of accelerated. I think the tools we have have changed radically for everybody. And in those change of tools, the definition of our roles are also could be up for a question and probably should be, right? So a mature organisation that is authentically reflective and has a growth mindset should be challenging its own norms about who does what. And many organisations specifically a lot in enterprise software product is dictating what gets built. And then design is sort of order takers to that work. And the reality is with advent of Figma, we can work so fast that we're often ahead of the product team in terms of what the product should be. And so that dynamic is shifting some of the gravity between those two communities. And the argument I make is that products should be really focused on the buyer and the way work is completed now, but not the way work is completed in the future.
- Meaning they should understand how customers solve the problem really well and the value of that problem. So they should be the experts on the outcomes should be. Then how we deliver the outcomes in the future really should be left to the design team. The design team can iterate very quickly, can do rapid testing. Now it's very easy for us to build high fidelity mockups and at much lower costs than we could before. We can go in front of customers and get feedback. If you have really A-C-I-C-D model, you can put things into production and test it and get feedback on it from a set of people in your community so you can start to use that as a different way to work. And then even engineering is changing, right? You've got copilots or basically helping write code and you have more teams migrating to a more platform-based approach to building versus bespoke software development.
- Mostly because people are getting burned by the costs of the platforms they've built over time. If you constantly build just enough to satisfy the requirements, the tech debt you acquire becomes the boat anchor for innovation for the product. And so if we ideally can move to a more platform-based approach where we're building with the material components of code and design together, we can move more quickly and we can deprecate things and put new things in. It changes the way that we operate and the way they work. So that's one step. I think the culture needs to be ready for it. Incentives have to be aligned around that, and there's some challenges around that. The three disciplines of the three-legged stool have different incentives. Engineering tracks, lines of code built and quality metrics. Career advancement in product is often connected to the size of your remit and the number of features you support.
- So it's very difficult for product people to deprecate parts of their portfolio because it might make what they're managing smaller and then they can't get to that next level that they're looking for from a career perspective. Yet we would all benefit by actually turning something off that very few users or customers are using, learning how to say no and learning how to turn things off. And then design care is really about the outcome. We want it to be awesome and we may actually not see the business. Is the business structured well? Is it financially viable? We may not care about that. And so if we can find a way for the communities to talk about why they're there and what they value and just in the human terms what's important to them from a career advancement perspective, you can start to align the culture towards things that make more sense.
- And I'm a big fan of project-based teams versus product-based teams. Tell me about that, Greg, why project based? So the idea behind that is let's say you establish a new feature and you get it to a certain point and it's successful, the momentum will be to continue iterating on it or adding more capabilities to it moving forward. But that may not be the most valuable next outcome for the customer. It may be really good and making it better is just slightly better than where it is right now. Whereas if you took that same engineering design and product capacity in some other part of the portfolio of needs that the customer has, they'll find more value on it. And so you have to continuously be looking at what are the outcomes that matter and then the longevity of those outcomes, and then your capacity to execute against those outcomes and the ability to flex your resources towards the highest priority outcomes and sort of have above the line below the line mindset where you say, okay, these are the things that we need to do in the next six months and this is our capacity to execute.
- Let's staff those teams. And if we're successful at that, that's great. And only when we've done that can we entertain taking things and pulling it above the line. The one thing I think is a challenge in a lot of organisations is people still try to advance the ideas that don't make an above the line. They're sort of like, Hey, I'll be an overachiever and I'll give you A plus B. And what they don't realise is the plus B adds an operational tax to the organisation that deprecates your ability to deliver the thing that you're committed to. And so it's really also important for a culture to learn how to say no and to actually enforce that now in the organisation. And if you find part of that organisation doing something that's on the no list, having consequences connected to it, basically just saying no, we've made a decision from a leadership perspective not to do something.
- And that kind of clarity I think helps teams move faster. And then you have to build an incentive structure that makes people feel comfortable that, hey, you finished this piece of work, now you're going to be asked to move to something different. Is your career still solid? Are your goals aligned with that? Is it something that I can grow from? So it's a harder tool to manage, but if you can figure out how to do it, you build better product, customers get better outcomes. And I think actually the people at work are happier because they're delivering something that they know is good.
- Brendan Jarvis:
- You've talked a lot about product over the last 15 or so minutes, and I understand that most often you've found yourself reporting to a chief product officer at least in recent years, and that you've worked hard to make that relationship work. I mean, obviously people want to make the relationship work with their boss, but in particular, and in your own words, you've described it as making it airtight. What have you learned about the role of the CPO and the relationship with design as a result of that proximity and that approach you've taken?
- Greg Petroff:
- Yeah, I think it's a great question. I think I'm sort of questioning my own ability to say air tightness. And there's a couple of reasons behind it because the men are from Mars and women are from Venus conversation, right? The worldviews are so different and the value structures can be so different that you may feel you're aligned, but the semantics, what you use words to describe a problem and what you think is a yes is a no for the other person, but it's not explicitly said. So I think one of the things I think is really important is it's not just aligning to strategy, but it's questioning assumptions often and how are we doing? Are we working on the right things? What are you worried about? Can our team help in strategic conversations or strategy decisions? Do you want us to vet something along the way?
- And these are things that oftentimes are not planned for and you don't have the capacity to do, but you have to find a way to have the capacity to do them so that you can stay close. And I think the leadership role, the chief design role is managing sideways and up. You talked about Peter Miltz. Peter has a framework that I like that talks about depending on where you are in your career, which direction as a design leader are you operating at? And I do operate down sometimes, but I count on having a great staff that own those kinds of activities. And I think the job of the CDO is to break bread with their product colleagues in the organisation and their engineering colleagues in the organisation and to understand the pressures that they're under and the commitments that they're making and be an advocate for design.
- Being in those conversations and not getting the team caught in an unrealistic expectation that you weren't in that was made to leadership and you weren't in the room to be able to deflect or augment or question and therefore your team has to carry a burden of fulfilling something because you weren't there. So it is not an easy thing to do. I've had good relationships with the CCPs I've worked with. I think I've also think I've been challenging for the CPOs I've worked for because I don't always say yes to what they're asking me to do or that I have questions about why we're doing certain things that they may not have completely framed yet, but they don't want someone to ask that question. But for me, I think design teams work best when they have clarity. And so the job of the CDO is to drive as much clarity into their team as possible and that way people can actually get great work done. You
- Brendan Jarvis:
- Talked about staying close, and you also mentioned Peter, and I want to pick up on something that when you were talking with Peter and Jesse, you mentioned on their podcast conversation, which was that you liken the role of the design executive to playing chess. And I'm going to quote you here, it's a little long, but bear with me. You said 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 made that mistake where I'm like, I'm responsible for the outcome. They hired me. I don't have to tell 'em everything we are doing as long as I deliver. So what was the impact of not ensuring that people understood, and I'm assuming you were talking about the CPO relationship, but perhaps more broadly here, that they weren't aware of what the moves that you were making on the chessboard.
- Greg Petroff:
- Yeah. It goes back to what you value, how you motivate teams is very different in the three different disciplines. The personality traits of individuals are in product engineering and design are different. It's a little bit of a cliche or stereotype, but there's some truth to it. And so what do I mean by that? Product folk are usually very motivated to move up and to get to that CPO role that is a career path projection like control product. It drives a lot of type A personality behaviour and people who are gregarious, they love talking to customers, they help to move fast, they don't like to leave rooms without decisions being made, that kind of thing. There's nothing wrong with that. By the way, engineering teams, they're more black and white and less nuanced about things they want. Is this or is it that? Are we going to do it this way or that way?
- Ambiguity? No, that is not good. Let's move forward. Design teams to be motivated, they need to feel great about the place that they work at. They need to feel connected to some purpose. They need to feel like they are doing something that has societal value ideally, and you'll get better outcomes from 'em. They'll be more involved and more invested. When they don't have that, then you don't get their best thinking and it just becomes kind of a job and they start to tune out and they get burnt out along the way and they don't have the ability to do that extra effort when you need to do that kind of work. And so you need to explain why there are certain kinds of activities that you might do with the design community that you may not have to do with other parts of the organisation that may not be understandable to your cross-functional peers.
- Why are you spending so much time on team building exercises or why is creating boundaries around work and time of work and meeting schedules, et cetera, matter so much to design? And you sort of have to help people recognise that. So part of that is reporting that. Part of that is actually saying why it's in your incentive value as a lead of product to have your design folks do these kinds of activities and what it generates when you do it. And if you don't communicate that, then people will look at that and they'll just not understand why you're spending effort and they won't equate that kind of work with the quality that comes out. They'll just assume that quality always comes out and that kind of effort is sort of superfluous or extra, Hey, if you didn't do that, you'd have more capacity or something like that.
- And so I think I've found in my career that I focus, the way I know how to manage great teams is to help people grow their careers, to get them focused on what the outcomes are for the company, to see the vision, to see their role in the vision, to provide some clarity, to give 'em some autonomy around how they can contribute to it and then to make them feel safe. And then when you do that, boom, the design team flourishes and really starts to crank out great work. And the people that you have, the quality of your people goes up without actually bringing new people in. They acquire new skills, they feel like they're part of something. It's not that product and engineering don't care. I think engineering cares about that too. Engineering spends a lot of time on training in their own way, so you can talk to engineering leadership and they'll kind of understand what you're doing.
- Product doesn't really understand it because product as a profession is relatively new too. And everybody in, a lot of people in product come from different backgrounds and they all kind of roll their own even in large organisations. And so they may not value those kinds of activities. So that's one example. I think the other example is when you've found something of value and done something, well, you need to promote it so that you get to take that victory lap inside the organisation. It should be shared because almost always it's a collaboration between your product and engineering colleagues, but it's not always understood. And so those are just important things around helping your cross-functional peers recognise what it requires to create a high functioning design organisation.
- Brendan Jarvis:
- I've heard you talk previously about sharing that victory lab with product and engineering where appropriate, where the situation means that there's been that kind of collaboration. I've also heard you tell the story of being in a leadership meeting where you were talking about, I believe the role of the design org and what the design org had done. And you had a colleague actually say to you to stop in that meeting, you were only talking about design. It seems like there's a precarious balance or line here to be walked between just how much you advocate for the org that you're leading with your peers and how much you try and bring to bear that broader business perspective.
- Greg Petroff:
- Yeah, the retort for that conversation was sort of like the moment you talk more about design, I'll talk more about business, but that's a little passive aggressive. So we're new in the conversation. I think I found it to be less true of recent than it was in the five, 10 years ago. Five, 10 years ago. If you were in that room, it was the first time someone with design was in that room and you were fighting for relevancy and also trying to create the space for the work to be done the right way. I think there's less issues with that. Now, there's also some other things that go on in enterprise software. So one of the things as designers in enterprise, you have to recognise that the buyer and the user may be very different people and the product leader cares about the user, but they mostly care about the buyer.
- And so design teams need to think about does the experience, is there some part of the experience that helps in the selling of the product? And it's not like doing gratuitous design work, but is there some part of the experience that demos Well, when a salesperson is showcasing a product, and you'll hear that from product leaders like, Hey, our competitor has this really impressive data visualisation. It's blowing everyone's socks off the table. And you can go, yeah, we know people are using it and they find it unusable, but the buyers seem to like it looks super cool. You have to create space for that. You have to be able to say, okay, there's some part of the product that we have to build that is appealing to the person who's making the purchase decision. And then there's some part of the product that is connected to the outcomes.
- Now that is shifting, and this is actually really interesting, and I think a lot of product people don't understand this very well yet, especially in large enterprise, or lemme put it this way, digital native companies, SA native companies understand this deeply. Companies which are trying to become SaaS related companies that have secure annual recurring revenue, the initial sale isn't the most important thing. The most important thing is the event that happens when they renew the renewal event. And what you want to do is you want to be in a situation where they renew without you doing anything. They just love the product so much that they say yes. And that means that users have to be achieving their outcomes, has to have product market fit in a way. I've been advocating for this idea around reverse journey mapping and saying, okay, we're at the renewal event.
- Let's work backwards. What are all the things that went right along the way so that we understand that the customers are getting value? And how do we know? And what that asks you to do is a couple of things. Onboarding has to be a great experience, and then you have to have great instrumentation in your product. So if a customer is using all of the capabilities, and if they're not, then you should have remediation procedures where you have consultants or staff or the account executive call on that customer and say, how can we help you use this product more? Is this product have the right fit for you? And that also should give you the data to know which of your customers are likely not to renew. And you probably shouldn't even spend time worrying about it because it's just not the right product for them.
- And a lot of companies just don't understand that. And I think the more that we can be data-driven about that kind of experience, I think that distance between the buyer and the user starts to collapse, but you still have to do some of that work that attracts eyeballs and attention, especially in crowded market spaces and in security where I was is coming from lots of vendors, a lot of really cool UI in that space. And so great experiences serve table stakes in that space. And coming up with net new innovation is hard because everybody's doing really well.
- Brendan Jarvis:
- Greg, that thinking sounded dangerously like a CPO. Have you been considering a jump over the fence?
- Greg Petroff:
- People told me I would be a good CPO at some point, but yeah, I mean obviously I find a lot of design leaders when they partner with their product partners end up doing part of their product partners job for them because they do it to drive clarity with their teams. Probably shouldn't be that way, but I think we're in that space. I'm definitely an advocate for design leaders to become product leaders.
- Brendan Jarvis:
- I want to just take a slightly different direction now and reflecting on your career, right at the executive level as a design leader, you've worked at some of the world's most recognisable companies, the ones that I mentioned in your introduction, and that's been I think for roughly 13 years or so. So that's not an accident, that's a track record of success. What do you tell people about design when you are interviewing?
- Greg Petroff:
- I think that when I interviewed for Cisco, that was a really interesting interview process because I was late, they were late, and I had two offers already from other companies that were about to expire, and they kind of found me and I said, you're too late. And they said, no, no, no, we'll figure this out. And so I did no due diligence on them. I was on vacation when this happened and they said, we'll set up meetings, which they did amazingly enough in 24 hours, I had meetings with all the people that I should meet with. And so I was very unplugged in that those conversations and what I talked about in that space is good design is table stakes and a must have, but for it to be successful, there's a recipe or there's some preconditions for its success. Your ratios of talent have to be in good shape.
- You have to be able to, you can't have designers working with four different product leaders. Product leaders may think everything's great, but the designer's only in meetings and not actually doing anything. And then I kind of talked about some of the challenges that can happen in organisations that value short-term, thinking over long-term thinking, and then advocated for growth mindset, et cetera. It was really funny because in the conversation, we love that you should come here, be that person talk that way. We need that kind of transformational change here. And I thought, I really didn't talk that much about design work except to say that the process of design is how you make products that connect with people. And if you want products to be sticky and meaningful for people that they love, if you want customer love, you do that by delivering something that people feel seen by the people who made the product. And the people who do that really well are the designers. We're not the only people in that space, but that's the special set of things that we bring to the table because we use research and insights and a deep understanding who we're serving, and then we choose intentionally. We make intentional decisions about how people can get work done on their behalf. And if you get it right, then people love you for it, and that's the value that design can bring to the table.
- Brendan Jarvis:
- You mentioned the importance. You sound like you've been quite frank when you were talking with Cisco early on there, you kind of unplugged and it just sort of came out. I'm sure there's probably some things you said that you were pretty happy that you said them because it framed, it seems like it would've framed the relationship to start on a clear foot on the right foot. You mentioned capacity though, and I've got a quote here I just want to quote you about capacity. You said previously, at this point in my career, I probably won't shut up about getting ratios and getting teams to work the right way because it creates the conditions for success. It really does. So this whole ratio thing is obviously something you feel is really important for design to be successful. What would you say, and I think you mentioned, for example, you've got designer reporting into four different product managers, which is probably one example, but what are maybe other examples of the ways in which we could be working or people, designers may be working that aren't the right way of working together, that don't have the right ratios for success to be present?
- Greg Petroff:
- And first of all, I'm cognizant of the fact that not every product or culture or company needs the same ratios, and some of it depends on where the value of the product is created. There are some products where it's deep technical capability that is the value that it creates, and there needs to be a lot of people working on that. And I learned that in Cisco, the security business, there are parts of the portfolio that most of the team is working on, algorithms and threat detection, ai, et cetera, and there's product and engineering working together, but design doesn't really need to be there that much because it is really deep under the covers of things. But on the experience side, when you're talking about delivering experience, I think that the dynamic I look for and the one I try to communicate is the product to design ratio.
- And it's a physics problem, and I was sort of joking about the four to one thing in a moment earlier, but if you're a designer who's working with, let's just say two product leaders, but the two product are working on different things, the product leader feels that they have a designer working for them and may schedule multiple meetings during the week for them to meet and coordinate work, et cetera. But then the other product leader does the same thing with the same person. And then if you look at the calendar of the designer, all of a sudden half of their time is in meetings and only half their time is actually doing heads down work. And then if you look at the way their calendars are scheduled, they have maybe hour increments of heads, downtime interrupted by half hour meetings along the way. And so you're not using your design resources effectively or efficiently in that environment.
- The second thing that I think it happens is that when that ratio is off, product leaders will compete for resourcing with each other. And what I mean by that is that they're trying to push an agenda, a set of ideas forward, and their peers trying to do the same thing and they move forward in their career by their product being successful, they're going to look at the pool that's supporting them and try to protect or pull or steal and advocate for work. And that creates friction in the organisation. And you have to fend for that. I've heard people say, well, that's just the way things work, and you just kind of manage through it. I'm like, well, okay, let's consider a different world. Let's say we have two designers for each product leader. So the ratio is flipped. You have someone who's envisioning a product category is going after a market, is looking for product market fit, has two product designers, full-time focused on the work.
- Those people only meet when they need to. And the rest of the time those designers are fully busy designing things which are helping fulfil the vision of that product leader. And that product leader is actually more successful because they're getting more done in the capacity of their work. And oftentimes when a product leader becomes overwhelmed in their mind, they're like, I'll just hire a junior PM to make me more successful. And what they really should do is look at their design partners and say, am I adequately staffed on the design side to help execute on some of these ideas? And this goes back to the make the think piece, which is if you don't have enough design execution, then product has to define what it is, and they spend too much time doing that. And then by the time you make it, you discern that the idea wasn't completely fully fledged, and there's some incongruity in it that is unresolvable.
- And so that ratio is a really important one. And I think the organisations that do that well move way faster. And then engineering resourcing, obviously you have to have the right, depending on the problem, you have to have the right number of engineers. But to me, I think that is the number one success factor. And one-to-One is, okay, one product to two designer is awesome. I think if you go more than that, it must be something really special on the UI front or consumer facing or something that's got a lot of design work to do to figure out. But the moment you drift in the other direction, the super valuable resource of a designer you have is actually being wasted and you're not using the company's resources effectively. So to me, I always try to describe it as a physics conversation. How many hours in the week are they actually in Figma and doing what you want them to be doing? And when you see the ratios are wrong, you recognise that they're not there that often.
- Brendan Jarvis:
- And you've got some thinking around design ops that's coming to mind here, and I'll paraphrase you here. And that's really that design ops should be primarily about resource allocation and providing visibility into what's actually available. And so understanding how full people's calendars are so that you can actually have a conversation that's grounded in reason rather than just people getting stressed out and wishing that things were different. How much of that is actually about the design org, wrapping their heads around spreadsheets and just getting really comfortable with that analytical side of what makes the design boat go faster.
- Greg Petroff:
- Well, you have to have the right people. I mean, the average designer probably doesn't want to do that work, but someone who loves design and has kind of product management skills loves that work at Cisco, right before he left, we just finished putting the entire organisation in Airtable, and we use that as a tool. You can use other tools, but we use that as a tool and we could tell you the capacity of every designer, what they're working on, what they're currently working on and what their plan to be working on. And we rolled reports up on a regular basis to product and engineering peers. And the reason behind that was we would get, there's always situational asks from leadership like, Hey, we need you to do this thing. And I'm like, awesome. That's fantastic. What would you like us to not do? Right? Because you can't ask people to do more than they have the ability to do.
- You can't at times if you're willing to kind of flex, but you can't do it consistently. But if you don't have that information, you have no way to say no with a straight face. You don't have the way to share that point of view with your team. I did this thing last summer where I bet the GM for the security business, a case of beer that we wouldn't adequately staff all of the work that they wanted to do for the year. And he was like, no, we need to. And I'm like, I know, but culturally, we just have this problem of being able to do it, and we should have above the line and below the line, it shouldn't be about trade-offs. We should just look at our capacity and say, these are the things we're ready to do and we're adequately. And I even built a little flow chart that said, is this an idea that's important?
- Yes. Is it staffed appropriate? Yes, go. And then is this idea important? Is it validated? No, do more validation. It was sort of like this sort of path to help people evaluate it. My peers didn't really take to that because of course that meant they had to rationalise some of the decisions that they wanted to make that sometimes aren't the path that everybody wants to take in the path they want to go. But it was a useful meme in the organisation, and he used it publicly. We had it all hands because Mr. Petrov here has, bet me a case of beer that we can't figure this out and I like beer, so I want to get my case of beer. And so that actually helped us have conversations in the organisation that were healthy, are we staffed appropriately? And one of the things we did do is we figured out a way. We had to do a little bit of staff augmentation and reshifting and rebalancing of resources, but we found a way to make sure that we were adequately staffed for the work that was planned for the fiscal year.
- Brendan Jarvis:
- Listening to some of these stories in particular, that one that you shared, it seems that there's a bunch of peculiar decisions that are made around or informed by the incentives that these cross-functional organisations working to. It sounds pretty dysfunctional at times. You seem to be someone who tries to reach across the aisle, so to speak, or tries to build bridges between silos, tries to shake people out of their narrow focus and to actually see the broader outcomes that everyone should be striving for. I don't know. How do you maintain a positive attitude from role to role, for example, or from project to project or feature to feature when it seems like it can be quite tricky at times?
- Greg Petroff:
- That is a really great question, and it's probably one where occasionally it gets me in trouble, right? Well, first of all, organisations are made up of humans and humans. We are all incented differently. We're all built differently, and we all have something going on. And what I mean by that is if you really dug to the person, you'd recognise that some of the ways they make decisions are based on either past trauma or some part of their childhood or something, right? And so the notion of organisational dysfunctionality and functionality is there's always going to be that even in the best run organisation because human beings are there and we come with faults, and that's what makes us the people that we are. I choose to see the glass half full, and I choose to see people as being intrinsically motivated to do the right thing.
- Occasionally you run into people who don't, but most organisations, if they're reasonably healthy, will ferret those people out. So I don't know. I guess I've come to the point of you have to act on it. It just comes with the territory is part of, and you take wins along the way and you show how you can make culture better. And I'll give you a perfect example of this. We have a pretty young team at Cisco and their relationship with their cross-functional peers where usually one or two levels of hierarchy different. So you'd have a manager working with a VP or that would be three levels. There'd be a senior manager, senior director, VP level, and feeling the hierarchy and then therefore acquiescing in the conversation versus holding their own in the room and saying, no, this is my role and these are the things I think are important and doing the right work.
- And there's a way of holding your own that respects hierarchy and organisation, but also allows you to communicate more clearly why something's important so that a stakeholder can understand it and then go, oh, I understand you, and oh, that's a good idea, let's move forward with that. And you kind of get at that win. And that's really around developing narrative storytelling skills in the organisation. So one of the things we did very quickly is we built this programme we called Campfire, and it was all about storytelling. And we had every designer tell a story about what they're currently working on. So that was step one. What's the story of your work and why is it valuable for Cisco? And not everybody could describe that. So they're like, okay, so there's some work we need to do there around connecting what you do to the outcomes that matter so that you feel like you have some, not only ability to see the value that you're creating, but also in that autonomy maybe work better towards those outcomes.
- And then we also discerned some people were great at telling that story and were really well respected in the organisation, and other people were challenged with storytelling. And it wasn't that they weren't respected, they were just not able to make as much impact with their cross-functional peers. So that was an effort around helping us build narratives around our work. And we drove that and we became really successful and very popular in the organisation. And we invited product and engineering peers to that community because it was about how we can use story to align everybody towards the right sets of outcomes. And there are some tools that you can use as a designer to say, okay, who's it for? Why do they care? What outcomes is it going to allow them to get to? How are we going to monetize that? I may not understand that part, but I can ask someone to tell me how are we going to make money doing that? And then that can draw a theme and a line around for everybody to rally around.
- Brendan Jarvis:
- And so the designer themselves can actually start to understand what matters from the perspective of that vp. For example, if you're a manager and you're dealing with a vp, you can frame things in appropriate terms
- Greg Petroff:
- And you can bring your case to the table in a way where they may not say yes, but they understand what you bring to the table and they value it, right? There's a difference between you bring an idea to the table and they're indifferent or they ring a table and they deeply understand the contribution and they thank you for it. But then they explicitly say, yes, we are going to do this or no because, and then that's useful too, to hear the context that the product leader might have that the designer didn't have and that can help them become more knowledgeable about how the work that they do connects to the business as a whole.
- Brendan Jarvis:
- Yeah, yeah. You spoke earlier on about the glass half full metaphor and how you take that posture and that's one of the things that helps you to, I suppose, keep flying the flag and keep fighting the good fight, so to speak. And it made me think about, it's almost like you're saying there are those, this is a cliche I suppose now, but there are those things that are up to you, which are what you bring and how you can position things and frame things and try and encourage people to think in certain ways. But there are also things that are not up to you, which is the decisions that they make and what they choose to do with what you've brought to them. And one of the things that I wanted to ask you about was back in April, 2022, and I think this sort of dovetails in nicely here, but you be the judge is you started a talk by quoting Paul Hawkins for Rethinking UX, and that's India's largest UX community.
- And what Paul said, and I'll quote Paul here, quote you quoting Paul. So that's kind of measure was when asked if I'm pessimistic or optimistic about the future, my answer is always the same. If you look at the science about what is happening on earth and aren't pessimistic, you don't understand data. But if you meet the people who are working to restore the earth and the lives of the poor and you aren't optimistic, you haven't got a pulse, and you then went on to liken what he was talking about there to the will that you see in the design community to make a meaningful difference, even if it's just in the day-to-day work. It doesn't have to be some grand thing, but just to make a meaningful difference. That was about a year ago that you said that. So what I'm wondering is from where you sit now today, how pessimistic or optimistic are you about the future of design?
- Greg Petroff:
- That's a great question. I definitely think that our community is under some stress right now. There's been a lot of downsizing in organisations. There's a lot of great talent out there looking for work, but I think that's temporary. I think the problems that we have as a society globally are asking for a designer's lens to solve. And I think we're also in this moment of transition between a framework for how the world works that no longer works and what the new framework will be that we're not sure what it is. And you can see that in politics. You can see that in geopolitics. You can see that in a couple of the wars that are going on in the world that are just terrible. And you can see it in the climate crisis, you can see it in a lot of different things in the background.
- There's just crazy science going on right now that is going to solve all kinds of things around energy and food production and healthcare. And as much as people in our society may feel disenfranchised, your actual quality of living in general is higher than it's ever been. And so part of the narrative that we as a world culture, and now I'm speaking about the us, I think the US has lost its future narrative. It used to be a very future focused culture like, hey, tomorrow is always going to be better and here's a set of things that we can do to get there. I think that's still possible and the reason that connects to my Possibilitarian Glass F full perspective, but I do think that there's a path where we need to be working with NGOs, with governments, with other venues that we may not have in the past to help them be more effective and more efficient and give them a leg up so that the solutions that they bring to the table are preferable to alternatives that may not be in the best interest of its longterm. And I think there are more and more people are thinking that way. I just feel like we're in a moment that we need to get through. So I think the pessimism is a little higher, but my optimism is still there.
- Brendan Jarvis:
- I was curious, I suppose behind the scenes there to understand just where you are personally sitting. You mentioned some of the challenges that are out there in the community, and obviously those challenges have arrived at your doorstep as well. This is a pretty interesting labour market to be in for everyone up and down the hierarchy. How have your recent experiences in the labour market changed your perspective on work?
- Greg Petroff:
- Well, you and I talked about this. I'm very privileged. I mean, I've worked for a long time. I'm financially stable, so I don't have some of the same particular issues that some of my peers or other people earlier in their career might have if they lost a job or in transition. I recently left Cisco and I'm looking for the next thing for me. I'm also looking at potentially doing different things, not leading the big design org, maybe doing something in an NGO space or somewhere else. I don't need the same kind of income in the future. I do want to work. I like working and financially I do need to work. I just don't need to work at the pace and scale. If the right big job comes, I'd be interested in it. I enjoy doing that. So I think that's one thing. I think for those of us work in enterprise and in tech, we're in this weird moment where the AI story is sort of driving decision making and the decision makers we're looking at that are all focused on the technology five years ago when they might've been, Hey, we have to have, our design game needs to be where we invest so that we can, it's a table stake activity now and we have to be as good or better than our competitors.
- Their focus right now isn't that, and that's okay, and we should be okay with that too and recognise that. And then there's a huge opportunity for us as a community to help shape that so that the kinds of experiences that come from that work are equitable and smart and don't alienate people and are positioned in a way where they will be disruptive. The technology is disruptive, but they are potentially co-creative as well in terms of opening other opportunities for new kinds of roles to emerge for people from an employment perspective. So yeah, it is an interesting moment and I think we should be looking at what we need to do differently as a community for sure.
- Brendan Jarvis:
- Most definitely. Paul Hawkins, who we spoke about a little earlier. Yeah, I understand you're a fan of his book on intelligence.
- Greg Petroff:
- Yeah.
- Brendan Jarvis:
- What was it in that book in particular about the way in which we make decisions that you learned?
- Greg Petroff:
- I'm a big Paul Hawkins fan. I know for those who don't know, he was one of the founders of Palm back in the day before, the first little handheld device that we used to have in the late nineties, early two thousands. But he took his fortune and used it to invest in brain research, and he got very fascinated by it. And he has this term, he calls it a prediction framework. He has a notion around intelligence, which kind of makes sense to me. IQ is in his world, is sort of the addressable memory that you have and the ability to use that memory to infer what happens next. It's amazingly similar to generative ai conceptually in terms of how we respond to a problem is based on our collective experience, and we're making a educated guess as to what to do next based on the collective things we've experienced and seen in our lives.
- And that prediction framework's really useful because it allows us to survive in the wild and it allows us to be successful at work. But it's only useful when the rules around you are stable with what you know, and when the rules change and you don't see it, then the framework that you have no longer is useful for sort of attacking that space that you're entering into. And so we've got to constantly be scanning to retrain ourselves along the way. And this is one of the reasons why CEOs have kind lifespans. They get to a very certain senior point in an organisation, and they're almost isolated from the customer and the universe, and they have a whole group of people around them that respond to them. And all the decisions are based on the framework that they bring to the table, which is for many of them created on very smart understanding of the world.
- But then if they stay in the role for too long and the world changes and they don't see it, the playbook that they bring to the table no longer works, and then the company falters because it misses a step. And that's when you need someone whose prediction framework has been reframed because they've been paying attention to changes that are going on. We're definitely in one of those moments for sure. I've seen a couple of them in my career. I mean, the rise of the internet, I'm old enough to be there early at the beginning of, I had the first website of any architect in the US, I believe ages and ages and ages ago. It was nothing to be proud of, but it was super, super early. And then watch that kind of go through a cycle. The mobile phone, the iPhone and the smartphone revolution changed dramatically a whole set of things.
- And we're now in this AI thing moment, which is going to reframe lots of things. And there's some overstepping going on too. I think some people are like, if you read the pundits, there are all these sort of dramatic predictions about how people are going to operate and work. And I'm not a hundred percent sure because human behaviour has to also meld with these things. And by the way, that's an opportunity for design because we can help shape how we connect to and partner with a digital partner, someone who's there with you along the way. How do you operate that in a way that's meaningful for people? So yeah, it's in an interesting moment.
- Brendan Jarvis:
- And thinking about, you've been at these top roles for at least the last decade or so, and thinking about what you were saying there about CEOs and just the gravity of the situation that we're currently in probably won't be evident. I don't feel for another five years or 10 years, just sort of how big this is or otherwise. How are you thinking or talking to yourself or what sorts of things are you doing to ensure that your way of making decisions, your reference if you like, for how the world's working is staying contemporary?
- Greg Petroff:
- That is a great question. I spent the last year deeply in the AI space working on Cisco security strategy around it and our design response to it. If you followed my career, I've been talking about intent-based experiences for quite a long time. And so I'm sort of excited about the moment right now because to do intent-based experiences, you need to have backend systems that are sort of ductile and can connect things. And to do ai well, you need to have backend systems that are ductile and can connect things. And so some of the work that organisations may not have paid attention to in the past, they sort of have to do now to be able to have accuracy in the models that they build and how they present information. So that's interesting. And then the next piece of it, I'm going to do some writing about this in the coming months.
- The prompt is a really interesting way to operate with the system, but not all of us know what question to ask, and so can we have systems that anticipate what we should be doing or give us a nudge or an offer along the way, and what would be the next best thing for us to do or for you to do based on the knowledge of you and where you are and what your role is and what job you have and what's going on in the context of your work. We have this opportunity to reimagine the kinds of experiences that could be much more experiential.
- Brendan Jarvis:
- That's a refreshing and glass half full perspective. Greg, this has been an energising and thought provoking discussion. Thank you for so generously sharing your stories and insights with me today.
- Greg Petroff:
- Oh, you're welcome, Brendan. I really enjoyed it. Thank you for having me.
- Brendan Jarvis:
- Oh, it was my pleasure. My pleasure, Greg. And if people want to connect with you, Greg, they want to follow along. They want to understand what you're up to and what you're contributing to the field. What's the best way for them to do that?
- Greg Petroff:
- I think I am most active in LinkedIn, so I have a LinkedIn profile and suit me a connection request, and I'd be happy to say hello.
- Brendan Jarvis:
- Sounds good. Thank you, Greg. And to everyone who's tuned in, it's been great having you here with us as well. Everything that we've covered will be in the show notes. It'll be in detailed chapters so you can hop around in particular on YouTube to the parts of the conversation that you want to hear. Again, you will also be able to find a link to where to find Greg on LinkedIn and any other links that are relevant.
- If you've enjoyed the show and you want to hear more great stories or great conversations like this with world-class leaders in UX research, product management and design, don't forget to leave a review. Those are really helpful. Subscribe, so the podcast turns up every two weeks and pass the show along to perhaps just one other person that might get value from these conversations at depth.
- If you want to reach out to me, you can also find me on LinkedIn, just search for Brendan Jarvis. There's also a link to my profile at the bottom of the show notes or head on over to my website, which is thespaceinbetween.co.nz. That's thespaceinbetween.co.nz. And until next time, keep being brave.