Figma is not the source of truth | Ryan Lucas (VP of Design, Rippling)

Brett: Thanks for joining. I'm excited to get into it.

Ryan: Yeah, I'm excited to be here. Thanks for having me.

Brett: So wanted to kick things off by just sort of getting your definition of what you think the job to be done of a design function is at a software company.

Ryan: I think you have to define design maybe a little bit at a software company where it's helpful too. I think people don't ask the question like, "What does engineering do?" People kind of have a sense of it, but I think you hear more often like, "What does design do?"

Brett: Or what does sales do?

Ryan: Yeah. What does sales do? They sell stuff. My definition of what engineering does is engineering uses the techniques of science and math and they build technical solutions and systems and structures to solve problems, right? That's sort of the essence of it. And I think design is not that different. The tools are maybe a little bit different, but design is very much about solving problems and it's about making things to solve problems. So maybe it's a little bit less on science and math and it's a little bit more on humanities and social sciences and arts. Psychology or cognitive science, visual arts, anthropology, ethnography. Maybe those are a little bit more of the toolkits. But even then, I think that's a little bit imperfect because if you study architecture, you have to take structures and statics. And I studied industrial design in school and you have to take material science and manufacturing processes. And those are pretty applied sciences and pretty hard sciences. So even then, I think there's a lot of overlap in how you think about engineering and design. And I think that's maybe a helpful point to anchor, like what the job to be done for the function is. I think of industrial design, which is what I studied, as sort of the base of software design, like the modern practice. I think a lot of people hear product design, which is the term that we use often for designers today. And they think of product design, that's pretty new. We used to call ourselves UI/UX designers or interactive designers. And that is true, but to me, the true practice is basically the same as industrial design. You have to think about what you're building and why and for whom. You have to have a deeply informed understanding of your users. You use that to make design decisions. And then you have all these sort of hard skills that come around that of like, how do you make things? And whether you make something physically like table or whether you make something on the computer, you're still dealing with a medium. You have to know that medium. And I think that the essence to me of industrial design is very much... There's an industrial designer named Henry Dreyfus, who's quite famous. You'd probably recognize some of his works if you saw it. He designed the Bell 500 telephone, which is kind of like the classic heavy telephone rotary dial. The Honeywell Thermostat, which if you've seen the Nest thermostat, it's actually based on that. And he wrote a book that I think it was in like 1955 or somewhere around there called Designing for People. It's an awesome book about just the practice. But one of the things he says in it is that basically products that look good and work well sell better. And I think that is the kind of essence of industrial design. And so when I think about the modern practice of software design, what do we do for a company, it's like, well, we're trying to make products that look good and work well because we think they will sell better. They will accelerate the powers of a business. Or in some cases, I think they can create the powers of a business. What that looks like pragmatically, that's maybe like the philosophical thing, like what does that look like on a day to day. I always talk about useful and usable and desirable as being like the three things that we need to deliver. And when I think about like practically what useful, usable, desirable means today when you're designing products, useful is pretty straightforward because it's just utility. It can like do a job. Like maybe a really dumb metaphor is like if you have a small tree in your backyard and you're like, "I no longer want this tree to be here," you want to cut it down, how do you do that? Well, it's like maybe you go into your garage and you're like, "I think I have an ax in here somewhere." And you fish it out and the ax is just completely dull and like rusted and the handle's falling apart. There's like no utility. The thing... You just can't cut down the tree.It won't do it, right? Maybe you find in there that you do have an ax, but maybe it's like the wrong ax for the job. And when we talk about like design, there's obviously a lot more to tactically what it is, but I really think like well-designed products, products you say that look great and work great and hopefully sell better, those are the three things. Those are what you have to deliver. And the sell better piece is used. Like, do people use this? So useful, usable, desirable, and used. And I think people often forget about that last bit, but I think it's incredibly important to the practice of professional design, again, whether it's physical products or software products. I think Dreyfus said the designer's job is not done if the product doesn't sell, and I've always believed that.

Brett: That. How do you think that squares with the other functions that are involved in sort of delivering something to the customer? And in your definition or the way that you think design should function, is the responsible part you design or in so many things, these things like desirability, well, there's product marketing elements often to that.

Ryan: Yeah. Yeah, yeah. Totally.

Brett: Or usability. There's what's the latency of the product. That might be more of something that engineering is responsible for. So do you think how those things relate to, does it matter who is the primary owner versus supporter in a given company?

Ryan: Yeah, that's a really good question. I mean, to me, the answer is no. I think it's sort of a shared responsibility, and it may differ from company to company. It differs from team to team too, right? You're always putting together a crew, a cast of characters and trying to assemble the right skillset. And in any given time, you might have a product manager who actually was originally a designer or has great sort of aesthetic skills. You might have an engineer who's like a really good product and business thinker. These things genuinely tend to be shared between people who are making stuff. But I think the original definition of industrial design, if you go back to Dreyfus and his ilk of that time, like if you read that book, Designing for People, he basically literally says in the front, he's like, "A designer is part salesperson, part marketer, part PR person, part artist." He's like, "You need to know a balance sheet, you need to be able to sort of write copy, you need to talk to customers, do all these things." It was a very holistic view. And the idea behind it is like, you basically can't deliver a well-formed product unless you have an understanding of all of those things and you're probably by nature of doing it going to touch all those things. In modern practice, look, there's specialization, right? Everybody cannot do everything. It's impossible. When you're a smaller company, when you're a startup, much more possible. And I think you see it more. You're like, "We don't have any PMs, so our engineer and designer are doing it." As you get bigger, there's just too much work. But I think the spirit of that idea is really important to me. And this is maybe a place where I might differ from other design leaders, but I think that the EPD trio has to be a Venn diagram. It has to overlap to build great product. And again, it can differ a little bit from team to team and company to company, but the nature, you're just going to naturally step on each other's toes a little bit, I think in a good way. And that's how I think about the space between the functions, product marketing, marketing, product management, engineering, design, is like, if you have that skillset, it's immensely powerful. That's how I've always tried to practice. I'm like, I would say like a pretty decent front-end engineer. Not a great back engineer, a decent front end engineer. I ran product marketing for a bit at Retool and I've definitely done a lot of it in startups that I've run. I love core functionality of design. I love making things. I love the hard skills of talking to users and framing problems and making and building UIs. But I also love business and thinking about like, "Is this the right thing to build and who's going to use this and what's our strategy?" And I think the best makers of any product probably care about the things around them. And I think when you see people who don't, that lack of curiosity, that more specialization, I think you generally, maybe not always, but I think you generally get worse products because of it.

Brett: How do you measure success for you in the role of head of design or VP of design or leading a design function?

Ryan: Building an environment I think in design in particular where people feel like they can truly really do good work, like do the best work in their life, that takes work. It's a lot of work. The skillsets are not necessarily diffuse. You're looking for certain types of people, especially if you're looking for people who are these generalists. To be able to recruit, find people, get them in, get them up to speed, it's a big part of the job. And measuring that, of course, is like at the top line. It's like, "Are we making our hires? Are we getting the right people in?" And there's a bunch of metrics you look at when you're hiring; time to hire and onsite to offer rates and all those normal standard things. That's a big part of it. I think there's the product bit, which probably overlaps with quality a lot. When I think people think about design and we talk about useful, usable, desirable, you're very much entering into the world of, "Are we shipping a quality product," right? "Are we shipping a product that we think does these jobs well for our customers?" I think ownership of that, ownership of quality again is a shared ownership, to your point. Stability of the system or reliability of the system probably falls a little bit more into the engineering world, but something like performance is shared because perceived performance is often very much a design problem. It's not like you can say, "The API needs to be faster." It's like, "API can't be any faster, but how can we make it feel faster?" And then you start talking about interactions and perception, right? Maybe that comes a little bit more in the design world. So I think you're looking at that category of things. But I do also think, and this might be controversial, but I think the design leader needs to have ownership of building the right things to some extent. I mean, again, it's shared, I think, with the product function. But like research, for example, sits under me at Rippling and our research function is very strategic. It's very much looking around the corner. It's less evaluative and more generative. And I think that type of thinking of like, "Where are we skating to? What are we missing?", that's often lives in design and then you need to be responsible for that. And not just generating it, obviously, because generating it is one step, but if the company's not able to use it and access it and act on it and make decisions on it, then it's probably not that helpful. So that's sort of another category of things. I think there's the metrics you look at when you're thinking about these things. Like for quality, there's CSAT and there's NPS, there's customer sentiment things. I think those are useful. They're not perfect. They're lagging. They don't always tell you exactly what's going on, but they're useful to track. The qualitative bit is probably generally the more interesting stuff. And you see that in evaluative user testing or you'll see that in surveys. You can do ethnography, right, shadow customers. And that usually, I think like Nielsen said, you kind of only need to do five tests and you kind of know what's going on generally. And I think that's often the case. And so keeping attuned to that. It's very easy to get into execution and production mode of just like, "These are the things we have to go do and ship in our business right now and forget that you really need to be constantly sanity checking them against, did they solve the jobs to be done, did they solve the problems we identified, are they working. And I think a leader can be a check on that. The quality bar bit is something that I think is part of the job of the design leader in terms of thinking about success. Like, who ultimately owns the quality bar or like has the final say of, is this good enough? Probably the companies that you would look at and think are the most design-driven, they tend to have one benevolent dictator doing that, right? So it might be Brian at Airbnb or obviously Steve Jobs at Apple. And I think that can be partially the design leader's job. It depends a little bit on the org. I think defining quality is a big part of that. Does the organization know what it means? How do you know they know what it means? Can you get specific? I've done a bunch of work there, and there's I think some really interesting prior art in that space. It goes back to the '70s in software quality actually that Silicon Valley is good at forgetting stuff that we've done. And you go back and you read old papers and you're like, "Oh, we've really thought about this." And I think that's definitely true for quality. And so a lot of that stuff is just surfacing it to the org and communicating it, making sure people know it and can act on it.

Brett: How do you think about what is excellent in the context of a director versus a VP or exec that runs the function other than more span and scope and responsibility? Or like, what is required? What is the gap between someone who is effective as a director of design and someone who is effective as a VP of design?

Ryan: I've been this week debugging some places where it doesn't feel like we're always getting the right product to market and from idea to production and then like, "Is the problem that we're not specifying the design correctly?" And so we're not able to build it correctly because the specifications are wrong, which is maybe upstream and a little bit more in the designer's house. Or is the problem that we're specifying it properly, but somewhere along the way, maybe it's that engineering, like we're not sort of building the thing that's specified. And there's a bunch of ways that breaks down into individual things, like skill sets of the individual people, how fast we're moving, number of engineers to number of product designers. But looking systematically at sort of problems like that is also a big part of my job where I'm not debugging one individual problem. I'm really trying to see the patterns between them. I don't want the specifics very much. I'm like, "Give me the cases. Give me the examples," but I can start to pattern match and then go like, "Oh, I think we can solve this problem across the whole org potentially. And what are the changes or the processes that we need to put into place to do that?" And I think it's a little bit harder to do that when you're really in the weeds on a domain of a product.

Brett: Do you think the most capable designer should run the function?

Ryan: I think it's really important for design leaders to be hands-on. And this is like a very timely topic. A lot of people are talking about this, I think, in the industry right now. I think you hear this more and more. There's a generation of leaders who are maybe a little bit more focused operationally or like on organizational complexity rather than product complexity or like core design problems. I think that's bad in general. I think your design leader, I don't know if they should be the best designer, but I think they should be one of the best designers. And that's because you have to really jump up and down in altitude. I think this is true in engineering as well, but when you're in a function that builds things, like builds products, build services, you have the context which is very rapidly from thinking systematically, thinking about the goals of the business, resource trade-offs, how to get a team to do something that they don't want to do. And then you also have to be like diving deep on the quality bar and being like, "Whoa, this is not the right solution and I need to figure out how to get this back on track." And sometimes you can delegate that stuff to other leaders to do. Sometimes it doesn't make sense to do that, I think often. At Rippling, I think Parker, the CEO, is well known for this, Parker Conrad. People talk about founder mode. I think before founder mode existed, Parker was doing founder mode. He's just in the weeds constantly on everything. And he very rarely goes to me first, almost never, when he sees a design problem. He goes straight to the designer who designed the thing and he gives them feedback. I actually think that's really good because they hear directly what his opinion is. It doesn't get filtered through me and then my director and then somebody else. And I think design leaders need to do the same thing. It's like much better to hear it directly. The feedback that I give is often different than the feedback my managers and directors give. And it doesn't mean it's necessarily better or worse, but it does sort of illustrate those points when it's not reconciling. And I think if you're just not in the work like that every day, what's going to happen is at the end, you're going to see the work and you're not going to be satisfied with it as a leader and then what? It's like your team went through the whole process and they're going to get that feedback when it's too late to act on it. I also think you can build a lot of credibility with your team and with ICs when you show that you can still do the job. There's like a trust that comes with that. I like to stay sharp on stuff. I like to still stay up on the tools. It helps just me think more efficiently. I think I've bounced back and forth between leadership and founding and just doing work myself and my career. And I think it's just useful to just stay close to it. It just makes me, I think, a better thinker in all ways. So through that lens, I would say, yes, it is, I think, extremely important for a design leader to be incredibly hands-on, close to the craft, close to the practice. I don't know if they have to be the best one. I think sometimes that happens, but I think you see a lot of folks in the industry who maybe try management and then they're like, "I miss making stuff and it's a proportionally much smaller bit of my time, and I really want to go back to that." And those become your staff level, principal level ICs. And they do a lot of the same work, they just have more bandwidth to be hands on. And I think truly those can be parallel paths in a lot of ways. The other stuff that comes with running an org isn't everybody's favorite.

Brett: Do you think someone effectively running a design org can be someone who's an extraordinary designer and a mediocre general manager, or does that generally devolve and actually not work?

Ryan: I think it depends on the size of the org is what I would probably tell you. I mean, this is the most obvious example, but if I think of Jony Ive, it's like the Apple's design team, industrial design team at least, was never that big and they did a lot of work and it's a giant company, one of the largest companies in the world. I think if that's true, then you don't probably have to be the world's greatest manager. I think being very good at the hard skills of design is probably the most important thing. If you need a more scaled design org because of the nature of your business, and that often happens, then I think the answer is like, no, it's not going to work. You're going to hit the limits of all the things that come with trying to become a scale leader. Understanding what to let go, designers are all perfectionists, I think that's a very hard thing to do when you have a large fan of control. You're constantly making trade-offs that the business needs. There's decisions that there's like no good answer on. You're like, "Both of them are bad. What do we do?" I think you have to have somewhat of a skillset to operate that way. And you have to think really critically about the business. I mean, it's kind of what I mentioned earlier, just like I think being a generalist, really being able to understand the business from first principles, put yourself in the shoes of other functions, hopefully know a bit about how they work and be able to speak their language, if not perfectly well enough, it's just really important. And I think if you can't do that when an org gets to a certain size, you're just going to have a really hard time, again, working with your first team working laterally across the business. It's my experience at least.

Brett: You touched on this a little bit, but when you think about earlier roles in your career relative to what you're doing now running a function, what are the actual skills that had to be developed between those two points? Not just the things that are more encoded in your DNA standard, sensibility, whatever it might be, design sensibility, but like the practical things that you actually had to figure out.

Ryan: Well, I can tell you what I think the core things that you have to do as a design leader are, and then I can maybe tell you of those, I think the harder ones to develop and maybe where I struggled a little bit along the way. What I always tell folks when I'm talking to them about leadership or talking to my own leaders is like the four things that design manager needs to do, people management, we talked about that, right? Recruit, retain, develop, build a good environment people can do really good work, they feel like they can do really good work. If people aren't able to do that, you can find them a new home, that performance management piece. The second is execution. Sheer execution really, really matters, especially in hyper growth companies, which is where I spent a little bit more of my time. Speed is like just always a requirement in that world. The business that you were operating in six months ago is not the business you're operating in now. And that means execution is like a constantly moving target. And can you get stuff done and can you drive a group of people to get stuff done effectively? That means installing some process, hopefully not too much process. You still want to move fast. That means negotiating cross-functionally, building good, cross-functional relationships, but it's really about delivering on the commitments that your team has made to the business consistently, basically. And then those are like, I would say, like the foundation of like, probably all managers need to do that stuff regardless of your function, true in design as well. The other two are strategy and quality. And strategy probably touches on what you're asking a little bit about like, "Where are the lines between these functions? If this is true and these things are shared, how do you figure this out?" And when I think of strategy, it's very much building the right thing. And when I think of quality, it's building the thing right. And so building the right thing is like, "Are we figuring out how to put the best product into market and the right product in the market for our business?" And that's going to touch lots of stuff. It might touch pricing and packaging. It's going to touch hopefully a pretty deep understanding of users. You need to be able to connect design decisions to user needs in a really tight iterative feedback loop. And to do that, you have to have an understanding of strategically what you're trying to do. And then quality is very much like, "Okay, when we know what direction we're going in and we're aligned on that and we feel like it's the right direction for the business, how do we do it well?" And we talked a lot about some of that stuff earlier, but where managers I think often struggle with that stuff is they maybe like over index on one. And I can tell you a place in my career I think I spent too much time over indexing on one is probably the quality bit. That might be like the most common one for designers because most designers are perfectionists. They care about excellence. They care about really touching the work. You have this idea in your head, you're trying to make the idea real. If it doesn't quite match the thing in your head, you're sort of always pursuing that. And yet there are constraints in the world and there are constraints that you have to operate in. I think I spent too much time... You talked a little bit earlier about like, should the leader be the strongest designer in the org? I think you often find yourself in that position, especially as you're scaling, you might be the strongest designer in the org. And then your natural tendency when there's problems or the team is performing is like, "Well, I'll get in here. I can do it, and I can do it pretty fast, so let me go ahead and do it." It doesn't really do you as service as a scaling leader because it just does not scale at all. You will not have the time for it. You're not developing people. The leverage of hiring more people would actually be a much better use of time probably than you doing it. But when you're in a hyper growth business, that work needs to get done. So you feel that pressure of like, "Well, we need to get this done, and I could get this done." And I think that's a place a lot of leaders struggle with. It's something I certainly struggled with a lot. I found myself at stages of business I probably shouldn't be still working late nights and weekends and drive and work myself. So that's like a big one that I think was a hard lesson to learn. The way out of that is not a surprise. It's like you really have to hire your way out of it. You have to delegate your way out of it. You have to go through those uncomfortable periods of being like, "Well, this stuff is not going to happen or work's going to go out that I'm not going to be proud of." And you start to develop an intuition of, if you're juggling the balls, like which of the balls are rubber and it's like, "Ah, it's fine. It'll bounce back. And which are the ones that maybe don't?" And then you kind of delegate resources appropriately. But if you're a perfectionist, which I definitely am and a lot of designers are, that doesn't just manifest in the work. It manifests in hiring, it manifests everything. And I think you have to get through that hump and just realize a pragmatism, like a natural pragmatism. I think you see that it's okay. You go through stuff and stuff does fall apart and break and you go, "Oh, that was okay. Actually, it's fine." And what we got to, because I put my time somewhere else was like much better and you start to see the leverage. I think you just have to go through it. I don't think there's necessarily... You can tell this to people all the time, and I tell my managers this stuff pretty regularly, but I think you just have to go through the exercise of seeing things break a little bit and then realizing that maybe it wasn't the end of the world. Or in some cases, maybe it was and you're like, "Well, that was the one thing that I probably should not have let go. And now I know and I can pattern match a little bit on that." The other place I see, I think with the people stuff, you sometimes see managers who really heavily over index on people and they're like, "I want to build the right environment and find the right people. I want them to feel psychologically safe and they can do great work and they can trust me and I can shield them from all the chaos of the org." And that's usually, I think, a bad decision because one, you're not working with your lateral team. That again really is your first team usually. Two, the same way as I want Parker to go to an individual designer, it's better for your designers to see what's going on in the org, to hear it, to not be sheltered from it because they'll learn more and then those times you can't be there, they're going to be able to navigate it better on their own. And then the execution stuff I think just looks like, "Do you over-index on process too soon? Do you try to build the perfect... Do you try to design... Like design energy into designing the perfect little system of execution," right? And it's like, "Ah. A lot of that stuff kind of probably doesn't matter as you're growing." It's like, good enough is great. Is the work getting out? Are you doing it? So I think those are all the places that people can fail. For me personally, in growth, it was very much more like that delegation piece and just coming a little bit more hands off the work.

Brett: What's an example of when you knowingly let something go out the door that wasn't at your standards and it actually did matter that knowing what you know now, you shouldn't have done that.

Ryan: There's a case where we're working on our reporting product at Rippling right now. And so reporting is like a platform construct. So we have lots of different products and they do lots of different things, but a shared component across the whole platform is this idea that you might want to do a little bit of reporting. You might want to just build a report that tells you something. How many people you hired in the last six months, how much you're paying in deductions for your employees every month, all those sorts of things. Basically, manifest is like you're building charts and basic tables and stuff and you're sharing those reports. Basic analysis, pretty lightweight analysis. Ripplings, I think it has an original report builder. There were some flaws in it that I think we learned from customers over time, and there was a sort of 2.0 version put forward of like, "Great. Here's where we're going to go next with this product." And I think the initial pass on it was quite good. It was very thoughtful. It addressed, I think, a lot of the problems that we'd seen. And then I think over time the scope changed a little bit for some internal reasons that I won't get into too much, but scope started getting bigger, some features got sort of pulled in that weren't in the original scope. And then what we kind of found at the end is like, we thought we had a pretty good approach. And then by the time it kind of got put together into a product, we realized it wasn't good for a lot of reasons. The usability was a little bit tough. Some concepts were hard to understand. We were trying to serve two audiences, maybe like a slightly more advanced user, more expert user versus all more of an entry level user who doesn't do this stuff a lot. And you could see that stuff kind of getting jumbled. And that's like a very preventable thing. And I think that was a place where it seemed like it was on track, and I was like, "This seems like it is on track and they know what they're doing." And I turned my attention to other things in the org. And then when it came back to, it's sort of very obvious to see probably where it went a little bit off track. We're getting that back on track right now, but I think there's a lot of cases like that of just, there's many things like Rippling as a business has a lot of different products and there's a lot of different things going on. I definitely cannot be everywhere at once. And you have to make those assessments and those judgments and sometimes they feel a little bit snap like, "Where am I going to put my time? Do I trust this team?" And you get it wrong sometimes and then you realize the cost is a little bit of time upfront would have saved a lot of time downstream, and the amount of time it's going to take to sort of go back and get everybody on the same page and unravel that stuff and fix it can take a lot longer.

Brett: And so is it just mainly judgment? You can sort of bubble up and you quickly get to the question of like, what do you delegate fully? What do you delegate partially, when you let something go out the door where if you were to be the IC owning it wouldn't go out that way? Is it just judgment that's accumulated after doing lots and lots of reps or there's some other higher order way to think about it?

Ryan: Sometimes you see things and you think it's fine. Part of it is like skill of the people on it, whether it's the manager or the IC designer or even the engineers or the PM. Do they have domain experience? Have they seen this one before? Can you trust them that they probably know how to navigate this? If everyone's like new to the product problem or the domain... Like an example is like payroll. I'm working in payroll now. I've never worked in payroll before. So there's a lot of things that are probably very obvious people who have worked in payroll for 10 years that to me I'm like, "Oh, fascinating. I had no idea this is terrifying. You can't get payroll wrong." But you go talk to somebody who's been doing this stuff for 10 years and they're like, "Oh no, it's totally fine. Here's how you do these things." So you look at your team and you go, "Do they have that accumulated between them and the triad?" Maybe that helps you take your foot off the gas a little bit. Sometimes you just have to... You throw people in and you just go, "I think you're all pretty good or you're a good designer, you're thoughtful, you're talented, you've been on a bunch of different stuff. I think you can take it" and you just kind of see how it goes and you just check in, see how they're feeling, see how other stakeholders are feeling. Is the work progressing?" Sometimes it's not, and you can just course correct a little bit, get them back on track and it's okay. Sometimes it's not and you're like, "Oh, this might not be the right fit, right? Maybe I need to look elsewhere on the org." Because it's the Andy Grove stuff, right? It's like there's motivation, there's task-relevant maturity. The task relevant maturity piece is not small. And I think even in a design function, even people who've been product designers for a long time, like with the payroll things, sometimes you encounter problems and you're just like, "Whoof. This one is hard and I haven't seen it before." As you get more senior, the space where that's true probably gets smaller. But look, everybody is, to some extent, T-shaped and is stronger in systems thinking or visual design or an AI or whatever, right? And so you have to do that as well, the other things. Like, what's the opportunity cost or what's the counterfactual? If we get this one wrong, if I'm like, "Ah, this could be better," it's like-

Brett: Yeah, reversibly irreversible.

Ryan: It's very reversible. I also think about how these decisions stack too, right? So I often ask designers, I'm like, "Okay, I don't think this is sort of good enough here. I think it should be better in this way, in this way, in this way." But I'm okay with this going out the door. I just want to know what your next steps are going to be. And if you have a well-formed set of milestones, I'm like, "Okay, yeah, we're going to go out the door with this." And it's not great because we're worried about... I don't know, the feature's not discoverable. Like, "Okay, but does the feature work? Do we feel good that it's usable?" I'm like, "Yes, it's just that we're worried people aren't going to discover it." It's just tough for us to solve that problem right now. Then I'm like, "Great. Tell me your plan to go solve that problem. Is it because you need to unravel dependencies across teams? It might take a little bit more time." Whatever it is, if you can show me that you know where you want to get and then you have a plan to get there, I feel much more confident about being like, "Okay, this can go out the door." What often happens I think in software is you do the thing and you sort of know it's flawed and then you're like, "We're onto the next thing. We're not going to come back to it." This is very much about iteration, and iteration is like so important to building quality product. I think the idea that you can build a great product in one shot it almost never happens. If that was true, I think most products would be amazing because we'd just be like, "Yeah, it's great. You just do this." And then products are great. Most products are not great. The only way through to build good product is to just iterate a bunch, and then you want to iterate as fast as humanly possible. And if you have trust that that motion is happening in your teams, it's more comfortable to be sort of hands off. If you don't have trust as that's happening, then you start to go, "Geez, do I want to let that one go?"

Brett: If someone were to watch the way that you run your design team and the design function, in what ways is it the most different than pick a random sample of 25 other scale up design functions? What are the main points of difference and what's the story behind those points of difference?

Ryan: I've had other leaders I've worked with tell me that they don't really think of me as a designer, and I sort of take that as a compliment. And I think what they mean by that is, it seems like you have your hands on a lot of things that aren't sort of purely what I think of as the hard skills of design; designing screens, thinking about interactions, visual design, whatever. And that might be part of it, which is like I really push an org to think broadly. I just redid the sort of leveling guidelines at Rippling, and there's a very specific call out around product thinking. And in product thinking is very much like understanding our product, the complexities of our product, how it's built, understanding the market and competition, thinking strategically about our business objectives, where we should go, what we should build, for whom and why. And I think a lot of functions maybe don't... Design functions don't emphasize that as much because they're like," Yeah. Product team does that. They're good. They give us a thing. They figure out that stuff. We just figure out how we're going to do it." I don't like running an org that way. Again, it's a shared responsibility for sure, but I want designers thinking that way just because I think... I'm always asking them questions of just like, "How did you make this design decision? How do I evaluate it? How do I know it's right to do this versus this?" And it's always connected back to like, "What customer insight do you have? What are the constraints of the business? What are the engineering constraints?" And I really want people to have that rigor. That's one way. And again, I think other functions do that. I'm not alone in that, but I'm probably a little bit more invested in that in general.

Brett: You want members of the design team thinking about revenue or retention or pricing or...

Ryan: Yeah. If it's demanded by the org. At times, if you're building something zero to one, you might not be thinking about that stuff. If you are building something from 99 to 100, making a small change can have a big impact, and then you probably need to be extremely rigorous about the changes you're making. And then there's a lot of work in between. It just depends on what you're building. But yes, I do want them taking that mindset of like, "Why does the business want to do this? Why is this important? Why do we need to do it now instead of later? How does this connect to other things that we're doing?" I think that's really important. It's part of my job as a leader to be able to drive that information to the org as much as possible so they understand that. Our chief product officer does that. I also do that. I want people to understand the mechanics and have the information and make the decisions and that often doesn't happen. But yeah, I think it's really important. And the other bit I think that's maybe a little bit different, although this is really changing in the industry now, is I consider myself a technical designer. Like I said, I'm a reasonably okay front-end engineer. I think it's really important to be as close to the medium you're building in as possible. It's funny, I argue with engineers about this sometimes. Engineers are like, "Figma is the source of truth." And I'm like, "Figma is not the source of truth." They're like, "Don't you want that?" And I'm like, "I do not want that." Figma is a simulacrum. It's a bunch of rectangles in a vector drawing program. It is not the thing that gets put in front of customers. The source of truth is the thing that customers experience. If they experience something and it's wrong or broken, I do not care what is in Figma. It does not matter. I would much rather everybody orient to the thing that we are putting in front of customers than to orient to some of the tools and techniques we use upstream. That is probably a somewhat unpopular opinion, but it is changing now with all the generative AI tooling because it is much easier to get more designers to work in production environments. And previously it was very hard. You maybe hire a core who had that skillset, it was hard to build a whole team. That's changing rapidly. So if you asked two years ago, I'd be like, "Probably nobody thinks that." Now I'm like, "Well, I think it's becoming a little bit more popular."

Brett: Why was that controversial?

Ryan: Yeah. I think a lot of people would go, "That's impossible. You're asking for something that's just not possible. Nobody could do that." And I'm like, "Well, definitely people can do it." I've hired a lot of people who are exceptional at it. They're great product designers and they're very technical and they can commit code. I think you see it more in earlier stage startups than probably you do later stage. And maybe that's one of the inputs that people just haven't seen it. And I'm like, "Well, if you've been in early stage, you've probably seen it." But yeah, I think people are just, "You can't scale a function that way. You're just never going to be able to hire enough people," which I think was true. And that has not gone away, but it's just more and more accessible. And I've been really excited about what I've seen out of designers. I think you see some designers right now who are still a little bit nervous about the tools and they're not quite sure how to pick them up even though I think we're doing a lot of enablement around them. And then you see the designers who already know how to do that stuff, they're just accelerating. They're like, "This is great. It's just faster." And then there's a nice sort of middle core of people who are like, "I've always been interested and curious and tried a little bit on my own, but I couldn't quite get there, and now I can get there." And those folks are doing awesome and it's really exciting to see.

Brett: How do you spend your week?

Ryan: Right now, I spend probably about 50% of my time on recruiting, and that's because we're trying to grow our design work quite a bit. I think in any given point in time in my leadership career, I'm probably at least spending 20% of my time recruiting. The next thing is probably looking at work. So like I mentioned earlier, I go... We call them UX syncs, but we basically have crits for every pillar, and I try to go to all of them and they're each about an hour long. So at Rippling, I won't go through them all, but Rippling started in HR and payroll and benefits. That is called the sort of HCM, human capital management, which is a crazy term, but very anachronistic. HCM is sort of a pillar, right? So a set of related products, our talent suites in there. That group of designers basically orchestrates their own one-hour UX sync every week. They sign up for that. So you'll have usually a couple designers who bring in work every week. And then PMs and engineers are welcome to attend, and they sometimes do, sometimes don't. It depends on what work we're looking at.

Brett: But you show up and it's minute one. What ends up unfolding over the hour?

Ryan: Minute one is, "Who's up? What are we looking at today?" And so it's a couple things we're going to look at, X and Y. Okay, great. Designer sets context, "Here's what we're going to look at today. Let me give you some context if you're not tracking this super closely what we're doing, what problem we're trying to solve. Here's the feedback I'm looking for right now today." Place that crits often go awry as people give you feedback where you're like, "Yes, yes, I know, but we're not there yet. Or that's not super helpful at this stage or maybe we've already made that decision." So that can help hone what we're all looking at and giving feedback on. They typically walk through their design decisions. Sometimes they show prototypes or demos. Sometimes they just walk through the screens, and then people ask questions and give feedback. When they go well, you have a discussion and folks take notes and they write down the feedback that they get. Sometimes you use a framework. So one of the things when you get a lot of feedback is like, "What feedback should I take and what feedback should I discard as a designer?" It can be tough to know, especially with leadership, it's like when I give feedback is, "Does that mean I have to do this? Or was Ryan just throwing out some ideas?" Asana came up with a framework called Do, Try, Consider, that a lot of companies use that I really like. So do is basically like, "This is feedback you must do. You must make this change before you can progress, whether that's shipping or going to the next stage." Try is like, "I would like you to try this idea." It might not work. You definitely don't have to do it, but I want you to at least try it. And consider is like, "Here's five ideas. Take them or leave them. Up to you." And I think calling that out can be helpful for people, for everybody when they put feedback down. But I think especially for leaders, because sometimes better or worse, the gravity of your feedback probably stands out a bit. So you do that and you look at a couple projects and then you kind of ask about next steps. Sometimes I'll ask to see certain work. I also have a Friday standing set of time where I review work. So I ask designers to bring work that's either at like 20% or 80%. And the reason for that is I picked this up from ex-Stripe folks that I worked with at Retool. 20% is you're far enough along that like you're not at square one. You're like, "We don't even know what we're going to do yet." It's not helpful to get feedback at that stage, but you've probably made some decisions and started producing something. And so it's like, "That's the directional check. Are we headed down the right road?" It's a good time to be like, "Ooh, don't go down that road. Wrong road. Get on this one before you do anything more." And the 80% check is like, "Okay, we're almost there. We've got a thing. We can really show you what we've got. We can go through most of the experience," but there's enough time left that if I'm like, "I don't love this. Let's refactor that. Let's go about this differently." You actually have that time to go do it because if you're at 90% or 100%, it's too late. We're committed to getting us out the door and we just can't do it. So those are the checkpoints that I like to have with the team. So that's a big part of my week too. And then I have a staff meeting with my leadership team. For my staff meeting with my leaders, this is another Stripe-ism I picked up from working with some ex-Stripes. We have what we call, we did this at Retool a lot, snippets, where basically everybody writes down ahead of the meeting kind of three bullet points of things that are top of mind for them. It's not necessarily like what I'm doing this week. It's more like, what is useful for this group of people to know? What should be shared or shared context of things that are important to me? So everybody fills that out ahead of time and then everybody sort of reads it. We often, at the start of the meeting for like five minutes, silently we'll read through it. People add comments. That actually ends up building an interesting agenda of like, "Oh, I didn't realize, but you were working on that thing. I'm also working on that thing. That's interesting. Or I've seen that. Let's talk about that right now." It's a really nice format. It's very quick to do. You can write them in five minutes, you can read them in five minutes. You often find things in there that you would otherwise miss with like a more formal agenda. So I do that and I think that worked quite well. And then I ask my team to... I add things to the agenda beforehand pretty regularly and ask my team to add things to the agenda. And so I'll look at it the night before, see what we've got, kind of structure it, order it, and we'll go through the snippets and go through the agenda. I think that works pretty well. Staff meetings are always tricky. I think the best staff meeting may still be not that great of a meeting, but the problem is if you don't have them, you'll miss a lot. If you do have them, you might have some meetings that don't feel like that useful or that valuable. And I think information sharing, context, discussion points, like discussions you need to have that if you don't get together that you're not forcing them, hard discussions, decision points, those kind of things. So we keep that meeting pretty short in design with the leaders. We were doing it for an hour. I trimmed it to a half hour. That time constraint of just like, "We've got a half hour. Let's use the time efficiently," I think helps a lot.

Brett: What's the most important decision you made in the last year?

Ryan: We talked about this a little bit earlier, but the resourcing decisions of, I think we have more to build than we have team size to do it right now at Rippling is one of the reasons why we're hiring more. But to some extent, you always feel that way. I think Rippling, in particular, wants to run teams that are relatively lean. I think there's a lot of good to that. Designers get to own a lot at Rippling. They, in some cases, will own a company's worth of product themselves, which as a designer is an amazing opportunity. Some companies you go in and you're like, you get this little sliver of thing, right? Rippling, that's never true. You're like, "Congratulations, you own a series C company's products by yourself. Good luck." But it's very challenging too. And so when you're thinking about resourcing in that world of just like, "Wow. Could we get away with one designer on this thing? Is that going to accomplish the business goals? And if not, where do we draw the other resourcing from?" You get a lot of decisions where there are really no good decisions. I mean, recently we had a new product area we're working on that Parker and Matt McGinnis, the CPO, asked me to find a designer to work on. And I sort of laid out the land and I was like, "Okay, this is a challenging problem. It needs this type of designer. Here's the bank of people I think can take this on. Here is what they are all on." And I was like, "All of these things seem incredibly strategically important to the business to me. Some of them are existential, but they're all extremely important." And Matt and Parker, I think both looked at that and went, "Yep, that's a tough decision. Those are all bad options. Good luck." And I think that's the kind of thing where, again, you just have to think through. You have to make a decision, you just have to decide. And then you make the best decision with the information you have and you think through what's going to happen if it goes awry and what your next move is going to be and you just grip it and rip it to some extent.

Brett: What's your take on traditional one-on-ones?

Ryan: I like the idea that one-on-ones, the hot take of one-on-ones shouldn't exist. It's like, "Let's get rid of them." Sort of there's something attractive to that about me. And I think it's because one-on-ones don't always feel like the best use of time. They take up a lot of time, especially if you find yourself carrying a lot of reports, like your span of control gets large at times. If I try to assess one-on-ones critically, I often think about what's my experience with my manager in one-on-ones, what do I get out of them? Do I like them? And then how do I think they think about their one-on-one with me?

Brett: Which I think the original incarnation was this is a vessel for the direct report is the primary consumer of the meeting.

Ryan: Right.

Brett: Although there's some bidirectional sort of dynamic, but I think-

Ryan: I think you're right.

Brett: ... part of the original incarnation was, "This is a thing for the direct report."

Ryan: I think you're right about that. And I think that is my assessment, is like, "That's what they're good at." I don't think they're that useful as a manager for the most part because I think as a leader, I generally try to just... If there's an issue that I need to talk to a report about, I'm like, "I'm just going to find somebody on my calendar, go talk to them about it right away." Matt McGinnis, who I reported to at Rippling, is very good about that. He will feedback lightning fast at you, which I prefer. It's great. Give it to me in the moment, right? So if you have that, then you're like, "Well, okay, I have this vessel to get information I need to you and I need to get it to you. So why do we need this meeting?" Career development stuff, people talk about using them for that. It's like, yeah, that stuff doesn't happen every single week though. And it's probably better to carve out time for that that's dedicated, prepare for it a little bit. So what are you left with? Status reports, I don't think status reports are useful. You can do those async. A lot of that stuff happens in standups and things anyway where managers are around. So it's like, "Can we carve that out?" What's left? I think what's left is like, I got some hard problems and I need to jam on them and I would like you, my manager, to have some time to jam on these things with me. That's where I've seen them work. And I think if in design in particular, if it's me with an IC as opposed to a manager, the most successful use of that time in terms of like how I feel about it and what I've heard from my reports and polling them is actually just using it to go over work, to like jam on ideas, whiteboard, like actually just work together, call it like a jam session and design. That seems to be the highest impact that people really like. And they're like, "You could get rid of everything else. Just give me that. It's just protected time with someone who's going to give you hopefully good quality feedback, exchange ideas, brainstorm." With managers, it's kind of the same thing, but it's often like, "I'm having a problem with my team" or like, "I'm working on this person" or "I'm trying to make a hiring decision" or "I have a cross-functional dependency that's not going well. How should I navigate this?" That stuff and be like, "Okay, yeah, you know what? I don't know, but let's sit down and figure it out together."

Brett: How do you scale judgment?

Ryan: Rigor in thinking is something that can be taught. How do you break down a problem? Think through all the constituent parts, discover parts you might not know about, discover the known, unknowns. There's a lot of different ways to teach it. It's taught formal logic. I think designers don't tend to learn this stuff in formal education, but I think you can... Judgment as a factor of rigorous thinking, those two things can often be combined a lot. It's like you can make judgments pretty easily and in a repeatable manner if you have the right information and you thought through things. When you're trying to scale judgment, there's like tools you can give people that actually get you pretty far. And if you give those tools to people, whether they're just like frameworks on how to think or literal tools, that goes a long way. But I don't know if this is a question behind your question, but a question I get a lot is, how do you as a design leader scale quality and do it in a way that's repeatable? Because it's like, "I don't know. We've got this big company and we have quality problems everywhere. I don't know. And I look at this other company and their product's pretty good. It seems like it's pretty good." I'm like, "How did they do it? We can't figure it out." And this is like a process power thing, but I think that stuff, the only way I've seen it done truly consistently when you're talking about quality, which again, I think you can define and you can get specific about, you can be like, "Are we talking about system reliability? Are we talking about performance? What type of performance? Are we talking about usability? In usability, are we talking about learnability of the system or error rate?" You can get to that specificity that helps, but at some point it's still a little intangible. What makes you like, "I don't know. The products just seem great. I can't put my finger on it." I think benevolent dictatorship is the only answer. And I think you see that in most... I mean, I don't know, Ivan at Notion, Steve Jobs at Apple, Brian at Airbnb, these places where you're like, "Yeah, they have a design leader at the top and they clearly have a strong opinion and they kind of review all the work and they say what goes and doesn't go." And so my answer to your question in that form is like you don't. I think you don't ultimately. The real answer is I think there's a lot you can do to spread the ability to build better products across an org. But I think to get to the highest point on the mountain, you probably need the opinionated, tasteful, benevolent dictator.

Brett: There's a lot of judgment calls that you take two competent people, you take you and another designer and you give them a problem and they would make the call differently. But in the context of what you're trying to do in this case of Rippling or Retool, it seems that a lot of these calls seem subjective, but there is much more of a correct call in the context of what you're trying to do at Rippling. Is a lot of that an incredible amount of just explaining everything that's going on in the business? And that's similar to sort of an LLM, if a person doesn't have appropriate context on everything that's going on, they can't make the highest quality judgment call?

Ryan: Yes. Yes. I would agree with that statement. I think you see Matt McGinnis calls it low guy, locally, optimized, globally incoherent. You see people making what seem like the right judgments with the information they have at hand. They're like, "I'm looking here at this corner of the product, this world, this domain. We think this is what's right for customers." And if you just looked at that, you'd be like, "That's a reasonable decision. You've backed up your decision with some pretty good reasonings and pretty good inputs." But then as soon as you look up and across, you go, "Well, wait a minute, but we do that this way over here and we do it this way over here." And the reason we do it differently over here is because there's slightly different inputs. And how do you get the teams to see that stuff, right? It's like they can't be looking up and across all day long, but at the same time, it's like you do need them to be able to do some of this. You can't just only do it from altitude or sharing across.

Brett: If a friend of yours is the CEO and calls a 500-person startup that's rapidly scaling and they're hiring their first design leader or VP of design or chief design officer, what have you, executive level role, and they're saying, "Well, what should I be looking for? What's really, really important to get right?" What's sort of your answer to that?

Ryan: As a good designer, my answer is usually more questions, inquiry versus advocacy. It's like, "Well, tell me more about your business and what you're building and what do you think about design and who are-"

Brett: And they're like, "No, no, please. Just give the answer."

Ryan: ... "who are the designers?' Yeah. And they're like, "I don't have time for that, [inaudible 00:51:20] Just tell me what to hire. Give me the checklist." You can either find people who are maybe interested in scaling down a little bit or people who are interested in scaling up, which is to say leaders who have maybe worked for bigger orgs quite often go, "Wow, I miss the days when we were smaller, or I missed the days when I worked for a smaller company. I could be closer to the work, I could get more done faster, I could make bigger changes. I would like to sort of go back to that mode of operation." If they've done it before and then they've also done a larger scale company, that's a really nice sweet spot for a leader because you're like, "This isn't going to be unfamiliar to you, but I know you can grow. I know you're going to get us from here to multiple steps in the future." I think a lot of what happens inside of companies, typically with the first design leaders, it might be the best designer or it might be the founding designer and they scale until all of a sudden they're either like, "I don't like this anymore" or "I'm past my limits," and then you're like, "We need to do something here." And you can either try to... Leadership teams change over as you grow a company, they just do. And you have to asked the question of like, "Is this your next two-year hire? And you feel good about that?" If you brought in a leader and they got you from here to two years from now, and that was their time, would you feel like that's success? Because if so, you can take our risk on somebody who maybe has a little bit less experience. Y-intercept's not as high, slope's high, they're excited to do it, their motivation will be high, engine will be massive. They'll give you the hours that you want at this stage. The skills that you're looking for from them are obviously like some experience in management, aptitude of coming up out of the work, being able to scale themselves a little bit. They can hire. They have a network. They know the basics blocking and tackling of basic operational stuff. They're not going to be ignoring it or overwhelmed by it. They don't have to be the absolute best at it because if you're at that size, your org's probably not that big. You're making a handful of hires instead of making 50 hires, right? You can get away with more. But if you want them to keep scaling, it's just a higher risk that they won't. Sometimes they can.

Brett: And the benefit of experience is just, it's a shortcut for everything or they're more likely to be correct or...

Ryan: Bigger networks, faster to hire, seeing more stuff, seeing more reps, more pattern matchings, faster, ability to do... You've hired before, you understand you need to create a ladder, you need to create a loop. You probably have those things already. And you'll adjust it for our business, but you're not starting from scratch, right? The things that I always say with leaders is there's the leaders who can be hands-on that you sort of trust in their taste and their craftsmanship and their ability. You would not be afraid for them to jump in and do some of the work. And then there's the leaders where you're like, "It's been 10 years since they've clearly touched any work. You probably don't want to hire one of those." And there's a bunch of them in the space, bad people, they're just at a point in their career where they've been in a different world. I would definitely tell the startup founder, stay away from that. But also be careful not to over-index on the people who are going to have the same thing I told you earlier, which is they're going to not be able to extract themselves out and operate a little bit of altitude when you need it.

Brett: What about sort of the flip side of the question, which is it's a 25-year-old designer, they are a star, they work with you in an X number of years, they want your job?

Ryan: They can have it.

Brett: There's this funny thing when you talk to people who have been building functions for a long period of time where they want to amass the largest possible team. And then as they get later and later in their career, they want to have the smallest possible team.

Ryan: Yeah.

Brett: It's a funny dynamic.

Ryan: It is.

Brett: But for that person that's a few years in, you've touched on this in a few different ways, but what are the things they should be doing in the short term to sort of set themselves up to start to compound and sort of grow into your role?

Ryan: One of the things that I consistently look for in people is that they have an opinion, and it can be an opinion about anything really, but I'm like, "I want to know what you believe in strongly. I want to know what you believe in strongly and are probably wrong about. I want to know what you will go to Matt for" because that tells me a lot about what's important to them and their motivations, and it's going to connect in how they think about our product and what we're building in our business. What I see often is a sort of lack of that stuff. I'm like, "Why do you want to work here? Why do you care about this product? What opinions do you have on our product as it exists right now? Where do you think it should go? Show me some taste. Show me some opinion." That stuff is really important for a leader. I think you can get away with being an IC without having a ton of that because you're just like, "No, it's fine. Here's my world and I sort of have a set of tasks and I do a pretty good job and make a decent set of decisions in there. But you know, a lot of this stuff is just kind of handed to me." For leaders, I'm like, "This stuff's not going to be handed to you. You have to have opinions. You have to be able to go to the mat and fight for things. If you think the product should be doing something or we should be playing somewhere that we're not, who is going to make that happen if not you?" Design has this amazing ability to take ambiguous, intangible ideas and make them real. If there's one thing that designers can do that's maybe... I think this is changing now, but that other functions have a harder time doing, it's like we can make the artifacts to make ideas real, right? And whether that's prototypes or demos or narratives, slide decks presentations, blue sky thinking, dream decks, whatever, and you can see a company just rally around that stuff instantly. And an idea that's been around, people are kind of thinking about or they're arguing about, as soon as there's an artifact, people are like, "Oh, right." And everyone anchors on that. They might be like, "No, that's not it." Or they might be like, "Oh my gosh, that's amazing. How do we get there?" But it just locks everyone in to a much richer, higher bandwidth conversation. And if you can't do that, if you can't sort of see the playing field, grasp the things that are in the air, talk to others, form an opinion about what this product should be doing, strategically where it should be playing, where the opportunities are, where design can be in a lever and an accelerant for a business, you're not going to be able to produce those things in a way that's going to get the business moving. What I want to see in a 25-year-old is that you have the instinct to be able to do that. You might be able to do that fully or across the whole business, but that you see those opportunities and you come out of your lane and you make things happen. The best designers, you see them do that. You're like, "Wow, I wasn't even thinking this would be something you did, but you saw a problem and you steered the business. You moved the tiller." Man, when you see that, you're like, "Kids are all right, you're going to be okay." Most people tend to want to stay in their lane, and I think you need to see people come out of it to be a leader. And you see that quite early, but it's something I select for in leaders and I select for one of the most senior ICs. The absence of it is, to me, usually not a good signal. It's like, "I'd much rather you have very upsetting opinions that I don't agree with, but you have them."

Brett: What do you want your team to say about you? Like when they're talking to their friends about their boss or the person running the function, what's the thing you aspire for them to say about you?

Ryan: Maybe a few things. I think I want them to feel like they are doing truly great work and that I sort of put the environment in place for them to do that. I think my management style is generally demanding but supportive. I think that was Robbie Gupta, right? People can't do great work unless you push them. You have to push people. You have to put people in a position of being somewhat uncomfortable. I want to build an environment where it is true, so people are like, "Yeah, Ryan pushes us. He pushes hard on. It's not always comfortable, but I see that the work is better. The work that I've done here is so much better for it, and I want that." And I want it to be backed up too by feeling like the feedback I'm giving them is really substantive, which is to say it's informed. It's not just feedback of me being like, "Yeah, I mean, here's some graphic design fundamentals. Make that type smaller. That green doesn't look right," but it's really informed about the domain they're working on, it's high quality feedback, and they feel like I'm in it with them. And then the supportive piece is good design, good creative work of any kind. I mean, engineering design, it doesn't come from fear. You can't be in a fear state and make good work because when you're in a fear state, your limbic system activates and your prefrontal cortex shuts down and your executive function shuts down, and that's where all of your creative thinking is. And so if the stakes are really high and you're constantly pushing on people and you have them in that fight or flight or reactive mode, it's actually going to shut down good creative work. And it's a really hard balance to both push people, but keep them out of that zone, keep them in a zone where they feel like they do have the space to experiment and try and fail and their support in doing that, that's the balance I want to create in a design org. I don't know how people say that in few words, but basically I want people to feel both that like, "Wow, I really got pushed hard to do good work and I feel like I learned a lot and my work came out better from the other side of it. And I felt even though it was hard and day to day was challenging and it was often uncomfortable, I ultimately really felt supported, like the function and Ryan and my managers had my back. So even though there were bad days and overall, I really feel like I came out a better designer." That's kind of the whole thing for me.

Brett: And so how do you know if you're being demanding enough and how do you know if you're being supportive enough?

Ryan: I mean, I think about this all the time. I think my managers do too, just like sometimes you come out of meetings and you're like, "I should have leaned in a little bit more. I'm not sure I drove the feedback as hard." And then sometimes you come out of meetings and you're like, "Whoa, I really clearly overwhelm the designer here with this feedback." I think that's a case where it's a little bit easier because if you lean in hard on a designer, you give them really tough feedback, you can usually kind of read it where it's like, "Uh-oh, I overflowed their buffer a little bit." It's a little bit more than they're maybe capable of handling and acting on." You can then go, "Hey, let's schedule some more time. Let's sit down. Let's go through this together." The generative AI tooling is great because it's like now I can be like, "Ooh, I can spend 15 minutes and I can actually whip something together much faster. I don't have a lot of time, but I can now start to speak in artifacts to you, which is more helpful." But you can walk them through it. You can help them break it down. So that one's more salvageable. The inverse is less salvageable where you're like, you maybe didn't lean in as hard, the work continues, they don't make the changes that maybe you thought you communicated or you were hoping they were going to make and then you find yourself further down the road and you're like, "Whoa, this product's not ready." That's actually, I think, worse. So I tend to try to bias towards more harder feedback, which is to say overflowing the buffer a little bit versus pulling the punch. But time is a constraint on this stuff. I don't get to always go to every single crit or see all work. Sometimes even you're looking at three projects and you're like, "I got more to say, but I got to go to the next one" and you sort of lose it. So I mean, I think about this a lot. Part of the reason why I have that Friday time is just that there is a space where it's just me and I'm going to see that work. And that's where I really try to fully lean in on stuff to make sure I'm like, "Okay, this one, I don't want it to go past here until I can really push on it." I think that's it. I think a lot of companies maybe pulled back from this stuff over the years. I see companies leaning into this more now. It's like the culture's changing a little bit around it.

Brett: What is working at Parker's company sort of taught you or net new ideas that are important to the way that you think about running or scaling a business?

Ryan: I think that Rippling, the way that Rippling operates challenges a lot of people, like you see leaders come in and I think this was true for me. And the way it operates is just often very different than the way other companies operate. Some things you might think are good practice might not be in place. Specifically for me, it was like, I'm used to EPD teams being like really, really tightly integrated. There were a bunch of places where I was like, "Oh, they're a little bit siloed." It's a little bit more waterfally, and I'm like, "That seems crazy. How's anything getting done?" And then you really have to question your priors, I think, because if you look at Rippling and the amount of work that it's done, the amount of things it shipped, how successful the business has been, you're like, "Clearly this is working." And so that's been sort of my experience of just all these little places where I'm like, "This is how we should communicate with R&D org." And I'd be like, "Oh, we don't do it that way, or we communicate less frequently." Or, "I don't speak as a design leader in front of the org as much or things that I think are important." But then I go, "Actually, I think it's totally fine." There's many things like that where I've really been sort of forced to suspend my disbelief, and it's helped me understand what's unique about the opera. It's called the Rippling operating system a lot. What is Rippling operating system? What I really love is, and the thing I will take with me, is just absolute sheer, amazing speed of execution. I mean, just like the gas pedal is just meshed all the time. And normally you think that it's a little scary as a design leader, but I think it's really great. I mean, it's like the amount of stuff that gets done when you really press on people on like, "You can do more, like what's possible." It's amazing what people can get done more than they think. I think Rippling and Parker are very good at getting that out of people. It's been awesome to see. It's made me think a lot about how I do that. And that sort of overlaps with this idea of pressing on people and demanding. And I see the company's really good at that. Another thing is commitments. The company talks about commitments a lot. There's this concept of MMDDs, which just basically are a Rippling deadline. Parker wants a date next to everything. And the idea is like, it's not that that date is sacrosanct per se. It's that like in the absence of a date, there really is not a commitment, and that express commitment is what matters. And if you commit to the thing, you need to follow up on that commitment as any team member. And if you're going to miss that date, that is okay, but you better, A, have a good reason and good rational, rigorous reason, things you learned, things that changed. And then hopefully you are smart about it, which is to say when you see that coming, you renegotiate that date with a lot of room as commitments to other people because there's a lot of dependencies. It's very hard to do in practice. I think it's incredibly important. And I think the rigor around commitments to other teams is like in a business that's doing as many things as Rippling is so critical. And I really like that aspect. And I think Matt McGinnis is really smart about how he runs the team in this regard and how he asked for it and Parker as well. And that's a big thing that I will sort of take away. Man, you can get a lot of stuff done really fast into pretty good effect, and a lot of it is about how you get a lot of people working on a lot of different stuff at the same time to work in concert and orchestration. And I've taken away quite a bit on that front.

Brett: Good place to end. Thank you.

Ryan: Yeah, thank you.

Brett: I really appreciate it.

Ryan: Yeah, that's great.