• kylepeatt.com

Allen: Welcome to It Shipped That Way, where we talk to product leaders about the lessons they’ve learned building great products and teams. I’m Allen Pike. Joining us today is Kyle Peatt. Kyle’s been a design leader for many years, including a six-year stint at Shopify, where he worked his way from design lead to head of design. Welcome, Kyle.

Kyle: Thanks, Allen. Nice to be here.

Allen: I’m glad to have you on the show. You were one of my folks when I first started penciling out like, “Oh. I should do a show.” It was one of the first folks I was like, “I definitely need to have Kyle on at some point,” so I’m glad to have you here.

Kyle: Yeah, for sure. I think our very busy calendars have kept us from seeing each other.

Allen: Today I’d love to talk to you, there’s lots of things we could talk about, but I’d love to capture some of the things that you’ve learned leading design teams over the years. You’ve learned so much, and when we do have conversations, I am always picking up lots of fun stuff. First, I want to give you a chance to describe your background just a little bit. What’s the Kyle Peatt story so far?

Kyle: Maybe I’ll start where I started designing, which is I started designing, I think this is probably familiar to a lot of people around at least my age range, but I started designing for my Counterstrike clan. That was probably the very first thing that I really wanted to create design for.

Allen: Nice.

Kyle: And that was form tags, that sort of thing, but I got into it and I made a friend who was really into the kind of development side of web development. So that kind of put me on the design side of web development, and then we started doing what you do in high school, which is go find people that might want a website build, and build it for them. But from there, it was the early-2000s. It seemed like there wasn’t a lot of plausible money left in technology after the .com crashed.

Allen: Yeah. That was the end of technology.

Kyle: It didn’t seem like a viable career anymore. Yeah, exactly. So I was like, “Oh. You know what? Whatever, I’ll just go to university and do an arts degree or something like that. That’ll be fine.” I did one year of that before realizing that I didn’t like doing that, decided to go to design school. So I actually went to a technical school, because I couldn’t draw and couldn’t find a design school that would let me in without a life drawing portfolio essentially, so I went to a technical school focused on print design. That school was the Southern Alberta Institute of Technology in Calgary, and it was great because I learned a ton about press production, kind of what it takes to be a great production print designer. Because I had been a self-taught digital designer up until that point. it was really interesting to get into a completely different aspect of design.

Allen: Sure.

Kyle: From there, I worked as a marketing designer for a little while. Fast-forward, I went back to university, thought I’d become a lawyer. While I was doing that, I wanted jobs during the summer, and so I would just take design jobs because I had that skill, kind of paid for my school over the next year. And one of those summers, I got a job. The job was called product designer, although I don’t think it was very product designee, but I was doing mobile website builds pre-phone for a marketing company that was focused on SMS marketing, and this was my first kind of step into startup land. It was a small company. I was one of two designers. I was focused on the professional services side of things. The other designer was really focused on the product design. I was just building mobile websites mostly for restaurants, although I built the mobile website for, I think this will date when this was happening, appropriately, for Kung Fu Panda.

Allen: Ah.

Kyle: Yeah, Kung Fu Panda. It was actually funny, because it was like Kung Fu Panda but Kung Fu Panda on fruit.

Allen: Oh, okay.

Kyle: Yeah. It might have a code on it, and you could text that code. It would text you back a URL, and you could go to the Kung Fu Panda fruit website.

Allen: Nice.

Kyle: That got me really interested in web for mobile, essentially, so this was just before the iPhone came out in Canada. I think the iPhone actually came out in the US a year ahead of time. We only got the 3G in Canada. So we built, that company kind of leaned real into this mobile website building era where we’re building lots of webpages for blackberries and Motorola Razors. We had just finished building the mobile website for UFC, essentially, and it was me and another developer. Just two of us built the entire kind of mobile website set up for UFC, mostly focused on WAP devices, like Motorola Razors. But I just built this crazy passion for what it takes to condense and compress information at the time into something that was usable and functional on small screens.

Allen: It was kind of freeing, almost like you can only have this tiny device with these tiny screens, so you’ve got to make interesting decisions.

Kyle: Yeah. This UFC website was weird, because we were really focused. I was, I don’t think, a great designer at the time, but we were really focused on taking this crazy amount of information the UFC website had, mostly around fight stats, these tables, and how you could reorient that information, reorganize that information so it would be consumable on a Motorola Razor with a directional pad, and enable people to ingest that data in interesting ways on a small device. It launched on a fight night. They kind of announced it during the programming, and we got tons of hits that night. But when we reviewed our logs, nobody was looking at any of the interesting work that we did. They were only looking at the pictures of the fight girls, essentially.

Allen: Okay, okay.

Kyle: Yeah, so super disappointing, but also an interesting glimpse into my complete lack of user testing at the time, which would’ve been if I had just talked to somebody, they would’ve been like, “Yeah, I want to look at pictures of fight girls and not look at fight stats,” and I would’ve saved myself a bunch of-

Allen: But you also learn with user testing that sometimes, if you just ask someone, they’ll be like, “No, no. Yeah, I’ll look at the fight stats,” but then you observe what they actually do, and then they just look at the fight girls, so that’s what the user testing really helps.

Kyle: Yeah, and so that was my first big, I would say, product that I built, was that UFC mobile website. From there, I moved to another company after that point called Mobify, actually in Vancouver, but at Mobify was my first place where I actually started building my opinion about what design teams should look like and how design teams should grow. That first company was really a lot smaller. I was kind of just paying attention to myself as the designer. Mobify was really the first company I was paying attention to both myself and how I interacted with the other designers on my team, and how that team could scale and grow. Mobify, when I joined, it was about 10 people, I think. There was one other designer. We were in a really cool position, where again, I was doing professional services, so it was sort of outside of the product design team, but we really needed to scale. The professional services team was kind of ramping up, and so over my three-and-a-bit years there, I grew that team from two designers and a kind of set of engineers that would act as front end developers, to a focus design team of about 20. So we were, I think, 10 designers and 9 front-end developers working together to build out the professional services work.

Allen: Nice.

Kyle: And this team was great, because we didn’t have another design lead at the company that was focused on the professional services side of things, so it was really my chance to build a team that reflected what my opinions of design teams should look like, and that was why it ended up being a mix of front-end development and design, because that’s kind of how I’ve always worked. I find it very hard to disconnect how you build from what you’re building. And so for me, design teams have that component as part of them. That was kind of the first place that I started to explore how I could put teams together like that.

Allen: Yeah. It makes me want to ask a bunch of, because you say it was the first time you got to build a team that was set up the way that you feel teams should be set up, and so that makes me want to then dig into that. But I feel like that there’s at least one other chapter of your story where you maybe learned even more about how to set up teams after Mobify.

Kyle: Yeah, for sure. And so I was at Mobify for, like I said, just over three years. I was getting to the point where, and I think this is a common point for a lot of people, it was the same thing that took me from the company I was at before to Mobify, but I got to the point where I was feeling like I had plateaued. I had not only stopped being able to grow, both from the people around me, but from myself as well. And so I think that that’s that feeling of a sense that you’ve kind of tapped out your ability to discover interesting new problems or try interesting new things, and use those to make yourself uncomfortable, expand your skillset, or build your opinion in a different way, and so at Mobify, there were tons of great people to learn from there. But I think the opportunities inside of the professional services team especially, I think probably I could have found more things to do, but it was harder and harder to reach them or to access them. So I had started to look elsewhere, and a company crossed my plate that I actually had no intention of even thinking about, because they were all the way across the country. I was living in Vancouver, and this company is headquartered in Ottawa, so burying the lead slightly, but it’s Shopify. Shopify, at the time, was on my mind. I knew about it, but I didn’t actually think about it a ton. I knew that they were pretty big. I knew that they had done some cool stuff, but I hadn’t used Shopify at that point. I wasn’t that familiar with the product, other than to know that when I saw their design work, their design work seemed good. I, kind of on a whim, took the interview, flew out to Ottawa and started talking to people there. It was in talking to people there that I realized that they had a co-founder that was a designer. His name is Daniel. Design seemed like it was, and I mean capital D design, seemed like it was baked into the ethos of the company really deeply, I think because of that co-founder Daniel. He had imbued this sense of kind of humanistic or human-centric values into every aspect of the company. The thing that was really actually obvious about that wasn’t the output of the designers. It wasn’t the product of Shopify, although I think at the time and still it is reflective of those values. It was actually the way that the people inside of the company work. The way people would describe the company culture really made it seem like every part of the company had been touched by this kind of design thinking mentality. That was really cool to see, and I think made me really excited and made me want to join. But the other piece of it was that there were these other design leads that I could learn from, people that had done this before and done it in a different way from me, and that there was Daniel, this co-founder, this person who had built a fairly large company at the time from his own perspective. And so this was really interesting, because it meant that I could take these opinions that I had built purely on my own, having had no real design mentor previously, and test them against now other people who had done this, had done this for longer, and could teach me a lot, could teach me the things that maybe I was not thinking about or the things that I was thinking about wrong, and really build out my opinion a bit more.

Allen: Well, yeah. And also scaling, like a common journey that folks will go through is they’ll work up to, like you did there, up to your leading team of 20 people, and maybe you’re a design manager and you manage a team of designers, but there’s a whole bunch of considerations. You could can have strong opinions that are totally validated by all your experiences about how design teams should be set up or any kind of team should be set up. When you only have a 10-person team and you’ve only interacted with that one team, and so you could might have some opinion like, “All information should be totally open, and everybody should share everything always, and you should never have any secrets,” or something like that. Then, you manage a team of teams of teams, and then you’re like, “Okay. Every once in a while, we should be thoughtful about how we disclose information,” or whatever. You see things, the extra layers about how, “Oh, things are actually more complicated.” Unfortunately, they just get more and more complicated, so what were some of those things? I mean, I guess I’m sort of going too far ahead in the story, because just your story, you’ve just now joined Shopify.

Kyle: It is kind of an interesting breakdown because it really was this build up of things that led me to the point where I could transform from that initial design lead role to, like you said, leaving the company as the head of design. It really kind of depended on my ability to dissect what I was learning and who I was learning it from. I think I got really lucky that I joined Shopify when I joined it, because I was joining as one of the first design leads at the company. I say there were other design leads around, but there were 30-something designers at Shopify when I joined. Up until that point, all of those designers reported to one of two people, so it was a hyper flat structure and that was across three offices. 30 to a lot of teams now probably doesn’t sound all that big, but I was used to 10 designers with another 10 to front-end developers, but the company itself, they didn’t really consider design leadership as a skillset. The things that I was pulling out as those design values, I don’t think they would be able to articulate necessarily, other than the fact that they shared them. I joined as one of the first design leads. A few other people in the company got promoted to that position, and then another person was hired in, and we all sat under those two previous people who were the design directors. The fun thing was essentially now we had a set of new leads, as well as some leads that had come from another company that had their own opinions. We were trying to form a team of leads to build values around. Look, that’s why I say I was lucky, is because that meant that I could come in and present these opinions without having to feel too fearful of whether they were correct or not. It’s like, “I tried this at my last place. Should we try this? We do this currently at Shopify. Let’s keep doing that,” or “Maybe this doesn’t work so well.” So it wasn’t like I was joining a team that had really established practices. It was more like a place where I could come in and kind of play a bit safe play, where you’re not playing too much with people’s careers, but play in terms of leadership.

Allen: Sure.

Kyle: It meant that we could really test out how we wanted to scale, because the week I joined was the week that Shopify went public, just to put it into perspective. So no leadership up until the point they went public, and then post public, leaders coming in. The team started scaling quite rapidly, and so we were 30 designers when I joined. When I left six years later, we were about 450 UX people. Quite a lot of scale, and a lot of that happened in the, I would say, first three years that I was there. We had to question a lot of things like, “What does our organizational structure look like?” We were, at the time, a design pool, which I have opinions about. I’m sure we’ll talk about more later.

Allen: I want to access and share it, get those opinions, because-

Kyle: Yeah. I’m going to stop telling this story and we can get into it, but we were a design pool. There were something like three or four front-end developers for the entire company. Every engineer did front-end development with the stuff the front end developers created. It was a really interesting structure, and not one that matched kind of my opinion about what a team that builds great work looked like. And so a lot of the work post that point was just testing and applying design practice against this team.

Allen: Just to make sure I heard that right. Shopify went public with three or four front end engineers?

Kyle: Yeah. They, I think, wouldn’t even call them engineers, although they’re definitely engineers, but they’re front end developers. I mean, John Snook, of BEM fame and lots of other things, was leading that group, but he left the week before they went public. And so there was this little team left behind that was really focused on, as a rail shop, like rails components essentially that the rest of the company would use to build the product.

Allen: Right, and so much was being done on the server side, rendering and all of that kind of stuff, that front end development was this kind of little side thing, I guess, or at least at that time?

Kyle: I think it was actually more like a little burgeoning systems team, so they built these components and they components were useful and hyper successful. They were kind of everywhere, but that meant that the engineers across the company could just use those to build and build pretty rapidly.

Allen: Yeah, so one of the things that I think would be great to dig into, because it’s something that comes up a lot as people are thinking about, they’re growing their teams or trying to improve the organization of their existing teams. When we think about the way that design in particular gets organized, it’s often easier, I find, to find resources and references about how engineering teams get organized, rather than design teams. But it matters how you organize your design team. One of the things in particular, it’s a point of either pain, debate, or just angst is this thing that you reference as a design pool. And so you end up with a lot of orgs that end up, “Okay. Well, there’s the design team, and there’s a design manager and there’s a bunch of designers.” Then, those designers get picked and pulled into different projects that their manager may or may not know really much about, really have any context on, or really have much can rigor about how that works. Then, often when you get to a team that has hundreds of designers, then there’s some structure of what they call matrix organization, where maybe they have a manager that’s the person that manages the product that they’re primarily working on, but then they also have somebody who mentors them for their skills. Of course, that has a whole bunch of downsides, where the person who is maybe setting your promotion, choosing whether or not you get a promotion or not isn’t a designer, but you’re a designer. And so how do you convey to them your skills? So I don’t know. What did you learn about the organizational design mistakes and lessons learned, I guess, about that in the time of scaling up that group?

Kyle: Yeah. I mean, I think there’s lots of things in there that are interesting. One of the big ones is the idea that a matrix org is inevitable I think is something that I fought really, really hard against. I went down the path initially of thinking that a matrix might be the best choice for us, but maybe I’ll step back a bit and talk about the problems that I was seeing with the team and how the team interacted as the place that I started. The team that I joined, it was a design pool, but I was responsible for five designers. Those five designers generally were assigned against a set of problems, I’ll call them, although there were probably project areas at the time, more than anything else. One of the first problem areas that was throwing up red flags was an area in Shopify called Home, and it was kind of, canonically, everybody I talked to at the company was like, “Oh. This problem’s unsolvable. Good luck. You’re going to encounter a bunch of stakeholders that all have different opinions, and nobody can agree on what this thing should be, and it’s basically an impossible design task.”

Allen: Have fun.

Kyle: The designer that was responsible for it was having a hell of a time trying to figure out how to navigate all of this. And so the first real design leadership job that I did there was just trying to break all of that down so I could understand what the problems were, where the problems were, and then help that designer kind of cut through all of that tape at the time to do good work. And so this was kind of an exercise in understanding why design leadership was hard at Shopify at the time and why even design at Shopify was hard at the time. It was really through that, that I started to understand that I needed, as a design leader, to deeply understand the problem that my designers were working on. And so I dove in really deep on this home problem. Kind of looking back, after I kind of came back out of it, was I realized I had neglected the other four problems, essentially, that the other designers that I had were working on. And so this one fire kind of consumed my entire ability to help lead my other designers. They were getting the short stick, while this other designer, who had the biggest problem in terms of maybe company impact or what was on fire, was getting all of the attention. And so this started to generate this little idea in my head of design leads should be problem oriented instead of, let’s say, people oriented. That’s maybe not a great way of talking about that, but instead of saying, “You’re responsible for five people, and it doesn’t matter what those five people could work on, because you’re a design leader, and you’re just going to lead the design.” It’s actually, “You’re going to lead the design for that problem area, because you need to be as invested in that problem area as your designers are for you to solve problems with them,” essentially. And so I started to explore this kind of concept of reorganizing the team that we had, which was one designer against one problem area usually, and then one design lead leading five problem areas, to saying, “Well, what if we take our team and we cut it in half, essentially?” So we say that there’s always two designers on every problem area, and we start to try to make sure that they have always have somebody that’s working on a problem with them. And so that meant that every design lead, instead of having five problems that they had to think about, would only have two to three problems that they have to think about. So you’re trying to narrow this what each design lead had to think about. But then with the eventual goal of it being actually a one design lead to one product manager ratio for the company, and that each design lead then would have two designers, usually complimentary skill sets that can work with them to help solve problems with that product manager. When I looked, looked across the organizational structure, is that we usually actually had one engineering lead per one product manager. That was already the structure of Shopify, but design, for some reason, was kind of this amorphous blob that got assigned against problems here and there. As I talked to people, it wasn’t that each of the problems was worthless to the company than the others. It wasn’t like there was some rating or value assigned to each of the primaries. It was just that we didn’t have enough designers to cover everything. That was the first really big scale point for us, where it’s like, “If we want to try this organizational structure, we’re going to need to add designers to the team to be able to cover all of the areas that we want to cover,” because Shopify wasn’t going to do less just because of this. Shopify’s never doing less. It seems like they’re always doing more. The two designers thing actually became super important, because it meant that we could basically say, “We have a set of really experienced high context designers that are already in the company. As we bring designers in, now we can pair them with these designers and grow the team that way.” It wasn’t necessarily a senior junior model. Sometimes it was a strong visual design with strong product design, or a strong experience design model. It was just complimentary skillsets to try to create a robust team that could solve problems better than one person alone could, and so this was kind of the first org change that I made there.

Allen: One of the things that you see across different companies and orgs, different companies definitely, but even different teams within a lot of companies, is that the ratio of design to development or just the amount of design budget or attention that will end up getting put on problems will differ depending on the problem or depending on the part of the product. How do you think about how design, assuming that you have a finite amount of designers, either because it’s hard to hire great designers, and also you just have a certain amount of budget? You have a certain amount of design resources across the whole company. How do you think about making sure that the time and attention of the design team is being put on the things where there’s going to be the highest impact and leverage in terms of business outcomes or whatever, as opposed to just peanut buttering them evenly across all problems, and there’s like some backend dashboard that no one really cares how it looks like or, really, does it even need a designer? But then there’s something that has a way higher, I guess, return on the time of the designers. How do you think about that when you’re trying to set up teams or some structure for teams?

Kyle: Problem with, I guess, the word problem is it doesn’t have a lot of scope attached to it, and so the way I like to think about these things is basically, you’re actually starting from the top instead of starting from the bottom. Let’s say you have two designers, we’re just starting at the two designer space. The problem space that those two designers are responsible for is probably the entire product, so how do you pair those two designers with the people that have the most context on the problem that they’re working on? How do you make sure that they’re working with the person that can help direct them against the most impactful problems to solve, for instance? And so with that design team, kind of in that early stage of Shopify, it was actually not about pairing them with a product manager necessarily. It might have been pairing them with product director, because we had two designers to work on, let’s say, the scope of shipping, which was under a product director, maybe had a few engineering leads under it. It was actually working with the product director. In that case, that design lead could decide what the most impactful problems to work on within that space were. Then, as you add designers, you can kind of start to specialize within that space. To answer your question, obviously you can’t solve every problem with design. If you had infinite people, you could probably do that. But it’s really important to understand what is the, both, most impactful business outcome that design should be working on and the most impactful user outcome? I think if your product is well oriented, hopefully those things are aligned, although they aren’t always, but ideally, what is the most impactful user outcome for design to look at? I think this actually boils back to a concept that’s really, really important for design teams, which is, I use the word opinion, which people hate, but what is the design team’s opinion on the most impactful problem to solve, and how do they relay that information to product management or to whoever the decision maker is, the stakeholder is, to make sure that that gets worked, done. Because I also don’t being a design team or building a design team that is just in service of everyone else. The goal is not that design is just essentially a production team that gets told what problems, or even usually what solutions to build.

Allen: Or solutions to apply, yeah.

Kyle: But even getting told what problems to solve isn’t a great place to be in as a design team. Really, a design team should be able to identify what problems need to be solved, and make the arguments with the stakeholders, whoever those people may be, for what the solution should look like.

Allen: Yeah. It’s interesting that you raised that, because organizations vary widely among how they define product management, and how the boundaries in between product and design, and often you hear on podcasts and articles, your product managers, product management leaders, chief product officers talking about what product management should be and what the responsibility of product should be. But I’m curious of your take, as someone who’s run, grew, and scaled the design org. What do you think the boundary in between design and product should be, and how do you think about? Obviously, you can say, “Oh, yeah. We collaborate, but where do you think those things kind of pair together, and what do you think is product only and what do you think is design only?”

Kyle: Yeah, I think teams where product management does does it all, where they kind of say, “Oh. I own all of this thing,” just tells me they don’t have the right design leader to work with most of the time, or maybe they don’t have the resources for that, or maybe they just haven’t figured out how to do that with the person that they work with. But from my perspective, a product manager is responsible for the business outcomes of the product that they’re building. So they’re responsible for making sure that what we are working on aligns with the strategic goals of the business, so that is a very business oriented perspective on what product management is. But I think that helps, because it allows the product managers to focus on the aspects of the product that are going to make the biggest impact on the business’s success. The design leader’s responsibility is to ingest those, that business strategy, understand it deeply with the product manager, and discover the best user outcomes based on that business strategy. Product management can tell me, “I need to solve this problem for our users, using through this aspect of the business.” I’m going to pick a shipping example from Shopify. Again, product management is like, “We know that there’s a large opportunity for us to start providing our own shipping labels within the product, so we want users to be able to buy and attach shipping labels to their fulfillments inside of the product.” That is a business outcome. That’s something that the product wants to be true, but what they shouldn’t be able to say is, “And they’re going to do that by using an interface that does this and this and this, and users will be able to interact with these things on each order, and it’ll look like this.” That’s not the realm of product management. The realm of product management is not to decide how that problem gets solved, but instead to say, “This is an important problem, and it’s one that’s worth solving,” and also then to act as a stakeholder through the production of that solution to decide whether it’s achieving its goals or not. So that really relies on product managers and design leaders that are working side by side and are really two sides of the same coin in terms of problem solving, right? Ideally, your design leader and your product manager, together, are saying, “Hey, this is a problem that’s really worth solving. I’m seeing users being really frustrated by this on this side, and it’s a really big opportunity for the business if we could solve it,” and then that makes this a problem really worth solving.

Allen: Yeah, and so then you get an actual working together to solve problems model, rather than the sort of degenerate case that you see in a lot of companies, which I think is, as you shared a little bit of, is seeing these same problems when you had the five designers working, and only one of those designers had a design manager that was actually helping them solve business problems, and the other four were working with the product manager that’s like, “Okay. Well, I have this designer who will make designs, but will just sort of do it in a fairly, not a dumb way, but almost a naive way,” where it’s just the product manager’s like, “Hey, we need this, and then the designer is like, “Make this,” because they’re not necessarily engaged, trained, set up, or expected to be working through engaging with, “What are the business problems that we’re trying to solve?”

Kyle: Yeah. I think a lot of the times in those cases, competent designers will create competent designs. The designs will still be fine and good, but they won’t ever be novel probably, and they definitely won’t ever be the thing that takes an experience from what could be good to what could be amazing. The piece of the equation that we’re leaving out of this is the engineering lead, in my opinion, is just as important in as the product manager, because it’s those three people working together that set the constraints in the right way, that kind of do the discovery in the right way and then apply it against the business strategy in the right way that makes for excellent product.

Allen: Yeah. What you’re describing there is what seems to becoming the industry standard, and maybe this has been actually for a while now. I don’t remember. I don’t have a good sense of what originated this pattern, but having a design lead, an engineering lead, and a product lead sort of coming together as a triad with that nice structure, where there’s a tiebreaker. There’s never a day lock, and you have three people with these three different domains, working together to shift stuff. And so you’re sort of implicitly saying that you feel like that model, which is becoming more and more popular, is the gold standard in terms of how you set up teams for success?

Kyle: Yeah. I mean, I think it is, for me. The challenge is, and everything has a challenge, is a lot of the times the triad, like the ideal that’s put out there is not the thing that you end up with. And so what you’ll usually see is, and this tends to be my question for companies, is if I’m interviewing with them or if I’m just talking to people from them, is what you’ll usually see in the three-legged stool model is that one of those legs is a lot longer than the other. The company invests in one aspect of them, trusts one aspect of them, or just values one aspect of them more than the other, and that means that that relationship doesn’t actually work. It’s unhealthy in some way. And so in some cases that’s product management. Product management might get final say like, “Okay. Everybody gets to debate, but then product manager is the decision maker,” or usually it’s engineering is the people that have to build it. And so they get to be the people that tell you what you actually build, and so it doesn’t really matter what product management and design leadership says, because the engineering team is going to make all the decisions anyways. It’s actually hyper important that the triad model, if it’s going to be effective, is one, like you said, that’s a lot more, I don’t know what the right word is, a triumvirate that one of them can be a tiebreaker, that they can and do have to work together, because the relationship that you want to build there is actually one where any one person can stand in for the other. There’s so much trust between each of the individual disciplines in that, so product engineering and design, that engineering understands design’s intent and design understands product’s intent, such that, let’s say, you’re the product manager and you’re not in the room, but I’m talking to the engineering lead, I would go speak against maybe my interests to represent yours, because I understand that your interests are important, valuable, and relevant to the conversation. It’s that deep understanding of intent across the triad that’s actually the important part of the triad. It’s not that you have people in those places. It’s that each of those people understands why the other one is there and what they fight for.

Allen: And has context. One of the things that I’ve been seeing more and more teams do is involve all three of the leaders in their triumvirate in things like customer interviewing, where if you asked a lot of product managers 10 years ago, “How do your customer interviewing?” They might describe, “Oh. Well, the product manager goes in and does some customer interviews, and then tells the designer and engineer that their ideas are bad because the customers don’t like it.” That makes it fairly difficult to have, like you’re saying, sort of bring those other two people to the table and be able to engage in a meaningful discussion if product management just has this kind of thing, this sword that they can just chop you down with and say like, “Well, I talked to the users, and they said they don’t like that solution.”

Kyle: Yeah, but it’s equally bad if design does that, right? Design shouldn’t wield research as a weapon either, and so that feeling of context and trust is super important. This is the other problem, I think, with the triad triad model, which is that usually one of those people in the triad is actually the person that’s kind of either responsible for the project or has the most time to spend with the project, and that’s kind of coming back to that designer’s on problem spaces thing, which is it’s not helpful for me to be a member of the triad if I only get to spend 10% of my time thinking about that problem, and you spend 100% percent of your time thinking about that problem, I’m never going to be able to contribute on the same level as you. And so I’m always going to feel like my opinions aren’t strong enough to really argue with you in the times when arguing with you matters. And so this was that feeling that I started to, I guess, coalesce around the team around, which was, “Well, what if we take that idea of the triad, and we actually put it in place it at every level?” So not just at the director level or at the VP level, which is where you see this, I think, the most frequently, but at the senior manager level, if you have one of those at the leadership level, if you have one of those, and ideally, when you’re working on problems, like you’re pairing with design and engineering, that the design and engineers are paired against problems as well. And so you have this kind of entire flow, what I call, of problem bubbles. Essentially, at every bubble level you have this triad. By doing that, you have somebody that cares deeply about a problem represented from each discipline, that they’re completely attached to that problem space, and they’re able to really dive into it together in a way that they care about.

Allen: By the time you were the head of design, were you able to roll that out? Is that something that actually manifested throughout the whole org?

Kyle: I mean, I don’t know why they trusted me so much, but I was actually able to implement this model in, I think, my first year at Shopify. We were able to switch to this model, and I think I put a big part of this on Daniel’s shoulders, like his willingness to experiment with the team in this way, and talk with me and talk with the other design leads at the time to figure out why this made sense. But there were some flags that I think the company was seeing that made it make sense as I continued to explore it. One of them was the fact that design felt this problem somewhat. But there was really two bigger disciplines that felt it very acutely, and that other people felt the problem from them very acutely as well, which is that we had a research team and we had a content strategy team, but they were tiny pools. They were much smaller. So there was one content strategy lead. There was a research lead, and there was never enough time from either of them, and when they got parachuted into projects, they never had enough context to really solve them or help in enough of a way to make, essentially, the people that were deeply solving those problems feel good about it, so the content strategists were unhappy, because they couldn’t spend enough time on things. The people that were getting access to content strategy were unhappy, because they weren’t getting enough access to content strategy. What we were able to do was say, “Well, okay. We have this benefit, and not every company has this benefit, but we have this benefit of money, essentially. We can solve this problem with money. We can solve this problem by hiring, so what if we extrapolate the same thing that we said about design, which is like there should be two designers on every problem that matches the product management structure, but if we say that there should also be one researcher and one content strategist on every problem or maybe on a larger problem bubble, and start to build those teams out?” So then you have a dedicated researcher for your problem area. You have a dedicated content strategist for your problem area that can build up that same context and deep problem understanding that the designers have. We actually took that one step further, which is to say, “And they should all have what we call the UX developer,” but is a front end developer really focused on micro interactions and the deep kind of front of the front end that could work with that team to solve problems in interface. That maybe hadn’t been solved before. What we ended up with there was a UX team, because what we said was we’re going to pull those individuals, the designers, the front end developer, the content strategists, the researcher out of their respective disciplines, and instead, give them a problem lead. They weren’t going to get a design lead. They were going to get a UX lead, and the UX lead’s responsibility, first and foremost, was the experience of the problem area that they were responsible for.

Allen: And then they’re working with content strategy, user testing, design, UX developers?

Kyle: Yeah. They’re leading, in that case, content strategist, researchers, and designers. So this is kind of coming back to that matrix conversation, right? It’s like, in this model, you have now a lead that may not be your discipline lead, so you might be a designer, a product designer, and your lead might be coming from a content strategy background, because they were the best person to own that problem space. This was, I think, maybe one of the more contentious things that I tried to change in the organization, but in my opinion, it’s the thing that I’m most proud of in my time there. I think that had the biggest impact on Shopify’s UX team culture and the output of the work that we were doing.

Allen: And that was to change it so that those teams were intermixed and that people were not necessarily always reporting to the same person. That was their discipline?

Kyle: Yeah. I took it away from being a functional organization, which it really was up until that point, the the design leads and the content leads, and I don’t even know the term for it. I’ve forgotten all my org design terms, but really focused on it being a problem-oriented organizational structure. We had talked about, or you had brought up the idea of matrixes before, so matrices usually you have a technical lead, your content strategy lead that’s leading all content strategists from a technical perspective. Then, you have people leads that are probably leading everybody from a management perspective. Our position, or my position I guess, was that a UX lead, because they’re accountable to the experience, and the experience is really the outcome that everyone is building towards, that they should be able to lead their team from both a management perspective and from a technical perspective. The output of a content strategist or a designer on a UX team, the individual work that they’re doing is important. The fact that they’re doing good design work is important, but the more important thing is that they’re solving the right problems in the right way. And who better to determine how effective they’re being doing that than UX leader, a user experience leader that is deeply invested in the problems that they’re solving?

Allen: Yeah. That makes a lot of sense to me intuitively. I’m sure this was the thing you mentioned. It was contentious when you’re like, “I want to roll this out.” Is there people saying, “Well, but yeah. If I’m a designer of the reports to someone who is contest strategist, how are they going to help me develop my design skills?” I assume that there was a proposed solution to this as well.

Kyle: Yeah. I think at first there wasn’t much of a solution for that, other than me saying like you always do, which is by finding mentors and doing that internally, right? There’s nothing stopping you from finding, recognizing. I think everybody always recognizes the people of the company that they really respect and are doing great work, and there’s nothing stopping you from reaching out to those people and trying to learn from them. I think that was my initial take, which was probably naive. It worked fine when we were smaller, but it’s so hard, when you’re in a team of 400 people, you’re a new designer, to feel comfortable reaching out and going, “Hey, person I really respect. Are you willing to spend two hours with me to talk to me about this thing that I’m working on?”

Allen: Yeah. It can have the problems on the other side where, as you’re scaling, especially if you’re growing rapidly, you can be a senior designer who’s fighting fires and really deep in this problem, and then a whole bunch of people who are newbies that you don’t even know who they are, popping up on Slack and being like, “Hey, I know you. I read your blog post.” Then, it’s like, “Wow. That’s really flattering,” but also like-

Kyle: Yeah, yeah. I have no time to do the things that I’ve been asked to do? Yeah, and I think that that was happening for sure. I think the perspective that I built based on those occurrences was that I think you see this other thing that happens inside of these org structures sometimes, which is that the idea of technical leadership or the idea of a staff designer, principal designer, or something like that, that they’re just really good at what they do. A staff designer is just a more senior, senior designer, and I think that’s faulty reasoning in most cases. A staff designer, at least at Shopify at the time, I can’t speak to it now, but at the time, a staff designer was somebody that had leadership skills and could become a mentor for a set of designers, or could set new processes or develop kind of new mechanisms for design to be successful through their technical skills. Ideally, when we built out this kind of technical track, the things that were really important to me was that we didn’t break the idea of problem spaces. We put technical leaders in problem spaces still, and what you’d see would be a, let’s say you have a senior design leader, they would have a staff designer, a product designer that they would work with, and they would be paired with essentially. We treated technical leaders, instead of just really senior designers, I’m trying to think of the word for it.

Allen: Like a right hand of the design leader?

Kyle: Yeah. Something like that. Basically, an augment, where they had just as much ability to impact decision making. They were working across a problem space. They were probably solving really hard problems within that problem space, but they were also leveling up all of the designers within it. So they would often lead design critiques. They would be sharing techniques. They would be doing pairing sessions with designers, and this was on each of our disciplines. That was what we tried to do, so we would have a staff content strategist, a staff researcher, staff designer, a staff running developer that could help grow the people in that area on their technical side, but they weren’t divorced from the problem that they were working on. They weren’t just off working on anything. They weren’t in the middle of the org somewhere else. They were deeply focused on the same problems that their team was focused on.

Allen: Yeah. That mirrors what a lot of effective engineering organizations start to set up, is a similar idea where this idea of a staff engineer is not just a person who’s really, really good at typing, that you’re co-programming language, right?

Kyle: Yeah.

Allen: That’s nice, but also leadership, having bigger impact, working on trickier problems, and mentoring other people. And so it’s a pattern that works across disciplines, but nothing about engineering in particular that makes that a good path, and then therefore justifies this idea of going out of our way to give a career path for people who want to stay as an individual contributor. They don’t necessarily want to be a people manager, but they want to keep growing their skills and having a bigger and bigger impact.

Kyle: I’m certain this comes up in an engineer all the time, but you’ll often hear people, when you’re leading them, say like, “Oh. I don’t want to lead people. I don’t want to be a people lead,” and those two things, to me, mean very different things. There’s a people lead, where you’re responsible for a person’s wellbeing, their happiness, and their career growth, and you’re responsible for their relationship with the organization and hopefully them growing within that. But then there’s leading people, which anyone can do, no matter what your position is. And often what you’ll find is that certain people are maybe more naturally oriented to leading people, but it’s a skill that can be taught. That was really important as we were building up our UX lead team, because we needed to scale a lot of people into UX leads because of the structure that we had designed, and we both didn’t want to and couldn’t hire all of those people externally, so we had to level a lot of people up into this UX leadership role that probably wouldn’t have identified themselves as being ready for people leadership or leading people.

Allen: Yeah, or the term that we would use, manager like, “I’m not a manager,” but anyone who is in a senior position, if you get better at your role eventually, even if you’re not trying to lead, you’re accidentally leading. You’re leading something, because the junior people are watching what you’re doing, and so what make it intentional.

Kyle: And there’s junior people that are leading a lot of the time. My favorite thing is seeing a junior person, and this is where I’m going to come back to this word, opinion, but junior people that are coming into a problem space that have spent a lot of time it, and they have an opinion about it, and they’re sharing that opinion, and they’re helping walk people through what their opinion is and how they got there. That’s leadership. That’s all it is. As a design leader, as any organizational leader, identifying the people that are really good at that early is awesome, because now you have basically these people that you can pour a small amount of energy into and have a huge impact on their growth into leadership, like organizational leadership, but then also being able to recognize the people that maybe don’t feel comfortable doing that, because they are uncomfortable sharing their opinions or speaking up as readily as other people are. So making sure that you’re kind of identifying what people’s leadership strengths are can also help people just mentally bucket them into the path that you can likely grow them into, and this was a huge part of scaling.

Allen: Yeah, and then how to mentor them and support them.

Kyle: Exactly, yeah. A huge part of scaling, because one thing that I was really conscious of is the fact that we were, I think Toby maybe, Toby’s the CEO of Shopify. Toby had this perspective that I really liked around the culture of Shopify, which is that teams should never more than double, essentially, in a year, let’s say. But it’s kind of a loose model, but it was really hard in a lot of cases to implement that, because we were trying to grow so fast. But the intention was that you don’t want more people on the team that don’t know the culture of the company or what they’re doing than people that do. One of the ways that we tried to manage that as we were scaling quite quickly was through this UX leadership model as well, which is that we could have a UX leader in place, and maybe we could have a whole new team under them, but if that leader who was accountable for the problem solving, and was accountable to their stakeholders, their senior leader, and all of those things, then we could actually build pretty new teams under them and have them kind of grow along the right route pretty quickly.

Allen: Nice. I love it. I also love that I had this list of all sorts of interesting things to ask you, but then we talked about org design, which I’m fascinated by, and you’re a great person to talk to about it, so I love that the conversation went this way. But there’s two things I wanted to ask you about, if I can. The first is, you mentioned in our prep for this interview that I, once, many years ago, said something that helped shape you how you think about product design. And so I’m curious, and admittedly, a little bit nervous to ask what I said. I don’t know. I’m curious.

Kyle: No, I’m more nervous than you to tell this story, almost certainly. For the listeners, Allen and I have known each other actually for a very long time, because Allen was friends, I guess. Yeah, friends. You went to SFU. Is that correct?

Allen: Yeah.

Kyle: Is that right?

Allen: Yeah.

Kyle: My roommate at the time, his name was Tim Kim. He was a computing science engineer who worked at a company called Nitobi, that ended up getting acquired by Adobe, and they went off on their way, but I had a party. My roommate was at that party, and Allen was there, and I think I was probably too drunk, so that’s part of this story, but I remember very distinctly talking to Allen and having this debate about the little green circle in the top left of window title bars, and how I didn’t understand why at the time they didn’t just open full screen. Why did I get this weird kind of constrained fit-to-content window size? I don’t remember exactly what you said, but my takeaway from that point was that Apple had an opinion that that was the best way for this interaction to work, and that because of that, there was no need for any settings, customization preferences, or anything like that. That was Apple’s perspective on what the best way for that interaction to work was, and that got me thinking a lot. I didn’t think you were right at the time. I think I was-

Allen: You were mad about it.

Kyle: Maybe I was mad, but I think I got very heated about it, because I was like, “Well, why not just have an option there? Why can’t I just say one option is give me full screen and one option is fit to content?” And then Apple kind of blew us both over the water, I think, and just made it take over the entire. Well, I think they just took over the entire screen though.

Allen: Yes.

Kyle: Which isn’t what I want either, but I started to get this feeling of, “Am I wrong?” It’s this sense that users should be able to do whatever they want with their computer. That was how I entered that debate. But after spending a lot of time thinking about it, I actually think that this sense of opinion is actually one of the most important things that a product designer, really any experienced problem solver, needs to have in order to make great decisions. In the case of this story, the thing was actually me realizing that opinion was important, and that Apple exerting its opinion on me in that way was good, even though I was maybe feeling at the time that it was bad. But now I actually think that the sense of opinion, and I’m using this word, and I’ve kind of called it out a couple of times, but I think of opinion as the confluence of a few different things. One is experience. I think experience plays a really large role in it. One is research, so I think subjective fact in a lot of ways plays a very large role in opinion. Objective fact, so data plays a really large role, and this is the part that people don’t like, but taste also plays a really large role. The way that those intermingle are the things that actually lead to your sense of opinion, and wielding an opinion is really important. How you wield an opinion is really important, but understanding that your opinion is not just something that you have. It’s not like a thing that you’re born with or just comes to you. It’s those four things really coming together to give you a perspective on something. By understanding that that’s how opinions are formed, you can actually understand how to change your opinion, change your perspective much easier than if you don’t understand those things. So if you know, for instance, one of a Shopify ism that we used all the time was strong opinions weekly held. It’s really important that you’ve had strong opinions that you stated your cases really clearly, and that you felt strongly about things, but that you didn’t hold onto them too strongly, because nobody likes somebody that never lets go of their ideas.

Allen: Well, it’s not just that nobody likes it, but also it doesn’t lead to us ending up with the good ideas that are actually converging towards good ones.

Kyle: Yeah, totally. But the problem was that most people were really good at building strong opinions, but really bad at weekly holding them, so you’d see two types of opinion holding, essentially. You see people that give up their opinions way too easily. So people that have great ideas, but then just let them kind of go away because somebody pushes on them, and you have people that hold their opinions way too tightly because they don’t understand what makes them their opinion. So if you can really dive into that sense of opinion, like what makes it so that you hold that thing or what makes it so that opinion is strong? Let’s say I have an opinion that the green button should go full screen. What are the things that tells me that that opinion is correct to me, true to me? If, at the time when we were having that debate, the only thing I had was really tasting, that was the only thing that I was lean leaning on there, and maybe experience. I’m used to windows, and so my experience is that this thing does this thing. I didn’t have any user data. I didn’t have any objective opinion about whether that was true or not. I think, from your perspective, Apple probably did have those things because why would they make that decision without it? Your perspective, in that case, I’m not putting words in your mouth, was the opinion that Apple’s designers have is going to be stronger than someone who has probably had too much to drink at some party. That’s clearly going to be the better opinion. By having that kind of ability to reason what makes your opinion, your opinion, you have that much stronger ability to make your arguments, and even flip your perspective on why the thing that you believe is the thing that you believe.

Allen: Yeah, I love that. I love both that it’s, I guess, very on brand that the many years ago, the story of what I was arguing about when I was drunk was that they shouldn’t make something a setting, but it should instead come up with a good design for users and make that the way it works. Then, also, I love that you’ve gone and built this sort of mental model that makes it really useful. The word opinion, I guess, is a bad word in a lot of product design circles, and they will conflate opinion with just sort of arbitrary instinct that can’t be reasoned with, but you sort of built a structure around it there, of thinking about that way that I really like it. But that if everybody thinks about having an opinion is worthwhile, and can build a mental model of why they have that opinion, then we’re way better off in the ability to actually build better opinions together and figure out how we’ve got where we are and build stuff, so I love it.

Kyle: And I think that the thing in that opinion argument that I’m making is that it’s really important to have an opinion. And one of the hardest things I find to work with is a designer that relies on one aspect of that opinion forming set as their way of building things, and so often you’ll see, “Oh. Well, research told me this, and so we should just build this,” or “The data is telling me that nobody’s clicking this thing, and so I’m going to make that thing bigger,” or whatever.

Allen: Or, “My personal taste is orange, so everything’s orange.”

Kyle: Everything’s orange, yeah. Is that a reference to the current thing that I’m working on? No. There’s too much orange in there. I was known as the purpler person at Shopify.

Allen: I have a bit of that reputation too, of over suggesting purple as the choice for things. Yeah.

Kyle: Okay. Purple’s a great interface color. It doesn’t mean anything like, “What?” If you don’t build an opinion, if you don’t understand how your experience, research, data, and all those things play into what you’re building, you’re not really designing anything. You’re just kind of responding to, you’re reacting to the information that you’re getting back. If I was teaching a product designer any skill, it’s the skill of understanding how to build an opinion and then how to share that opinion. Design is a practice, like opinion building is one of the biggest things that you can scale or that you can scale up.

Allen: I love it. Well, thanks Kyle. It’s been really great having you on the show. How do people go to learn more about you and your work? Where would you encourage people to go?

Kyle: Oh. That’s a great question. I actively avoid social media, so I am not on any of the social media things that you can find. I have a website that I haven’t updated in a year, but at least lists out some information about me, so it’s kylepeatt.com if you’re interested. The best thing about that website is that it’s got a button that you can click that lets you email me, which is just my email. But if you want to email me and talk about any of this, I really love it when people do that.

Allen: Nice.

Kyle: I also have a little button you can click that shows you my New York Times Daily crossword leaderboard, and lets you add me as a friend on that if you want to do crosswords together.

Allen: Awesome.

Kyle: That’d be fun.

Allen: Thanks. Well, we’ll link that up in the show notes. It Shipped That Way is brought to you by Steamclock software. If you’re a growing business and your customers need a really nice mobile app, get in touch with Steamclock. That’s it for today. You can give us feedback or rate the show by going to itshipped.fm. If you rate the show on Apple Podcast, that helps other folks find the show, and you can also find us on atshippedfm on Twitter, or we’re also on Mastodon at Steamclock, so you can find us there. Let us know what you think, and until next time, keep shipping.