Product Team's Role in Developing Strategy and Delivering Specifics

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, Jehad Affoneh, Chief Design Officer for the restaurant point of sales system Toast, joins us to talk about driving an experience strategy across functions beyond design, dealing with tricky executive stakeholders, and how his background in engineering informs his work now as a design leader.

Peter: Hi Jehad, great to have you here. Thank you so much for joining us today. As you know, we’ve been talking to folks who have a title of Chief Design Officer, SVP of Design, SVP of UX trying to better understand just what this role and responsibilities entails. So that’s what we’ll be digging in with you today.

So thank you for joining us.

Jehad: Thanks for having me.

Peter: Awesome. So the first question we’ve been asking everybody, and we’ll ask you, might as well start on the top rope: How do you define the role of Chief Design Officer? That is your current title at Toast, I believe that was your title at Splunk. What, what does that mean? What are the responsibilities? How are you held accountable? What does your leadership want from you? All of that.

Defining the Chief Design Officer role

Jehad: So first of all, thanks for having me. I’m excited to chat with both of you. 

If you think of the role of any kind of executive team member, there are three main things you’re doing. 

One is your discipline’s contribution to the business. So if you’re the chief, you know, technology officer, you’re leading technology for the company. If you’re the chief people officer, you’re taking care of culture for the company. So your discipline’s contribution to the company. 

The other one is how you’re building your team and how you’re building that organization that drives that work, and bringing talent, hiring, growing talent, setting up the right culture for that team to, to bring the right culture into the company.

And then how are you uplevelling that discipline or the contribution of that discipline to the, to the company continuously? You can track that with metrics, you can track that qualitatively with, with feedback. You can track, you know, there are multiple ways to track that, but that’s, that’s a third piece.

So if you think about it that way, and obviously any executive team member is looking at strategy, helping define strategy for the company on, on vision, feedback from customers and so on. But that’s really just comes with the role. Like, if you’re at an exec role you’re helping drive strategy and execution for the company.

But if you think of these three areas, the role of a Chief Design Officer is to build, hire, and grow talented designers, user researchers, design ops folks, roles and disciplines required to operate a healthy organization. Build that culture where around, you know, skills and, high quality work and hold customers feedback and voice of customer as, as core to that story, they’re responsible for upleveling that conversation at the executive level and having conversations not just about customers in general, but about the way experiences help shape the product strategy.

And then provide language for the executive team to talk about design and user experience. So internally for a team, it’s easy for us to get stuck into, you know, the details of how user research operates and how design operates, and all the language and words that we can use in order to understand how our work is happening externally.

Externally, meaning within the rest of the company, outside of the design team. The role of a, whether it’s a CDO or VP of design, is to provide that language where the company can now talk about experience in an intelligent way that helps the company deliver more to it.

And this is, by the way, where the conversation, I don’t know if we’re gonna get there, but this is where like most conversation gets stuck on design metrics, but design metrics or experience metrics end up being a shortcut to, we don’t really understand what you do, so could you please, you know, translate it to the way the business operates.

But it’s really common language of the business. 

Peter: You mentioned operating at an executive level. To whom are you reporting? Are you reporting straight into the CEO, into someone else in the C-suite? What’s your relationship with that highest level of leadership in the organization?

Jehad: At Toast, we’re still, you know, founder led to some extent.

We, we have a CEO, but we have two key founders that lead R&D and Go-to-market. So I report on the product side of the R&D organization. And I’m part of the, what we call the RD exec team, which is the triad CTO, CDO, and the Head of Product. In addition to, you know Chief Security Officer, you know, and other disciplines that are related to R&D, but we operate as that key triad of CTO, CDO, and head of product or SVP product.

Peter: Last organizational question, how, what is your responsibility, if any, for like marketing or brand design? Obviously you’re working on product design and UX research. Are you also working on the marketing and brand design, or is that handled separately?

Jehad: No, we collaborated very closely with them, but that’s handled as part of the marketing org reporting to the Chief Marketing Officer.

Jesse: And are you the first Chief Design Officer they’ve had.

Jehad: Yeah, the first Chief Design Officer. They’ve had design leaders in the organization before at different levels.

Jesse: Right. What led to the leveling up of design to a C-level function for Toast?

Jehad: Yeah, that’s a good question. I obviously have a different part of that story having, having been on the other side, but I think a couple things. 

One, which usually is the case in organizations, there is usually a believer on the C-Suite that believes in, okay, we, we’ve gotten this organization as far as we can, and sometimes by the way that CDO, sometimes even CTO or other disciplines, but we’ve gotten this organization far enough with what we have.

It’s now a moment for us to uplevel that discipline and both bring someone, either, either promote someone internally or bring someone externally to make a clear point about where design now stands or where engineering and other discipline stands. And two, it’s, it’s oftentimes driven by, and I, I think that probably was the case of Toast, too, driven by the market change.

Like if you want that level of talent, there is now a, a specific expectations of, that level of talent on what the role will be in the organization. That’s somewhat taken for granted in other disciplines. Like having a CTO is kind of pretty typical thing to have.

That change is happening in design now, which is why like, it’s, it’s a novelty to have a CDO in some companies, but it’s, you know, you wouldn’t be surprised that a company is hiring a CTO, for example,

Peter: I’m curious what the difference though is between a Chief Design Officer and a VP of Design, who is the senior most design leader, whose boss is the head of product, who reports into the CEO it sounds like you’re in a very similar context as quote, VP of Design. Is Chief Design Officer simply kind of, like, good branding for otherwise a VP of Design or do you see it as actually, “No, they’re asking me to do something interestingly different than if I were called a VP of design?”

Jehad: Yeah, it’s actually interesting. It, it really depends on the company. So like, there are times where it’s branding and, and you hear about different roles, by the way, at the C level that have C-level, like chief I don’t know. I, I don’t wanna mention specific roles, but like, I was at a hospital the…

Peter: Chief Customer Officer, Chief Data Officer. Every, I mean, there’s chief everything now.

Jehad: Exactly, and obviously not everybody can report to the CEO and by the way, sometimes that’s not what you want either. Depending on the maturity of the org that you’re leading, and the, your place in the organization and so on. 

But I do think– so, so there are places where, hey, chief is a way to, to attract talent. It’s only one part of the equation. If we give that title, we’re able to bring someone in. But really it’s, it’s, it’s internally not a big change. 

Partnering with other “C”-level leaders

Jehad: And there are times when it’s actually not the case. It’s actually, part of the senior leadership team. Part of the executive team. Only people at that level have that, you know, being part of that team.

And that means you have, you have responsibilities to the company, owning the actual end-to-end experience and, and sometimes customer experience end-to-end. You are actually accountable to metrics, company-wide metrics, that’s the case at Toast. Accountable to company-wide metrics around experience, around product satisfaction, around customer satisfaction and so on.

And the other piece is we, we have been working a lot at Toast to drive, which is part of the hiring of this role, to drive the partnership in R&D around design, engineering, and product. So this role was not just about a single person, but about having triads from the top-down across the whole organization, starting with CTO, CDO, or you can think of it by the way, if you remove C titles, SVP of Engineering, SVP of design, and SVP of product, down to product teams that are operating at a designer, product person and, and an engineer.

I think that there’s a lot of debate in design about who reports to who and how reporting works. My opinion is that debate is sometimes misguided around, to do a hot take, to be controversial about, around more about ego of the person versus the actual value that the role can bring to the org.

I think the most, most important thing is, are you a partner to your product and engineering partners, or are you or are you a member of one of their teams? Like, are you a true partner to the engineering and product org, and obviously other orgs, and marketing and customer success and so on.

Two, do you have the autonomy to actually execute for your org things that might not be popular at the time, but you believe are true? Do you have the autonomy to execute alongside product and engineering versus for product and, and, and/or engineering? 

And three, are you accountable for true company-wide metrics or, or, or outcomes? Or is that accountability held by someone else? Like are you actually accountable to the company? Obviously everybody’s accountable to the company, but is part of the company’s key experiences or metrics part of your accountability, or are you, you know, delegated that accountability through someone else?

As long as you have those three, then where you report to, what your title is, obviously, you know you know, you, you get different access points, having these different areas, and there are extremes, like if you’re reporting 16 levels down, but you have these things, obviously autonomy is not there.

But in my mind, it’s less about that and more about do you have these three pieces that make you a true leader in the org.

Jesse: The first of those you mentioned is being a true partner with product and with engineering. It’s interesting because we hear so much about the need for better partnership there. And I think that in a lot of cases, the elevation of design to the C-level is intended to kind of enforce that partnership because a lot of people really, they don’t know what a good true partnership actually looks like here because nobody in the room has had that experience.

What do you think makes for a good true partnership between product, design, and engineering?

Jehad: Yeah, I think obviously every discipline brings something else to the room, but I think a true partnership means true ownership of the overall outcomes of that triad. So, you know, if, if you’re a, if you’re a partner in that team, you’re involved in and, and you have ownership over, how do we come up with the strategy?

So, like, what are we gonna go actually achieve next year at any level, by the way, even if you’re leading a team, what ways in which we’re gonna actually go and measure the success of that strategy, and then owning the outcomes of the execution of that strategy, even when it’s not necessarily the execution of your team.

So, like, if you’re having a conversation that says design has shipped, but engineering hasn’t, you’re not really a true partner. ‘Cause at the end of the day, yes, you might not be the head of engineering, but you have responsibility as a true partner to figuring out how do the three of us sit in the room and, and drive that level of accountability.

In my mind, shared outcomes and shared metrics is, is, is the north star way you materialize true partnership. ‘Cause if you’re responsible for, Hey, look, your metrics as the head of design or leader of the design team or the design discipline is, you know, as long as you ship these three metrics, you ship on time, you deliver a great experience, whatever that means, and you, your team is happy, you’re good if those are the metrics you’re tracking. 

Notice that none of these metrics talks about actually shipping the product. None of those metrics talk about product market fit. None of those metrics talk about revenue. None of those metrics talk about you’re staying in business.

So if, if you don’t really feel accountable for the other metrics or quote unquote other metrics that truly form triad accountability, then you’re not really a true partner. The, the opposite is true if, if, if your engineering and PM partners don’t feel accountability towards experience metrics, they’re, they’re not true partners.

True partnership is often formed, together. It’s a partnership. So like if you’re not coming up with the metrics together, if you’re not building the metrics together, if you’re not building the strategy together, if you’re not accountable together, if your rituals are separate, then you know, you might be a great collaborator, but that’s not necessarily the same as a great partner.

Jesse: Mm-hmm. That makes so much sense to me. And at the same time, I also hear from design leaders that they want unique metrics for design because they need to provide pro of of design’s unique contribution to the organization and that these blended or shared metrics actually make it easier for design’s contribution to be kind of swept under the rug.

Metrics and organizational maturity

Jehad: Yeah. And it’s very fair, and it depends on the kind of maturity of the org, but the way I think about it, and I’ve been there too, there are metrics that prove your worth and there are metrics that are actually valuable. And those two are not always the same.

Sometimes they are, but they’re not always the same. So as an example, if you’re early on in your design leadership role and the company is early on in their design maturity, maybe the metric that proves your worth is the opinion of engineering and product of you. And that’s not gonna stay the same. And I know that like to many designers or design leaders who are hearing this conversation, this might be like an allergic reaction to that statement. 

Peter: Let me interrupt ’cause I’m curious if that’s something you’ve had in prior jobs. You’ve worked in very engineering heavy companies, very tech driven companies. Was that something you needed to do to build that maturity muscle? Is that, is this born of your experience?

Jehad: Yeah, it is. And, and sometimes if you step aside and say, let’s say it’s not a mature design team and not a mature organization from the way design is viewed, if you step out and say, I gotta invent my own experience metrics, that I’m now gonna build the whole thing around them to measure them and I’m gonna report on them, but the organization’s not even ready to talk, to have that conversation, instead of proving your worth, you’re seen as like, you know, vanity conversations around things that we don’t care about. So like, you’re spending so much time building these metrics that we don’t even care about versus, I’m actually gonna work very closely with my engineering and PM partner.

Doesn’t matter if they see me as one yet, but I’m gonna work very closely with them, have ownership over what we’re shipping and not shipping, talk the language of that team, which by the way, could be, most teams have an experience language that is not up to our standards in design maybe, but most teams talk about experience in one way or another. They talk about it in adoption. They talk about it in customer qualitative feedback. They talk about it in NPSs.

So there is a bunch of different language in the business that exists. How do you capitalize on the existing language and say, I understand it. I’m accountable to it. I’m gonna help you get there. Could be a great starting point for someone in engineering and PM to say, I could have not gone in there if this, if, if it wasn’t for this person or if it wasn’t for this team. 

And then capitalizing on saying, now that we’ve had that credibility, let me tell you how we can do this better. Like, let me tell you this one other metric that if we track, we can provide such a, you know, a much better experience there. But taking the leap of faith from, you know, we don’t know what design does to let me tell you the exact metrics I’m gonna invent and then hold myself accountable to is sometimes too, too big of a gap to be effective. Again, depending on the org. That’s by the way, not the story at Toast, for example, but that was the story in previous roles earlier on.

Jesse: You’ve touched on organizational maturity a couple of times, and I wonder how you see that tracking with the age of the company. ‘Cause you’ve worked for some older, much more sort of established companies, as well as companies that were much, much earlier in their life cycles. And I’m curious how you see the organizational life cycle affecting the way the design is received and the way that design is done in these organizations.

Jehad: I think it plays a factor, but I think structure of the team you’re immediately having an impact on is likely far more important. So like, if you think about, you know, our roles in different organizations, there is probably a role you don’t understand. Like, we talk about design a lot because we’re designers and that’s our thing. But like, if, if I ask you what do you think a business analyst does and what is their value to the organization? And there…

Peter: They analyze business.

Jehad: It’s, I mean, it’s very clear. I understand, but uh, but you know, like there are so many roles in every organization and, and there are roles within roles, right?

Like in design, in, in the, in the big umbrella of design, there is product designer and user researcher and design ops and blah, blah, blah. And two things are true. Not everybody needs to understand these roles. Like it’s just impossible for, for like a CEO, for example, as the top of the umbrella, or the board, to understand every single role that makes this organization tick. 

And not every role deserves a full discipline and team and, you know, a large umbrella of a C-level role or, or something like that. It’s just, just not scalable as an organization. So if, if you think about it from that perspective, and then think about the next step of, okay, and then how do we make the decision for what gets a larger umbrella versus what doesn’t? There are two paths to that. 

There is the path of advocating for, I’m gonna start at the C-level and I’m gonna convince every single executive in the organization that design is the most important thing under the sun. Or there is the path of saying, I’m gonna actually make impact in a circle that I can actually influence.

Depending where you are in the org, that could be media team, that could be the VP team, that could be you know, the engineering team. You know, it depends where the org is and what’s the center of influence. And a lot of the time the center of influence is not where you think it is. 

Like if you’re an engineering-heavy organization, individual contributor senior engineers hold a lot of weight. So collaborating closely with architects ends up being such a huge impact on how design is seen across the org. One, because they’re thinking at a high level. They’re not bogged down by the daily details of what they need to ship every day. Two, they have systems thinking already. They apply it differently, but they’re actually very close to the way we, we operate in design. And three, they’re generally at the level of maturity where they have the company’s hat on, versus their individual team, even though they’re attached to a specific team, but they’re still thinking, how can I make this company better? And they have a ton of influence. They have influence on the executive leadership team.

They have influence, and this is just an example, not saying always start there, but if you’re an engineering-heavy organization collaborating with these senior engineers may be a far more effective path, than let’s build design metrics across the org that’s gonna convince the CEO that C-level role is needed.

And then how you deliver in collaborating with these architects on, you know, whatever their goals are, ends up being a huge ticket to, ” Wow. Like imagine if every architect in this organization had a, had a designer working with them. Now imagine if every engineer in this organization had a designer working with them. Now imagine if every team had a senior level person working with them. And then take it from there into, into, you know, into that story. 

But that, but you have to understand the organization and the way it operates. And that’s less about the age of the team or company and more about like what tools and, what does the environment give you.

Peter: I wanna kind of follow this thread, but specific to Toast, where you’ve been there, if LinkedIn is accurate, about seven months. So still pretty new.

Jehad: Six months. Yeah.

Peter: Six months. Yeah. And I’m curious what you found when you joined, how much was already set in place? I.e., your product peer and your engineering peer, had they been there, had they developed a relationship that you now had to find your way into, or was everyone new and you were all figuring it out together?

You know, as you’re talking about relationships and navigating organizations to understand how to situate yourself to be effective, what was that experience like for you six months ago as you assumed this, this role at Toast?

Jehad: Yeah. So it, it’s kind of mixed. As an example for my triad, like the immediate triad, the SVP product has been there for a few years– two, three years. But my partner in engineering, our CTO, joined I think a month after me, if I’m not mistaken. So we, we had like a chance to set up the triad together.

Two of three members of the key triad joined recently. The person, Steve, who leads R&D, is one of the co-founders. So he has been there since the early days of the first line of code. So there is a mix of that. 

Managing change

Jehad: But on that note, which kind of gives me just quick something to think about, there is no organization that’s not changing. I think one of the key things a design leader can do is figure out what change that’s happening and how you tie in the change you wanna drive into it. Like in my case, for example, a new CTO joined, the product leader was there, and he was, he’s, he’s an awesome partner to work with, working together and, okay, what, how do we wanna shape this relationship, was, was the change that you can tie a lot of stuff into. We want to build triads across the org. We want to drive change across the org. Here’s how it’s going to work. In other organizations, the change could be, people have been there for a very long time, but the team is going through, I don’t know, some change management process around… process. We want to change planning. Okay, let’s change planning together. Let me tell you how I can help change planning. Whatever it is, there is always something to tie into.

Jesse: And when you think of the change that you see yourself driving, as a design leader, the change that you want to weave into the change that’s already unfolding in the organization, what guides your choices?

Jehad: Yeah. That’s a good question. I think like looking six months back, like maybe three or four things that influence this. 

One is conversations with a team. So spending time and the listening tour, and I, I use team as a larger kind of umbrella. It’s not just the design team, the, the, the R&D organization. Spending time with the team to understand, first of all, how do we see the quality of what we’re shipping? Like, are we happy with the experience we’re shipping? And if not, why not? Obviously you develop your own opinion, but listening from the organization tells you a lot about how much bar raising you need to do.

Listening to, How is designing versus shipping? Many good experiences die in Figma graveyards where like, you know, “yeah, yeah, let me tell you this experience that we’ve designed six months ago that never shipped and never will ship because, you know, because,” and sometimes it’s not because of engineering. Sometimes it’s because it was designed in a way that cannot be shipped. Sometimes it’s engineering is not shipping and sometimes product doesn’t believe in it, but listening to these stories is really helpful. So that listening piece is one piece. 

The corporate strategy and company strategy is the other piece. Where do we actually want to go? And most companies have a three-year strategy at a minimum. So understanding that longer term strategy, not just next year. 

There’s the piece of digging deeper into the team dynamics for design in particular. Do we have the right talent? Do we have the right people? Do we have the right skill sets? Do we have the right organizational structures that enable that to happen?

And then the last piece is process. Do we have, you know, is this, hey, we actually have the tools in the toolbox and we’re just not using them effectively, or we are using them effectively and can use them better. Or is this like, actually, there is more change management to happen process-wise? Understanding those four were the key pieces to kind of setting up, but okay, here’s our experience strategy.

Developing an experience strategy

Peter: And when you set up an experience strategy, is this your own n-month plan? 12 month plan, 18 month plan? Like you mentioned the three year strategy. Are you doing kind of your own version, probably not with this distance to horizon line, that you start to work towards? How, how explicit does that become? How broadly shared? Is it, does everyone understand it?

Explain kind of how that strategy gets operationalized or manifest.

Jehad: So about three to four months in, so two, three months ago we kind of developed that experience strategy working with the design leadership team, our general managers of each one of the lines of businesses that we have, as well as the R&D executive team.

I own the experience strategy, so I’m the single threaded owner that’s accountable for that, for delivering on that strategy. And the strategy has two pieces to it. 

Here is how we think of experience as Toast, which impacts every single person’s job in R&D. So for example here’s how we’re gonna measure our experiences before we ship them. Here’s the level of quality we expect from every product that ships across the organization. Here is how we’re gonna work closely with support on our customer experience. So this is every single team, here’s the framework by which experience is gonna work at Toast. 

So that’s one piece. 

And the other piece, and here are very specific projects that I’m accountable for that will lead experience on product, customer, and end-to-end experience.

So on, on customer experience, here’s the work that specifically Design will own in working with our customer success team to improve our customer experience on product. Here are the specific two or three product leverages that we think our experience is a very important piece and we’re gonna own the metrics on.

And, you know, I’m accountable for both, I’m accountable for experience metrics across the org. But obviously you can’t be accountable for every product experience. Your, your teams are and your triads are. But personally that, that’s not the role. But accountable for that framework being implemented, measured, tracked, and part of our quarterly business reviews.

And then on the other side, here are specific projects that design will be the, someone from design will be the single threaded owner in, in driving. Obviously also tracked by metrics, but specific outcomes that we’re gonna drive next year. And that timeline is 2023.

Peter: So what you’re explaining feels quite mature, quite robust. And my sense is most of the design leaders that I know and work with wouldn’t know how to build a strategy like this, right? Because they’re not thinking about things always from that business lens or have that understanding.

And so I’m curious how, how much of this was something that you created, that you said, this is my playbook, this is, this is how I make sense of things. How much was asked of by the head of R&D and your peers? Like how did you know that this was the shape for this strategy to take?

Jehad: Yeah. That’s a good question. I think it’s a kind of combination. So we, we, the product team and, by product I’m using the bigger umbrella of product, you know design, engineering and product. The product team is accountable to deliver a strategy for, like, the way it works at Toast before we do planning. Like, here’s what we wanna go do next. 

And the expectation was, and that’s part of the work we did as a triad, the expectation was there are product strategy pieces that cross everybody’s work. Like, how are we gonna go ship Product X and product Y is, is a combination and triads in that product area need to go and tell us what they wanna do.

There are pieces though that are horizontal across the org or pieces where we wanna lean in more on either engineering or design in particular. So on engineering, think about scalability, reliability, engineering effectiveness, so on, so forth. On design, think specific rethinking of, of areas of the experience.

You can think of design system and other things, but there are areas where, hey, we’re gonna take a lead on reshaping this specific experience. 

Trying my best to say it without giving the specific example for 2023, not giving away strategy. But, that design saying we wanna do horizontally. That ends up being for, for engineering and design, what, what we’re sharing that are specifics, and then a point of view on how we’re gonna track across all of these different products, how we’re gonna track that we’re delivering good experiences in a reliable, scalable, secure, et cetera way. 

So it’s, it’s a combination. Like there was an expectation that the triad would deliver that product strategy with specific horizontal deliveries, but also that expectation was more of, we need an experience strategy. There wasn’t really an expectation and here’s how it’s gonna look like. And I think that’s the role of a CDO, like that’s, that’s a huge part of the role of the CDO. 

And by the way, that’s shared. Like it starts with, you know, we presented it to the executive team, the whole executive team. Tons of great feedback because the marketing team looks at it from their perspective. And if that’s good enough, the customer experience team looks at customer care. Service team looks at it from their perspective. The CEO looks at it from their perspective. We took that feedback, shared it with the rest of the organization. We shared it with the R&D team first, and then with all of Toast, as this is Toast’s experience strategy. This is not the design team experience strategy. 

And by the way, we call it experience strategy on purpose. This is not a design strategy. This is Toast’s experience strategy. This is how experience is gonna happen at Toast moving forward.

A big part of that strategy is, is the frameworks by which we know we’re gonna, we, we will, and we, we will ship a good experience and we know we’ve shipped a good experience. Calling it design strategy, in my mind, limits it to, here’s what the design team wants to do, or here’s the, you know, it’s like saying you know, here’s our… 

We use business analysts, but like, “here’s the business analysts’ strategy.” If, if I tell you that’s true and then I tell you, here’s a 30 minute of it, my reaction at least would be like, “good for them. Glad they have a strategy, but I don’t really need to know,” versus here’s our Toast analytics strategy. I’m like, oh, okay. I need to, I need to learn a little bit more about that because I, I need to understand how the metrics I’m driving are gonna fall into that.

So experience is the ownership of everyone. Design is the team or discipline. 

Jesse: So then you are carving out a space for design within these conversations. 

Jehad: Yeah. 

Jesse: Yeah. 

Jehad: Yeah. Design has specific ownership over key deliveries, both in terms of the frameworks, how we deliver, operationalize these frameworks. But also actually, you know, like we, we proposed and got funded for specific deliveries that will enhance our experience in, in 2023, that design owns. 

By the way, these happen across the org, so like the engineering… teams that will deliver these experiences report to engineering, but design actually owns the, the, the budget and, and, and metrics for actually having these deliver and actually impacting the experience. 

Handling company founders

Jesse: You were talking about engaging people across the org, and there’s one relationship within that that I’m curious about because in my experience, there is a particular kind of senior executive that needs special handling in this kind of process, and that is the company founder. And I should know because I’ve been one. So I’m curious about, as you’re doing all of this strategy work and all of this visioning work, how does that work when you’re engaging with the people who came up with the idea for the thing in the first place?

Jehad: Yeah, that’s, that’s a very good question. I, I think I mean, obviously it depends on the company and the founders, but at least at Toast we’re lucky that both founders are still very deeply involved and deeply care, but also recognize the scale at which the company operates now, that, that, that might not be the scale at which the company operated, you know, 10 years ago or, or, or even five years ago.

That said, I think founders hold a lot of keys to not just the product or strategy, they hold a lot of keys to culture. A lot of culture gets formed by the founders and, and what they care about. And most founders, at not just Toast, most founders, you know, I’ve worked with, have deep care for experience.

They might materialize those words differently, but they have, they deeply, deeply care. And they, partially, deeply care because they’ve been in the trenches selling the product, hearing from customers, getting the customer support call late at night to do something early on in their career. And that’s in, in, you know, imprinted in their, in their brains of how like, you know, the empathy is, is core to building a company.

You can’t really build a company without talking to customers. And that’s really powerful because it’s also, you know, it’s also important to translate that empathy into why you’re doing the things you’re doing. So I worked closely with our founders on the experience strategy, but one of the first things I shared as an example in the experience strategy, when we went through it, the first 10 minutes out of the hour or 10, 15 minutes were three specific customer stories.

Like we ran through, here’s a restaurant, the name of the restaurant, here’s the problem they’re facing. You know, Kate at the following restaurant, not to mention a restaurant name on here, but Kate at the following restaurant, here’s what happened when she used Product X, here’s how that product looks like.

It is a real story of what happened. And by the way, that story represents X percent of our customers. So like, this is not an anecdote but starting with these stories was really powerful in bringing back that, you know, this is about people. This is about restaurants, this is about the, the people we care about and you care about and we all deeply care about.

And these are statistically significant things for us to be, you know, paying attention to. But those stories, I think working with founders resonates a lot because again, it, it brings back the deep empathy they have for customers and the deep care they have for, for individual, you know, customers they’ve worked with, and by the way, some still Toast customers or many are still Toast customers that, you know, call the founders by name.

Bridging that empathy they have to, okay, and here’s how that translates into business and here’s how that business translates into action or what we’re gonna do about it becomes really important. Like that, telling that story in that perspective.

Peter: So you’re now hip deep, neck deep in restaurants and your prior jobs were much more technical. VMware, Splunk, your audience were developers and engineers, and now your audience are people like me who like to order from Cholita Linda down the block and the people who run those… 

Jehad: Hopefully using Toast by the way.

Peter: Oh, yeah, 

Jehad: yeah. yeah. 

Peter: Cholita Linda’s on Toast. That’s why I’m mentioning Cholita Linda… 

Jehad: yeah. 

Peter: and the people who run Cholita Linda, and I’m just gonna keep saying their name ’cause they’re, they provide my favorite both fish tacos and Cubano sandwich in the Bay Area, but I worked at Groupon and I know that the people who run restaurants are terrible business people who don’t have I.T. Functions, right. And so, so you’re, you’re dealing with a very different audience now in terms of level of savvy, the challenges they’re facing, the role the technology plays in their lives. And I’m wondering how you’ve had to change, if at all, how you approach your job as a Chief Design Officer serving these very different audiences than the very technical, very savvy ones that you might have worked with before.

Jehad: Yeah, I think so. I wouldn’t call them very terrible business people. I would call them very passionate, hospitality oriented people who need to figure out the business to continue to provide that service…

Peter: They might be naive business people, right? That’s not what they’re getting into it for, right? They didn’t get into it to run a business. They got into it to serve food. They recognize that in order to do so, they need a business that survives, but they don’t have MBAs. They don’t understand a lot of kind of core business stuff, that, that’s not their passion.

I was being a little facetious, so that aside, how, is it just transferable, like how you led at Splunk is how you lead it Toast? Or are you having to change how you show up in the things you’re doing to accommodate now a different audience that, that your products are serving?

B2B vs B2C; tech-savvy vs tech-naive 

Jehad: Yeah, a lot of the lessons you learn are transferable.

So, you know, for example starting from how you lead your team, how you hold yourself accountable, your team accountable, how do you build processes that enable teams to execute these things? And, and they don’t look the same at every company, but these things become lessons. You learn about what could work and what might not work.

But I think you know, moving to B2B2C and specifically around small businesses at Toast, there are a lot of, lot of lessons that I’ve learned over the last six months. And a lot of advantages that you can start applying previous lessons faster to. So for example, like, speaking to customers.

I’m now the guy at a restaurant, at dinner with my wife who like, you know, just gimme a few minutes and walk to the kitchen and talk to the people in the kitchen and talk to the GM of the restaurant.

And, you know and when a waiter comes in, the weirdo who says, “Do you like, do you like this device? What do you like about it? What could be improved?” for five minutes. So access to customers is a lot, is very different. When I worked at VMware, Splunk, you know, you’re working with an admin who’s at a company who you have to get access to who you, you need to plan an hour of their busy day to be able to talk to them.

So it’s, it’s a lot different. So getting a pulse is a lot easier than it was before. But also the audience you design for is very different. So how you think about the experience you’re delivering and the quality, the experience is very different. 

In enterprise, people are willing to go through walls to get to the value. Like, as long as you’re delivering value to some extent, and that value is entrenched into how people operate, you can get away with a lot. That’s not obviously true for, you know, someone who’s trying to operate their business effectively and they’re run a small business and they’re run on thin margins and they have to get things done quickly.

Like, that’s a very different set of expectations that you have to design for or, or guests or consumers that have a different, you know expectations of the consumer experience. But I think the muscle of how you deliver good experience, the intuition and muscle of how do you build a good team that can deliver these good experiences, the muscle of taking ownership of the customer experience that’s delivered, that muscle is very transferable, even if the toolbox is different.

So, you know, like I think about it, if, if you’re, if you’re, I don’t know, I’m not into gardening, but if you think of gardening, planting different trees takes different types of work, but a lot of what you learn from gardening in general applies. Like, you don’t just water all your plants the same way. You don’t all, you don’t plant all of them the same way. You don’t cut the leafs in the same, you know, different seasons require you to do different things, but if you get into gardening, you know, once you’re, once you’ve learned the basics, the, the foundations and you’ve gotten good at it, then learning how to plant a new tree is a lot easier than if it’s your first.

And, and every company, every role, even by the way, VMware versus Splunk, even though they’re both in enterprise, was, was a very different role. 

Jesse: Speaking of those roles and what you learned from them, you’re a little bit unusual among the heads of design that we’ve spoken to in that you really sort of came out of this world of design systems and firsthand experience in spinning them up and building them from scratch. And I wonder how you feel that experience has informed you as a design leader. 

Background in design systems

Jehad: Yeah. So I started my career in engineering and I know most, by the way, most design leaders I know started their career elsewhere, like in, in a different function. Doesn’t have to be engineering, but somewhere else. And I think by the way, if used correctly, that’s very powerful.

Like being bilingual in two things is, is like I, I joke that I’m bilingual in engineering and design. It’s a very powerful way of being able to empathize with someone else in the org but also push on them in certain ways. I think working on design systems, when we set up uh, Clarity, which is the design system for VMware, we started with, I think, at the time, two, three people, or three, four people including the engineering team.

And we, we grew Clarity from nothing to the design system for VMware across 35,000 people and, and, you know, 130, 140 products. That journey teaches you a lot about what’s possible with a small team. What’s possible, you know, having to actually, and you can learn the journey in different ways by the way, but selling teams on owning a piece of their work with very little influence over that work.

So you’re owning their UI layer, you’re owning their engineering implementation components. You’re, you know, without a top-down mandate. So that was, that was very interesting. But it also teaches you a lot on, on, on the, on the challenges of the details, like things that may seem very obvious, you now understand how difficult they may be, but also you understand how to balance them.

Just an example, every designer at a certain point in their career implements a date picker or is around a team that implements a date picker. And you know, date pickers are very simple. If you think about it, like just from a consumer experience, like you, you go pick your flight. It’s very simple. You, you choose the date, you choose the time you’re good to go. Like if you go to, I dunno, Kayak or, or Expedia or something, but they’re actually quite complicated. Making them accessible is very hard. Ensuring that they’re easy to use for the use case you’re looking for is very difficult. The balance of that though is, you know, you hear stories about teams that have been, that spent eight weeks building a date picker from scratch.

Even though their product includes like two date pickers in a workflow that like 1% of users visit. And it teaches you about value, like what matters to spend time on versus not. And you also hear about teams where, you know, if you’re a travel site, that’s actually very important piece of your business and every small improvement makes a huge difference.

But that systematic thinking about the layer of who uses it, how do you build it in ways that different use cases can use it? And how do you build it in a way where engineering teams can actually use it? Like engineering productivity matters a lot. It changes your perspective about how organizations operate.

‘Cause it exposes you to all these layers of different choices you have to make on, on such a simple thing as a, you know, quote unquote simple thing as a date picker.

Peter: What led to your shift from engineer to designer to design leader. Why? Why that path?

Jehad: I don’t know if you have time on, this podcast, but, but I, I really wanted to be a journalist by the way. Like that was my dream growing up and that’s what I really wanted to do.

Peter: Well, now you’re talking Jesse’s language.

Jehad: Yeah. So when I started kind of reporting on news stories, I’m originally from Palestine, so I started reporting on news stories there.

This is very, a long time ago. It was a time where you had to set up your own website. You had to set up your own thing and you have to, you know, we used to rent servers from Softlayer and you had a server every time few thousand users show up. That got me from like, oh, actually as much as I love writing, I also love writing code.

So I really enjoyed the process of building that, that experience. And then I really loved being able to analyze consumer behavior and build that experience around it. Like the ability to have data very, I don’t know if you remember the, like server data. You, you actually get what the servers logging exactly, like, you, you, you’re really analyzing what server data is giving you and you’re trying to understand why people are going to this, this thing versus this other thing.

That was real helpful. So as, as I started as an engineer, I always kind of stayed close to customers and that was really, was really powerful to me. And that translated into, okay, how can I better write better code to do it design systems? Before design systems I worked on a product, I was, you know, this ui slash ux role where you lead both teams.

And that was kind of a transition point to me. If actually, you know, there is a ton of impact to do when you systematically improve the experience, which was through design systems and then from there, okay, like I actually really enjoy the, the impacting experiences at scale role, which is how I think about my role. Still a journalist at heart.

Not a career though. 

Leading in difficult times

Peter: So you, you started at Toast six, seven months ago. The past six, seven months have been strange, to say the least, in any number of vectors. And I’m wondering what it’s meant for you, in terms of how you show up as a leader, given both the uncertainty that we’re seeing inside companies with the economic conditions and companies having layoffs and stock prices going mostly down, but also sideways. 

But then also with your customers, particularly the restaurants who are probably also feeling a lot of anxiety and concern and, and yeah, because of the uncertainty. And just like, what, how, how do you help? I mean, you’ve gotta figure out your own way of navigating through it, but then how do you help the people that you’re responsible to on both sides, both in-house and externally? How do you see your responsibility helping them all navigate through this?

Jehad: Yeah. we’re, we’re lucky in a couple ways to Toast. Restaurants are surprisingly resilient to, to, you know, I don’t want to say the word recession, so I’m trying to think about a different word. So I don’t jinx this call, but, you know, recession related things. And obviously that doesn’t remove the uncertainty and it doesn’t remove the, like, nobody could have predicted a pandemic two years ago.

So, you know, like, you never know what happens. But I think the one thing that stuck with me early on in my career, I, I worked with a leader who, who was a very transparent about sharing what they’re able to share. Like, there are obviously always things that you can’t share, like, you know, financial numbers or something.

But they were very transparent. And you always knew that you had all the information that you needed to have, good or bad. And it really resonated with me that there was never, like, if there was, if there was bad news, it’s not because they knew it and I didn’t. It’s because they didn’t, which is fine.

Like there’s always uncertainty in any job, any time, any place. And that really resonated with me and I try to do it at work where, for example, as part of our rituals, I have a weekly all hands we call T G I T, Thank God it’s Thursday. Where we, you know, we have half an hour where I do top of mind and update the team.

I do Friday thoughts every single week on Slack. What I publish here is what I’ve done in my week on Friday. Here are thoughts on things happening around the economy, the business, the, the team experience. This is, you know, where I share my thoughts, but also updates happening around the team. I have an anonymous feedback form in my email signature and Slack signature that says any question, all questions are okay.

And then I answer them on Slack publicly. But basically it’s the goal of here’s all the information I know. And that that still might not be enough, by the way. Doesn’t mean I know everything or I know what’s gonna happen next week, but I know as much I’m telling you as much as I, I know. And I think navigating it with the team, versus navigating it for the team makes a huge difference.

Like the team feeling involved in that, Hey, we’re navigating this together. Nobody can predict what’s gonna happen in three months, but I’m gonna tell you what I know and how we’re thinking about it makes a huge difference in folks feeling like, okay, I’m included in this journey. And being transparent about the good and the bad.

Like, I’m, I’m not a fan of the term, you know, being a, I don’t know what we can say or not say on the podcast, but like an s-h-i-t 

Peter: You can swear, 

Jehad: umbrella. Yeah.

Peter: if that’s what you’re wondering.

Jehad: You know, I’m not, I’m not a huge fan of being a shit umbrella. I’m a big fan of, helping shield the team from distractions. That’s totally fair.

But I think sometimes by being a shit umbrella, we hide the reality of how things operate. Which in my mind does two things: prevents a lot of good people who have good ideas from being part of that conversation; does not prepare leaders for the next step. 

Because all of a sudden, once that umbrella is removed in their new role, they realize like, holy crap. Wow, okay. Like, I gotta learn this from scratch. And the team feels like, oh, you know, I’m, I’m learning. ‘Cause once you leave the umbrella, there is always more information elsewhere. So I’m learning these things not from my leader, but I’m learning it from the rest of the organization or maybe the external market.

So I’m a fan of like, shielding your team, but also telling them what you’re shielding them from. If, if you are, and then being transparent just about what you know. 

But for customers, I think it’s very similar, like being transparent with customers, with, with what you can, but also thinking about, you know, like, we think a lot about how Toast is gonna help you be more profitable. How Toast is gonna help you increase your margin, how Toast is gonna help you, like, we impact real people’s lives, and real, real people’s businesses and we take it very seriously. 

And I think having that sense of urgency always to put, you know, their businesses first is, is really, really important. Internally, we talk about it at least, you know, one of the principles for design is customer, business, team, self in that order. Every decision you make, customer, business, team, self in that order. So we talk a lot about the impact to customers and every decision we make, whatever that decision is. 

Design executives are here to stay

Jesse: So you’ve worked in a bunch of different kinds of organizations and you’ve touched several times on the notion of maturity, and I wonder, as you have seen everything becoming more mature in recent years, I wonder where you see all of this going. 

Jehad: That’s a very fun, that’s like the meaning of life. So, I think you’ll start seeing more design leadership positions and more design leaders for two reasons. One, you know, every CDO position now, or every VP of design or SVP whatever, you know, your choice of design position, when that person leaves, if they’ve done a good job, it’s very hard for the organization to go backwards.

So you’ve just created a new role. And, if you think three years with movements, you’ve, you’ve now have a ton of organizations that might have had their first VP, their first CDO, their first SVP, but now they will have their second and third as that person goes, opens, hopefully a door elsewhere. So you’ll see more design leadership roles.

But I think you’ll see more design leadership roles than design leaders. So like the funnel will open up where companies start realizing, okay, like if I’m a competitor to, I don’t know this other company, I’m a competitor to Toast and Toast has a CDO, maybe we should start thinking about it and like, you know, what does that mean for us?

So even though it’s one role in some place, it starts opening it up. And growing design leaders to get there is gonna be a, a big deal. And, and then I think you’re gonna start seeing a lot more companies go back to basics of like, how do we make customers happy, and make, keep them engaged and have them, you know, stick on the whatever platform that you have.

You know, we had a, I dunno, was it a 10 year run of infinite VC money and infinite, you know, stock growth, where you could have experimented with a ton of stuff and enjoyed your, you know, having 70, 80 people on the problem that, you know, to its essence is, is, is 15 people, now you’re gonna get back to like, how do we do this effectively? How do we do this efficiently? How do we do this well? 

Where design can contribute a lot in how we de-risk experiences before they ship. How we dis- risk experiences after they ship. I think that’s gonna be a huge part of the conversation. And then overall I think, like, the flip side of that is if you look a little bit farther, you’re gonna have a lot more CTOs and heads of product and product directors who have a lot more experience in design.

So, you know, a lot of, a lot of us been in areas where design thinking or the way design works or whatever is our specialty. I don’t think that’s gonna be good enough anymore because the product leader you’re working with will probably now know the basics to get by and knows, knows them well, or worked with a designer or design leader that was really good and they’ve learned a ton from them.

You know, the bar will go higher, in my opinion, for what a designer needs to bring to the table, which is a good thing in my, but, but also means for designers just simply coming in and saying, I can help you figure out the workflow as an exam– oversimplifying, but as an example is, is not gonna be good enough.

And that would change the dynamics. 

Peter: Yeah, I hadn’t thought about it this way, but the, the late nineties to early two thousands were great for establishing whatever user experience became, before the bust happened, like we had gotten enough of a foothold that through the bust we were able to to emerge.

And perhaps these last two or three years, we’ve seen something similar now at the highest end of design leadership, where these companies, as they scaled and started hiring CDOs and SVPs of design over the last two or three years, ’cause they were, every company has a team of 60 to 80 designers.

That’s a little bit of an overstatement, but way more. And, that’s provided an opportunity of figuring out what this role is and maybe introduce this role to peers that hadn’t been exposed to it. That even if we’re retrenching, which I’m seeing across the board with my various relationships, there’s some, some flavor of retrenching happening, but there’s a general elevation of, of savvy and awareness because of what’s happened the last couple years.

Jehad: Yeah. A– as an example, this is, this is a slightly, like, exaggeration on purpose or going the extreme and purpose. But if you’re a design leader, like the moment of maturity for a design leader, in my mind at any level is when you have a conversation that says, I’d rather have an engineer more than I want one more designer.

‘Cause I care so much about what we ship, that I’d rather, like, I’ll take one designer away from my funding and give it to the engineering team. ‘Cause I feel like that’s where we can make impact. 

Or I wanna be involved in an interview for the UI engineer, you know, and I’m gonna care that about, I’m gonna care about that as if it’s my top hire this year. ‘Cause I know that the quality of the shipping is actually handled by the code, not just by the Figma.

These conversations where you’re starting to think about, and I think they will happen more, they will be forced to happen more often in, in a bad economy, because, you know, it used to be, oh, no, no, you don’t have to say, I’d rather have, an engineer, we’ll have both. We’ll have a designer and an engineer. 

That goes away now, like, we can have one. What do you wanna do? And if you’re part of that triad or part of that team, and you’re not thinking, I’d rather have an engineer because you know, I wanna ship more, I wanna like, I’ll figure out how to optimize my team, then, then if you’ve never had that conversation as a design leader and by leader I mean, you know, manager, IC leader then you should think about it.

Like, you should think about why not? Because then you’re, maybe, you’re still thinking downwards on your team versus across and above on, on how can I help this product mature and especially in an economy like this.

Jesse: This has been great. Thank you so much. 

Jehad: Thanks for having me. Love the conversation. 

Peter: Thank you. This has been awesome. How can people engage with you across the Internets?

Jehad: I’m on Twitter, kind of interesting to say that now, but , It’s @jaffoneh on Twitter. Or if you search for my name and on LinkedIn as well. Those are the two places I hang out the most.

Peter: I, I’m gonna give you a plug, I’m trying to remember the name of your website is, my name is Jehad

Jehad: Yep. mynameisjehad.com.

Peter: Okay, we’ll make sure that’s clear. I’m gonna plug that just because I’ve found it as a, a helpful resource. The writings you’ve had, not just around design leadership, but design organizations, design operations, in particular, I think you wrote about chief of staff once, that when I was doing some research, so we’ll point people to that as well. Thank you so much for your contribution today. This was great.

Jehad: Thank you so much for having me. 

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. 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.