Season 4

|

Episode 5

Creating a culture of craft

Derek Briggs

Director of Design @ Clerk

Jan 18, 2024

Jan 18, 2024

|

42 min

42 min

music by Dennis

About this Episode

There’s a new design super team emerging at Clerk and in this episode we get a behind-the-scenes from the leader, Derek Briggs. We get into the weeds about:

  • How Derek assembled an A-list team from scratch

  • Why Derek pushed for a dedicated UI engineering team

  • How Clerk is approaching their massive redesign

  • Why Derek doesn’t believe in design deadlines

  • The business case for prioritizing quality

  • Derek’s #1 piece of advice for younger designers

    a lot more

Share on Twitter
Share on Twitter
Share on LinkedIn
Share on LinkedIn

Deep Dives

Get our weekly breakdowns

Insights + resources from top designers 👇

Lauren LoPrete

Director of Design Systems @ Cash App

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

James McDonald

Designer @ Clerk

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

HC

Deep Dives

Get our weekly breakdowns

Free lessons from 👇

Lauren LoPrete

Lead designer @ Netflix

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

Deep Dives

Get our weekly breakdowns

Insights + resources from top designers 👇

Lauren LoPrete

Director of Design Systems @ Cash App

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

James McDonald

Designer @ Clerk

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

HC

Transcript chapters

How Derek landed the role

Derek: The opportunity came with Clerk when Jeff Escalante, the Director of Engineering, followed me on Twitter, I had seen a lot from Clerk floating around, pretty much every stack you see that people are sharing of what they're building on has Clerk in it, and it really, like, intrigued me of, of why, like, what is it?

Because in all the other former opportunities that I've worked with, we started with Auth0, couldn't get it to look like what we wanted it to look like. , and tore it out or started hand rolling our own, but for some reason, there was this clerk that kept floating around for authentication. Like, why, why is everybody using this?

And it made me very interested. And like, what was it about and what was making it so great? So, again, Jeff followed me, uh, reached out to him, said, Hey, in doing cool stuff. , let me know if you want any support, , because I was doing a contract with tailwind at that time and wrapping that up and thinking about kind of what's next.

And pretty quickly, he's like, yeah, let's talk. So it was probably that day, that, we jumped on a call and talked about their needs and what they're working on. What they were wanting was design support for what the future of their components were going to look like, because they're known for their 1 liner components that you just get all the power out of the box.

It was exciting to work on. We, we figured out, you know, kind of what the scope of that project was to, to start prototyping and kind of envisioning what the next versions of those components we're going to look like, work closely with him and Braden, the, the co founder there and really enjoyed every interaction that I had with them.

They always had time for me. They're always available. great feedback, lots of trust, lots of autonomy. what designer doesn't want that? Getting towards the middle to later part of the engagement is when conversations started to surface from them of like, hey. Do you want to come do this full time?

No, like, I'm really enjoying the time of contracting and kind of being independent right now. and they kind of okay with that. And then the following week, then it'd be the other person that would reach out and say, hey. would you think about this? Maybe like, we have projects that are coming in the pipeline and we're starting to say things like.

What if Derek did that for us? What if Derek did that for us? and still I was like, no, I appreciate it. Like I really like working with you guys Maybe we can keep contracting but just not something that that i'm interested in right now And then I think it was the following week that they kind of both got on a call with me and they were like, hey Let us put an offer in your inbox.

We really want you to come like take on this team i've pretty clear expectations on autonomy trust Independence Here in Colorado, there's, you know, snowboarding, mountain biking, hiking. There's just so much to do during the day that I don't want to have to be focused on work all the time.

And then being independent, being able to control my own schedule. I was very clear that that's something important to me, and they made it very clear that that's not going to be something that's a problem for them. So, , they just kind of answered all the questions correctly and. Continued to make me think, like, what if what if, but they wanted me to run the team.

And that's something that was not really on my mind. I'm a shipper. I just want to ship and to be in charge of other people shipping wasn't the thing on my mind they just kind of kept pushing me and I appreciate now that they were challenging that less refined skill set of mine that I've worked for great leaders and been inspired with great leaders. Notably, like, Mike Kudermarsch at PlanetScale, , if you ever have the opportunity to work for him, , you learn a lot about how you work and how, like, elite teams work, , and, like, Brian Loven, he's a robot, and, like, if you want a lesson in shipping software, you work with Brian and Ryan, like, those guys over there just ship, ship, ship, ship, ship.

At an incredible velocity and it's extremely inspiring. So just being inspired by those like industry leaders that are just so good at what they do and learning from them has definitely allowed me to learn from their leadership skill sets and apply those to a team. So, the offer came through, , as at that time, as a head of design role, and they promised that they would help with the people management stuff, things like that. And I started talking to some of the folks that I use as mentors, former peers, former bosses, and every 1 of them are like, oh, yeah, like, I would work for you.

I would work for you. Like, you would be an incredible leader. So, just more of that, like, thinking about it at night, like, what if, what if I did just take on this team? And I decided to. It was quite a jump, but it was definitely with the understanding that I still need to play an IC role.

And I kind of made that happen for myself of I'm not going to let this job just be managing people and tasks. That I'm going to be pushing a bunch of code and doing a bunch of design, because I'm so passionate about it, and I care so much about the output and being a part of the output with the team and influencing the other designers and engineers on the team.

It's a really special position to be in to, to influence the direction from a leadership perspective, and then all the way down to pushing code right with everybody else.

How Derek landed the role

Derek: The opportunity came with Clerk when Jeff Escalante, the Director of Engineering, followed me on Twitter, I had seen a lot from Clerk floating around, pretty much every stack you see that people are sharing of what they're building on has Clerk in it, and it really, like, intrigued me of, of why, like, what is it?

Because in all the other former opportunities that I've worked with, we started with Auth0, couldn't get it to look like what we wanted it to look like. , and tore it out or started hand rolling our own, but for some reason, there was this clerk that kept floating around for authentication. Like, why, why is everybody using this?

And it made me very interested. And like, what was it about and what was making it so great? So, again, Jeff followed me, uh, reached out to him, said, Hey, in doing cool stuff. , let me know if you want any support, , because I was doing a contract with tailwind at that time and wrapping that up and thinking about kind of what's next.

And pretty quickly, he's like, yeah, let's talk. So it was probably that day, that, we jumped on a call and talked about their needs and what they're working on. What they were wanting was design support for what the future of their components were going to look like, because they're known for their 1 liner components that you just get all the power out of the box.

It was exciting to work on. We, we figured out, you know, kind of what the scope of that project was to, to start prototyping and kind of envisioning what the next versions of those components we're going to look like, work closely with him and Braden, the, the co founder there and really enjoyed every interaction that I had with them.

They always had time for me. They're always available. great feedback, lots of trust, lots of autonomy. what designer doesn't want that? Getting towards the middle to later part of the engagement is when conversations started to surface from them of like, hey. Do you want to come do this full time?

No, like, I'm really enjoying the time of contracting and kind of being independent right now. and they kind of okay with that. And then the following week, then it'd be the other person that would reach out and say, hey. would you think about this? Maybe like, we have projects that are coming in the pipeline and we're starting to say things like.

What if Derek did that for us? What if Derek did that for us? and still I was like, no, I appreciate it. Like I really like working with you guys Maybe we can keep contracting but just not something that that i'm interested in right now And then I think it was the following week that they kind of both got on a call with me and they were like, hey Let us put an offer in your inbox.

We really want you to come like take on this team i've pretty clear expectations on autonomy trust Independence Here in Colorado, there's, you know, snowboarding, mountain biking, hiking. There's just so much to do during the day that I don't want to have to be focused on work all the time.

And then being independent, being able to control my own schedule. I was very clear that that's something important to me, and they made it very clear that that's not going to be something that's a problem for them. So, , they just kind of answered all the questions correctly and. Continued to make me think, like, what if what if, but they wanted me to run the team.

And that's something that was not really on my mind. I'm a shipper. I just want to ship and to be in charge of other people shipping wasn't the thing on my mind they just kind of kept pushing me and I appreciate now that they were challenging that less refined skill set of mine that I've worked for great leaders and been inspired with great leaders. Notably, like, Mike Kudermarsch at PlanetScale, , if you ever have the opportunity to work for him, , you learn a lot about how you work and how, like, elite teams work, , and, like, Brian Loven, he's a robot, and, like, if you want a lesson in shipping software, you work with Brian and Ryan, like, those guys over there just ship, ship, ship, ship, ship.

At an incredible velocity and it's extremely inspiring. So just being inspired by those like industry leaders that are just so good at what they do and learning from them has definitely allowed me to learn from their leadership skill sets and apply those to a team. So, the offer came through, , as at that time, as a head of design role, and they promised that they would help with the people management stuff, things like that. And I started talking to some of the folks that I use as mentors, former peers, former bosses, and every 1 of them are like, oh, yeah, like, I would work for you.

I would work for you. Like, you would be an incredible leader. So, just more of that, like, thinking about it at night, like, what if, what if I did just take on this team? And I decided to. It was quite a jump, but it was definitely with the understanding that I still need to play an IC role.

And I kind of made that happen for myself of I'm not going to let this job just be managing people and tasks. That I'm going to be pushing a bunch of code and doing a bunch of design, because I'm so passionate about it, and I care so much about the output and being a part of the output with the team and influencing the other designers and engineers on the team.

It's a really special position to be in to, to influence the direction from a leadership perspective, and then all the way down to pushing code right with everybody else.

How Derek hired a team

Ridd: They talk about how the most important part of your job as a design leader is hiring the right people. And I think it's pretty safe to say that you got off to a hot start because the way that I heard about clerk was from a tweet from James McDonald saying that he was joining full time. And I remember thinking like, what the heck, like, what is clerk and how the heck did they land James?

So can you tell us that story? Like when did James come into the picture and how did you convince him to join clerk?

Derek: So James and I have been acquaintances on Twitter for probably the past year, six months ish, something like that. When the tailwind opportunity came to join them for a couple months to work on some stuff that they're going to be shipping here, , in the near future. We just had a lot of fun working together and kind of unlocking each other's abilities of just creating really great. Pixels and it was apparent that we were having a lot of fun and that our expectations aligned so probably a month after he left Tailwind, then I'm in his inbox again, like, hey, here's this opportunity that I'm considering, it'll be a fresh start for the team. You have this company who has this incredible technology, who is just loved so much by the industry, but are now investing in design.

They want me to take on this team and build a team. Come do this with me. We get to do it the way that we want to do it, make it as, as amazing as we want to make it. No one's going to influence this but you. Trust, autonomy is the theme, and no egos. , and then another part of that too is, with Clerc, I told them that we have to have a UI engineering team.

If you're going to bring the level of talent that I expect on this team, you have to have folks to be able to write the code. Otherwise, the designs are only ever going to be that good in Figma. And surprisingly, it was pretty easy after that to hear him say, like, yep, sounds good. I'm doing it. we work on stuff together, we're on opposite time zones almost, so it's a lot of him doing design, handing it over to me, then I'll add to it, duplicate the artboards, do some stuff, maybe it'll show up in the next iteration, maybe it won't, and just kind of inspire each other along the way in the same Figma file.

Get to somewhere that we're really stoked about, so. Yeah, pretty awesome opportunity to have the quality like James on the team. , but the team is as good as James because James is around, um, but also that James is as good because of the team supporting him.

Ridd: Let's talk a little bit more about the team then, because I've also seen Alvish on Twitter now, and he's been sharing a lot of Cleric work in progress. The quality looks really incredible. So maybe even at a high level, and you can talk about Alvish or future hires even, like what are the traits that you look for in designers and the way that they work that you think will be a good fit for this culture of craft that you're trying to establish at Cleric?

Derek: Alvis came up from James actually, he knew that we were going to grow the team and needed more visual design support. Especially on the product side, because we're coming in to a company that has a foundation and we're going to redo it all, we're going to reface all of the product offering.

So we got to do website. We got to do the docs. We have to do blog. We have to do the change log was a fun little few day project that we worked on and shipped really quickly. , just kind of a team thing that we thought we'd have fun with. , and then the dashboard as well. So that's going to involve product design.

I'm not going to approach a dashboard and just make it look pretty. Like we're going to think about the IA so, of course, there's going to be a lot of product design along with visual design there and James had proposed reaching out to Alvish.

I had followed him on dribble for a while. I'd seen a lot of his stuff. He's super talented visual designer. I reached out to him and said, hey, James, and I think it'd be really awesome to work with you. Would you consider doing some contract work with us and things like that? And right away, he's like, it would be an honor.

Like, absolutely. I would love to do that. So, we hopped on a call, met him, , I gave him a small task to do as kind of an evaluation, , and the next day, he turns around these designs for a dashboard page. I asked him to do part of the dashboard. The next day, morning, pretty much, he turns around these, like, multiple options, Figma prototypes.

Of what the dashboard could look like. And I handed over to Kyle McDonald, our director of product. And both of us are just like, this dude is, is an AI bot. We give them a prompt and he just spits out ideas, really good ideas, really fast.

And now that he's been with us for a couple of months, it still holds true. Today, I was talking with one of our directors of engineering. He's just like, he's so fast. Like he just comes up with good ideas so quickly and we're so lucky to have him. , It was funny, one of the first conversations I had with him, I was talking about some buttons that he had designed, like four sets of buttons, and I'm like, these are just really well done.

Like, the lighting around them, the subtle gradients, the subtle borders to highlight the edges, like, there's just a lot of that attention to detail that I really care about. And he's like, yeah, I did those because of your Twitter thread on how to do buttons

Ridd: was about to say that I have that Twitter thread saved.

Derek: Yeah.

Ridd: That's awesome. That was awesome.

Derek: It was humbling to hear that, yeah.

Ridd: Yeah. I'm gonna have to put that in the show notes. I read that at least three times. Like it is directly informed the way that I designed buttons.

Derek: It's

Ridd: you've you've said a few like really interesting things so far that I kind of want to like zoom out for a second.

You talked about. Basically having UI engineers, dedicated UI engineers as a requirement, you've mentioned, you know, like even just like the fine details on these buttons, this pitch to reskin literally everything, like a large visual refresh. And I've seen the work I've seen the work on Twitter. It's really clear.

How Derek hired a team

Ridd: They talk about how the most important part of your job as a design leader is hiring the right people. And I think it's pretty safe to say that you got off to a hot start because the way that I heard about clerk was from a tweet from James McDonald saying that he was joining full time. And I remember thinking like, what the heck, like, what is clerk and how the heck did they land James?

So can you tell us that story? Like when did James come into the picture and how did you convince him to join clerk?

Derek: So James and I have been acquaintances on Twitter for probably the past year, six months ish, something like that. When the tailwind opportunity came to join them for a couple months to work on some stuff that they're going to be shipping here, , in the near future. We just had a lot of fun working together and kind of unlocking each other's abilities of just creating really great. Pixels and it was apparent that we were having a lot of fun and that our expectations aligned so probably a month after he left Tailwind, then I'm in his inbox again, like, hey, here's this opportunity that I'm considering, it'll be a fresh start for the team. You have this company who has this incredible technology, who is just loved so much by the industry, but are now investing in design.

They want me to take on this team and build a team. Come do this with me. We get to do it the way that we want to do it, make it as, as amazing as we want to make it. No one's going to influence this but you. Trust, autonomy is the theme, and no egos. , and then another part of that too is, with Clerc, I told them that we have to have a UI engineering team.

If you're going to bring the level of talent that I expect on this team, you have to have folks to be able to write the code. Otherwise, the designs are only ever going to be that good in Figma. And surprisingly, it was pretty easy after that to hear him say, like, yep, sounds good. I'm doing it. we work on stuff together, we're on opposite time zones almost, so it's a lot of him doing design, handing it over to me, then I'll add to it, duplicate the artboards, do some stuff, maybe it'll show up in the next iteration, maybe it won't, and just kind of inspire each other along the way in the same Figma file.

Get to somewhere that we're really stoked about, so. Yeah, pretty awesome opportunity to have the quality like James on the team. , but the team is as good as James because James is around, um, but also that James is as good because of the team supporting him.

Ridd: Let's talk a little bit more about the team then, because I've also seen Alvish on Twitter now, and he's been sharing a lot of Cleric work in progress. The quality looks really incredible. So maybe even at a high level, and you can talk about Alvish or future hires even, like what are the traits that you look for in designers and the way that they work that you think will be a good fit for this culture of craft that you're trying to establish at Cleric?

Derek: Alvis came up from James actually, he knew that we were going to grow the team and needed more visual design support. Especially on the product side, because we're coming in to a company that has a foundation and we're going to redo it all, we're going to reface all of the product offering.

So we got to do website. We got to do the docs. We have to do blog. We have to do the change log was a fun little few day project that we worked on and shipped really quickly. , just kind of a team thing that we thought we'd have fun with. , and then the dashboard as well. So that's going to involve product design.

I'm not going to approach a dashboard and just make it look pretty. Like we're going to think about the IA so, of course, there's going to be a lot of product design along with visual design there and James had proposed reaching out to Alvish.

I had followed him on dribble for a while. I'd seen a lot of his stuff. He's super talented visual designer. I reached out to him and said, hey, James, and I think it'd be really awesome to work with you. Would you consider doing some contract work with us and things like that? And right away, he's like, it would be an honor.

Like, absolutely. I would love to do that. So, we hopped on a call, met him, , I gave him a small task to do as kind of an evaluation, , and the next day, he turns around these designs for a dashboard page. I asked him to do part of the dashboard. The next day, morning, pretty much, he turns around these, like, multiple options, Figma prototypes.

Of what the dashboard could look like. And I handed over to Kyle McDonald, our director of product. And both of us are just like, this dude is, is an AI bot. We give them a prompt and he just spits out ideas, really good ideas, really fast.

And now that he's been with us for a couple of months, it still holds true. Today, I was talking with one of our directors of engineering. He's just like, he's so fast. Like he just comes up with good ideas so quickly and we're so lucky to have him. , It was funny, one of the first conversations I had with him, I was talking about some buttons that he had designed, like four sets of buttons, and I'm like, these are just really well done.

Like, the lighting around them, the subtle gradients, the subtle borders to highlight the edges, like, there's just a lot of that attention to detail that I really care about. And he's like, yeah, I did those because of your Twitter thread on how to do buttons

Ridd: was about to say that I have that Twitter thread saved.

Derek: Yeah.

Ridd: That's awesome. That was awesome.

Derek: It was humbling to hear that, yeah.

Ridd: Yeah. I'm gonna have to put that in the show notes. I read that at least three times. Like it is directly informed the way that I designed buttons.

Derek: It's

Ridd: you've you've said a few like really interesting things so far that I kind of want to like zoom out for a second.

You talked about. Basically having UI engineers, dedicated UI engineers as a requirement, you've mentioned, you know, like even just like the fine details on these buttons, this pitch to reskin literally everything, like a large visual refresh. And I've seen the work I've seen the work on Twitter. It's really clear.

Why Clerk is investing heavily into craft

Ridd: Like you're investing a lot into the quality of the clerk interfaces right now. And I'd like to talk a little bit about the strategy behind that. Like, why do you think that this level of craft makes sense for clerk?

Derek: The engineering that they have, and the magic that comes with the engineering of the authentication flows, the user management, the session management, , all the OAuth providers, , we just released custom roles, like, there's just so much great engineering involved in there. And it was very clear that, The design had so much opportunity to improve along with that.

So that the value of the engineering that's invested into clerk and clerks offering, equals to the design investment in the product as well. That was an exciting part of wanting to join. Clerk was seeing the opportunity there. I am not interested in joining a company where a lot of decisions have already been made and it's pretty well thought out smooth sailing.

I was so excited and continue to be excited about the massive amount of work that we have to do. And, , with Colin and Braden, the co founders of clerk. , really caring a lot about the investment in the design moving forward and, , leveraging the design talent that we have to improve the dashboard experience and the DX and , the website and the visual presence of clerk out on the Internet.

And just kind of redefining what clerk. Is in the industry to align with other dev tools, like the linears and the planet scales and just these really polished brands, that we look at and, you know, extremely impressed with. So, I'm really excited that their priorities have shifted towards, you know, what would design do with this a side effect of that that I didn't really.

For C was with my engineering skill set as well front end, uh, specifically being able to influence engineering initiatives and bringing up ideas moving the needle on not only what it looks like, but the D X as well, because I care so much about it.

Yeah.

Why Clerk is investing heavily into craft

Ridd: Like you're investing a lot into the quality of the clerk interfaces right now. And I'd like to talk a little bit about the strategy behind that. Like, why do you think that this level of craft makes sense for clerk?

Derek: The engineering that they have, and the magic that comes with the engineering of the authentication flows, the user management, the session management, , all the OAuth providers, , we just released custom roles, like, there's just so much great engineering involved in there. And it was very clear that, The design had so much opportunity to improve along with that.

So that the value of the engineering that's invested into clerk and clerks offering, equals to the design investment in the product as well. That was an exciting part of wanting to join. Clerk was seeing the opportunity there. I am not interested in joining a company where a lot of decisions have already been made and it's pretty well thought out smooth sailing.

I was so excited and continue to be excited about the massive amount of work that we have to do. And, , with Colin and Braden, the co founders of clerk. , really caring a lot about the investment in the design moving forward and, , leveraging the design talent that we have to improve the dashboard experience and the DX and , the website and the visual presence of clerk out on the Internet.

And just kind of redefining what clerk. Is in the industry to align with other dev tools, like the linears and the planet scales and just these really polished brands, that we look at and, you know, extremely impressed with. So, I'm really excited that their priorities have shifted towards, you know, what would design do with this a side effect of that that I didn't really.

For C was with my engineering skill set as well front end, uh, specifically being able to influence engineering initiatives and bringing up ideas moving the needle on not only what it looks like, but the D X as well, because I care so much about it.

Yeah.

The case for dedicated UI Engineers

Ridd: And I do want to talk about your engineering background because I do think it's like a little bit atypical to have a design leader. Sometimes it's like the head of the org is in the weeds of the code. How do you think that impacts the way that the design team works and the type of culture that you're trying to create even?

Derek: I feel like. I'm uniquely qualified to support a team from a design and UI specific engineering perspective because that's something that I've been really passionate about in my own career for many years now, of not only refining my design skill sets, but also the front end engineering skill sets.

UI engineer and watch them level each other up. I say all the time that the users never see the Figma files, like your design quality and your design capabilities of your team is only as good as the UI engineers that are implementing it.

And that is a good, like, case for velocity as well. You have a whole lot less back and forth between the engineering and design. There's a lot less throwing over the wall because you have UI engineers that care a lot about making those pixel perfect Figma mock ups come to life And then you have designers who are less concerned about the translation process and having to Hey, will you move that one pixel?

like this is this is off a little bit because they're communicating to people that care

The case for dedicated UI Engineers

Ridd: And I do want to talk about your engineering background because I do think it's like a little bit atypical to have a design leader. Sometimes it's like the head of the org is in the weeds of the code. How do you think that impacts the way that the design team works and the type of culture that you're trying to create even?

Derek: I feel like. I'm uniquely qualified to support a team from a design and UI specific engineering perspective because that's something that I've been really passionate about in my own career for many years now, of not only refining my design skill sets, but also the front end engineering skill sets.

UI engineer and watch them level each other up. I say all the time that the users never see the Figma files, like your design quality and your design capabilities of your team is only as good as the UI engineers that are implementing it.

And that is a good, like, case for velocity as well. You have a whole lot less back and forth between the engineering and design. There's a lot less throwing over the wall because you have UI engineers that care a lot about making those pixel perfect Figma mock ups come to life And then you have designers who are less concerned about the translation process and having to Hey, will you move that one pixel?

like this is this is off a little bit because they're communicating to people that care

How design collaborates with engineering at Clerk

Ridd: it's interesting to hear you say that because I think there's like such a negative stigma around the word handoff and like, yeah, you're just lobbing it over the wall. And it's because we look at really good design teams and people who are creating really high quality product as the example. And I'm starting to realize that the trend is that either they have dedicated UI engineers or like I was talking to someone early in the team in Notion where all the designers had to be able to code and yeah, of course, there's less pressure on a pixel perfect handoff process when you have that level of trust and can have a more fluid back and forth with an UI engineer.

So it's really interesting to even see how people. Your decisions at an organizational level impact what responsibilities and where designers can even prioritize their time , and their efforts. Any thoughts on that would be great, but also I would like to hear a little bit more about how do you, I engineers at clerk collaborate with design.

How do you think about the org structure? How integrated are those two disciplines?

Derek: During the first week of, while I was at Clark, I put together a presentation for the engineering leadership team.

to kind of show the value of why we want to have an engine a U. I. engineering team, but have that U. I. U. I. engineering team on the design team, not part of the product engineering team. those slides showed examples that I had put together of simple things, like using shadows as borders, .

Subtle gradients, , alignment techniques, just a lot of things that. usual product engineer don't think as much about, , or even notice. So the presentation was showing, here is what you normally would expect to see. And it was all of the things that I would normally say are wrong with the design. And most people are like, what's wrong with it?

Like, it looks really nice. It's really pretty. And then I showed the difference of using a shadow as a border. Instead of the standard border on top. Here's with some multiple shadows. Here's with some really good alignment techniques. , concentric borders, a hot topic, and it was like, that's when kind of the chat lit up of like, holy shit, I, it's so obvious now that I see the comparison, but before then I didn't.

But you have to have people that care about that level of detail, otherwise you're going to have your designers on your engineers backs, wanting them to switch this over to them. The engineers don't care that, layering multiple shadows, getting into Figma, figuring out what those shadow values are for each layer.

But not only that, it's really easy to use a plugin like Beautiful Shadows in Figma and get some really amazing natural shadows. But then you right click, copy a CSS and paste it to your files, and it's just like these arbitrary values that came out of a formula. But a UI engineer is going to take that and create their own formula of evening out those numbers, making it really nice, creating a pattern between them, because they care about that uniformity in the execution and the implementation of it.

To where a standard product engineer who's not responsible for that would be more focused on the data layer, caching, API. Which is equally important, but by separating those concerns, you have a UI engineer who is just focused on building extremely beautiful UI like more than just. Making pretty shadows, but like the user experience, they're, they're really passionate about that.

And then on the other end, you have the designers who design this and care a lot about what it looks like and design with intent. And they want to work with somebody who cares equally about the execution of it.

So before it was a designer works with a product, uh, product engineer and a non technical designer struggles to communicate with a product engineer because they don't understand what to say for them to understand, like an implementation strategy and code. But now you have this translator in the in between that the designers working closely with UI engineer and watching the designs come to life.

And then you have a UI engineer that takes their vision. Together and implements that and then works with the product engineer who's working on the API side of things to communicate everything that they're needing because they're very familiar with the API handoff and the state layer and all of all of that to where the designers not at all.

And now you have someone who can translate that to engineering. So you have performance increase on product engineering because now they're not having to write any CSS or focus or care about any of that. You have performance increase on the UI side because now your quality of your design is leveled up.

Because again, your users aren't going to see the Figma files. They're only going to see what's implemented. And you have somebody in place to really care about that implementation. And then you have a performance increase in the designers because now the quality that they care about is being translated into the code because they're working with folks that care as much about making sure that the quality stays the same from Figma to VS Code.

How design collaborates with engineering at Clerk

Ridd: it's interesting to hear you say that because I think there's like such a negative stigma around the word handoff and like, yeah, you're just lobbing it over the wall. And it's because we look at really good design teams and people who are creating really high quality product as the example. And I'm starting to realize that the trend is that either they have dedicated UI engineers or like I was talking to someone early in the team in Notion where all the designers had to be able to code and yeah, of course, there's less pressure on a pixel perfect handoff process when you have that level of trust and can have a more fluid back and forth with an UI engineer.

So it's really interesting to even see how people. Your decisions at an organizational level impact what responsibilities and where designers can even prioritize their time , and their efforts. Any thoughts on that would be great, but also I would like to hear a little bit more about how do you, I engineers at clerk collaborate with design.

How do you think about the org structure? How integrated are those two disciplines?

Derek: During the first week of, while I was at Clark, I put together a presentation for the engineering leadership team.

to kind of show the value of why we want to have an engine a U. I. engineering team, but have that U. I. U. I. engineering team on the design team, not part of the product engineering team. those slides showed examples that I had put together of simple things, like using shadows as borders, .

Subtle gradients, , alignment techniques, just a lot of things that. usual product engineer don't think as much about, , or even notice. So the presentation was showing, here is what you normally would expect to see. And it was all of the things that I would normally say are wrong with the design. And most people are like, what's wrong with it?

Like, it looks really nice. It's really pretty. And then I showed the difference of using a shadow as a border. Instead of the standard border on top. Here's with some multiple shadows. Here's with some really good alignment techniques. , concentric borders, a hot topic, and it was like, that's when kind of the chat lit up of like, holy shit, I, it's so obvious now that I see the comparison, but before then I didn't.

But you have to have people that care about that level of detail, otherwise you're going to have your designers on your engineers backs, wanting them to switch this over to them. The engineers don't care that, layering multiple shadows, getting into Figma, figuring out what those shadow values are for each layer.

But not only that, it's really easy to use a plugin like Beautiful Shadows in Figma and get some really amazing natural shadows. But then you right click, copy a CSS and paste it to your files, and it's just like these arbitrary values that came out of a formula. But a UI engineer is going to take that and create their own formula of evening out those numbers, making it really nice, creating a pattern between them, because they care about that uniformity in the execution and the implementation of it.

To where a standard product engineer who's not responsible for that would be more focused on the data layer, caching, API. Which is equally important, but by separating those concerns, you have a UI engineer who is just focused on building extremely beautiful UI like more than just. Making pretty shadows, but like the user experience, they're, they're really passionate about that.

And then on the other end, you have the designers who design this and care a lot about what it looks like and design with intent. And they want to work with somebody who cares equally about the execution of it.

So before it was a designer works with a product, uh, product engineer and a non technical designer struggles to communicate with a product engineer because they don't understand what to say for them to understand, like an implementation strategy and code. But now you have this translator in the in between that the designers working closely with UI engineer and watching the designs come to life.

And then you have a UI engineer that takes their vision. Together and implements that and then works with the product engineer who's working on the API side of things to communicate everything that they're needing because they're very familiar with the API handoff and the state layer and all of all of that to where the designers not at all.

And now you have someone who can translate that to engineering. So you have performance increase on product engineering because now they're not having to write any CSS or focus or care about any of that. You have performance increase on the UI side because now your quality of your design is leveled up.

Because again, your users aren't going to see the Figma files. They're only going to see what's implemented. And you have somebody in place to really care about that implementation. And then you have a performance increase in the designers because now the quality that they care about is being translated into the code because they're working with folks that care as much about making sure that the quality stays the same from Figma to VS Code.

Why investing in quality makes sense for the business

Ridd: I love thinking of UI engineers as translators. I think that even just listening to you talk, like if I'm going to start a product team, I'm probably gonna do something pretty similar that being said. for the sake of conversation, I am going to take a second to put my design Twitter troll hat on and I want to push back a little bit and hear what you say, because I think you could make the case Hey, they didn't notice , you're catering to developers who didn't notice these details.

It was still solving a real user problem and. By adding a translator, the cost of that additional salary outweighs , the, you know, little bit more tacit improvements or performance improvements that you're getting. So, you know, why does that make sense? Do you have anything to say to that design Twitter troll?

Derek: , we care a lot about the quality. We, and. I think the quality provides a ton of value to the product. , you know that when you look at a product that The team cares the team cares about what it looks like the team cares about how you experience it and it helps with the adoption and you take a really pretty solution and a really ugly solution and you're immediately as humans going to gravitate to this really beautiful implementation the the product design and the underlying strategy of what you're trying to accomplish still matters very much the dx is extremely important to us but the dx can be beautiful Linear talks about this a lot, , in their posts about quality, quality, quality.

And they have a similar setup. You can see, there's Paco over there, just cares so much about the quality. , Vercel, same way. You have Rauno over there. Cares so much about the quality of the output. You just see these nerdy developer tools look so beautiful because you have people there that care about what it looks like.

I could probably speak for everyone that I've mentioned that. It would be very demotivating to be working for a team who, who does not prioritize that for us, to allow us to express ourselves and utilize our talents as far as we can take them, as opposed to be limited to someone else not caring about what it looks like. Luxury cars are luxury cars and are as beautiful as they are because of how much time and care and thought go into what they look like. But they are also equally as beautiful under the hood. And everything else that they think through, when putting together such an amazingly crafted thing. And I think in software it's the same way.

Derek: We, the user doesn't care about the code, we care about the code. , they might not care about the shadow strategy, we care about the shadow strategy. But really when you put them side by side, it's an obvious difference. For, it doesn't have to be a designer that sees that. You might not be able to say what looks different, but you can see that it looks different. And I think key factor is what makes a good designer a great designer, is being able to tell you what the difference is.

Ridd: and by creating a place where that difference is celebrated, you're attracting the best designers too. And like, you put yourself on the fast track, like Linear, like Vercel, to be this magnet to really, really skilled designers. And I think it's, you're going to have a special team as a result, it's undeniable.

Derek: Yeah, I'm really excited about the growth of the team. We want to be very careful about growing because the culture, the team culture, the ego less culture is extremely important. We're so lucky to have, , James and Elvis leading kind of the visual design of the product and the website and we all just work so well together. There's just so much trust. So much autonomy. And I couldn't imagine growing to a large team to where there's starting to like, ego battling and like, it just, it wouldn't be tolerated.

It just would be so toxic to the team. it's so important to me to ship as a team. It's not James design. It's not Alvish's design. It's not Luke's design. It's not Derek's design. It's all of what we're doing.

Why investing in quality makes sense for the business

Ridd: I love thinking of UI engineers as translators. I think that even just listening to you talk, like if I'm going to start a product team, I'm probably gonna do something pretty similar that being said. for the sake of conversation, I am going to take a second to put my design Twitter troll hat on and I want to push back a little bit and hear what you say, because I think you could make the case Hey, they didn't notice , you're catering to developers who didn't notice these details.

It was still solving a real user problem and. By adding a translator, the cost of that additional salary outweighs , the, you know, little bit more tacit improvements or performance improvements that you're getting. So, you know, why does that make sense? Do you have anything to say to that design Twitter troll?

Derek: , we care a lot about the quality. We, and. I think the quality provides a ton of value to the product. , you know that when you look at a product that The team cares the team cares about what it looks like the team cares about how you experience it and it helps with the adoption and you take a really pretty solution and a really ugly solution and you're immediately as humans going to gravitate to this really beautiful implementation the the product design and the underlying strategy of what you're trying to accomplish still matters very much the dx is extremely important to us but the dx can be beautiful Linear talks about this a lot, , in their posts about quality, quality, quality.

And they have a similar setup. You can see, there's Paco over there, just cares so much about the quality. , Vercel, same way. You have Rauno over there. Cares so much about the quality of the output. You just see these nerdy developer tools look so beautiful because you have people there that care about what it looks like.

I could probably speak for everyone that I've mentioned that. It would be very demotivating to be working for a team who, who does not prioritize that for us, to allow us to express ourselves and utilize our talents as far as we can take them, as opposed to be limited to someone else not caring about what it looks like. Luxury cars are luxury cars and are as beautiful as they are because of how much time and care and thought go into what they look like. But they are also equally as beautiful under the hood. And everything else that they think through, when putting together such an amazingly crafted thing. And I think in software it's the same way.

Derek: We, the user doesn't care about the code, we care about the code. , they might not care about the shadow strategy, we care about the shadow strategy. But really when you put them side by side, it's an obvious difference. For, it doesn't have to be a designer that sees that. You might not be able to say what looks different, but you can see that it looks different. And I think key factor is what makes a good designer a great designer, is being able to tell you what the difference is.

Ridd: and by creating a place where that difference is celebrated, you're attracting the best designers too. And like, you put yourself on the fast track, like Linear, like Vercel, to be this magnet to really, really skilled designers. And I think it's, you're going to have a special team as a result, it's undeniable.

Derek: Yeah, I'm really excited about the growth of the team. We want to be very careful about growing because the culture, the team culture, the ego less culture is extremely important. We're so lucky to have, , James and Elvis leading kind of the visual design of the product and the website and we all just work so well together. There's just so much trust. So much autonomy. And I couldn't imagine growing to a large team to where there's starting to like, ego battling and like, it just, it wouldn't be tolerated.

It just would be so toxic to the team. it's so important to me to ship as a team. It's not James design. It's not Alvish's design. It's not Luke's design. It's not Derek's design. It's all of what we're doing.

How Derek things about design systems

Ridd: I want to talk more about culture. I do have one question that I want to ask first. Specifically because you have such an understanding of DX. I think like as you're doing this visual refresh, there's kind of this spectrum where on one side, there's pretty obvious efficiencies that you can build by systematizing things and ensuring quality.

But then if you go too far, you can kind of overarchitect things too early, especially when really everything's on the table from a visual standpoint. So how do you think about where you want to fall on that spectrum as you're doing this redesign of the visual language for Clerk?

Derek: I think teams, , can invest too quickly in design systems, both in Figma and in code., there are a lot of early decisions that get made that are easy to either overthink or, over optimize and the way that we have approached it is kind of designing for what we need at that time reusing.

That design or component a few times before codifying, , especially in code. So , Joe Bell and I have been writing a lot of dashboard code lately and Joe , he contributed to Vercel's design system, like a massive amount of talent when it comes to design system understanding and thinking about it.

And he's been an incredible asset to the velocity of our design system. However, someone like him who wants to design system all the things well, is still very, very supportive of, we should not be, like, documenting these components yet, like, let's create this new component that we think that we need, , use it a few places, allow the API kind of to create itself based on the usage, , and then once we feel like we are at a solid place of A table, a checkbox, an input.

, then that's when we kind of document that component as a piece of our design system. So when we're approaching new design system components or building a design system, it starts off as a lot of repetition initially. While we kind of define the patterns and the needs of that component. Before saying, yes, like this is the blueprint that we want to use for this.

How Derek things about design systems

Ridd: I want to talk more about culture. I do have one question that I want to ask first. Specifically because you have such an understanding of DX. I think like as you're doing this visual refresh, there's kind of this spectrum where on one side, there's pretty obvious efficiencies that you can build by systematizing things and ensuring quality.

But then if you go too far, you can kind of overarchitect things too early, especially when really everything's on the table from a visual standpoint. So how do you think about where you want to fall on that spectrum as you're doing this redesign of the visual language for Clerk?

Derek: I think teams, , can invest too quickly in design systems, both in Figma and in code., there are a lot of early decisions that get made that are easy to either overthink or, over optimize and the way that we have approached it is kind of designing for what we need at that time reusing.

That design or component a few times before codifying, , especially in code. So , Joe Bell and I have been writing a lot of dashboard code lately and Joe , he contributed to Vercel's design system, like a massive amount of talent when it comes to design system understanding and thinking about it.

And he's been an incredible asset to the velocity of our design system. However, someone like him who wants to design system all the things well, is still very, very supportive of, we should not be, like, documenting these components yet, like, let's create this new component that we think that we need, , use it a few places, allow the API kind of to create itself based on the usage, , and then once we feel like we are at a solid place of A table, a checkbox, an input.

, then that's when we kind of document that component as a piece of our design system. So when we're approaching new design system components or building a design system, it starts off as a lot of repetition initially. While we kind of define the patterns and the needs of that component. Before saying, yes, like this is the blueprint that we want to use for this.

How Clerk is redesigning their dashboard product

Ridd: You've mentioned this dashboard a few times now, and I want to drill into that a little bit because it's potentially less pure visual design and a little bit more traditional product design.

And my question is , are you viewing this more as. Like , a pure re skinning where you're just kind of focusing on the pixels, or are you getting into like some of the underlying UX assumptions? Are you doing any major like IA refactoring? Are you doing even like research , to figure out some of the things that you should change?

Like how much of a, redesign is actually happening on that dashboard?

Derek: I would be doing the company to service if we just came in and rethemed the existing dashboard. I think there's a lot of opportunity to improve. And it's absolutely been a ton of IA exploration of how can we improve the navigation? How can we reduce the amount of options that users have but continue to keep the same amount of capability? Along with it, yeah, let's make it look beautiful and, Add some visual distinguish to why something is where it is on the page, as opposed to a single font weight across the whole thing, a single text color across the whole thing, and using various design strategies to improve the product design, as well as improve the features that are in there to either a make them more automated, more capable, more robust, , or just a better DX when using them in general.

One thing I'm really excited to redesign soon is kind of our session management. , it's a really powerful feature in Clerk, , and I'm really excited to go through that and kind of tear it apart and rethink how to make that as magical of an experience as possible.

But it all starts with the leadership kind of. Unlocking everything, moving anything out of the way, think about it from a fresh perspective and allowing it to now be a lot more design driven as opposed to engineering it and then putting design on top of what we engineered. that's an exciting opportunity in its own to create a lot of velocity around iterations along with refactoring the dashboard to utilize newer technologies that improve the DX.

At that layer. So, yeah, the, the redesign is, is more than just painting it. It's thinking about it in a better way, and especially Alvish has been making massive improvements there. And it's going to provide a lot of values to users,

having that trust and autonomy to the design team now to push where we think things should go along with utilizing engineering and their knowledge and their perspective so that we all are really shipping something that we really care a lot about those types of redesigns take a lot of time, you know, redesign your whole dashboard, this and that.

How Clerk is redesigning their dashboard product

Ridd: You've mentioned this dashboard a few times now, and I want to drill into that a little bit because it's potentially less pure visual design and a little bit more traditional product design.

And my question is , are you viewing this more as. Like , a pure re skinning where you're just kind of focusing on the pixels, or are you getting into like some of the underlying UX assumptions? Are you doing any major like IA refactoring? Are you doing even like research , to figure out some of the things that you should change?

Like how much of a, redesign is actually happening on that dashboard?

Derek: I would be doing the company to service if we just came in and rethemed the existing dashboard. I think there's a lot of opportunity to improve. And it's absolutely been a ton of IA exploration of how can we improve the navigation? How can we reduce the amount of options that users have but continue to keep the same amount of capability? Along with it, yeah, let's make it look beautiful and, Add some visual distinguish to why something is where it is on the page, as opposed to a single font weight across the whole thing, a single text color across the whole thing, and using various design strategies to improve the product design, as well as improve the features that are in there to either a make them more automated, more capable, more robust, , or just a better DX when using them in general.

One thing I'm really excited to redesign soon is kind of our session management. , it's a really powerful feature in Clerk, , and I'm really excited to go through that and kind of tear it apart and rethink how to make that as magical of an experience as possible.

But it all starts with the leadership kind of. Unlocking everything, moving anything out of the way, think about it from a fresh perspective and allowing it to now be a lot more design driven as opposed to engineering it and then putting design on top of what we engineered. that's an exciting opportunity in its own to create a lot of velocity around iterations along with refactoring the dashboard to utilize newer technologies that improve the DX.

At that layer. So, yeah, the, the redesign is, is more than just painting it. It's thinking about it in a better way, and especially Alvish has been making massive improvements there. And it's going to provide a lot of values to users,

having that trust and autonomy to the design team now to push where we think things should go along with utilizing engineering and their knowledge and their perspective so that we all are really shipping something that we really care a lot about those types of redesigns take a lot of time, you know, redesign your whole dashboard, this and that.

Why Clerk isn't rolling out their redesign all at once

Derek: So there are trade offs because I care a lot about velocity and improving the dashboard as we retheme the thing. So we have had to accept these. In between states of you're going to go to a page and you're going to see something that looks, that it's visually styled different than another page. And we've just kind of accepted that.

Because I just really don't want to build a new dashboard behind a feature flag and one day flip it over. I'd much rather give users that value now. And those improvements now. And deal with the inconsistencies. So that then over the course of a few months, we'll be where we want to be.

Iteratively and step by step as opposed to kind of working behind closed doors.

Ridd: That was actually my next question, which you beat me to, but I do want to drill into it a little bit more. So if you're not going to feature flag an entire dashboard and you're going to roll this out in phases,

how much of the redesign of the dashboard is focusing on new feature work versus going backwards and actually like revamping some of the existing architecture.

Derek: I'd say that there is very much a lot of new feature work happening right alongside the improvements. I've been using those features as opportunities to start fresh, as opposed to kind of just working with what we have.

Like, let's think about this from the ground up, , no matter what it's going to look like. We understand that it's going to be visually consistent from the rest of the app. But why make this fit into the existing design system and then have to go back and retheme it again, , as opposed to just accepting those, that kind of intermediate state while we continue to push the rest of the visual design throughout the dashboard while we bring in new features.

For instance, we just adjusted pricing and new pricing pages came out inside of the dashboard there, but That went from we want to ship something in January to we had been working on something for a little while and like, let's just get it out. Like, why don't we, you know, why, why do we want to wait until January?

This is an important improvement to the users that will lower bills. So we want to provide that value now. So, there is very much new adjustments being made while the underlying architecture is being explored and improved on as well. Custom roles, we just, again, shipped custom roles within there, and that was a massive feature.

We have some more improvements that we want to continue to make in it. But the importance of, like, getting to a beta and getting this to users to start using that so we can get feedback and make adjustments is extremely important.

Why Clerk isn't rolling out their redesign all at once

Derek: So there are trade offs because I care a lot about velocity and improving the dashboard as we retheme the thing. So we have had to accept these. In between states of you're going to go to a page and you're going to see something that looks, that it's visually styled different than another page. And we've just kind of accepted that.

Because I just really don't want to build a new dashboard behind a feature flag and one day flip it over. I'd much rather give users that value now. And those improvements now. And deal with the inconsistencies. So that then over the course of a few months, we'll be where we want to be.

Iteratively and step by step as opposed to kind of working behind closed doors.

Ridd: That was actually my next question, which you beat me to, but I do want to drill into it a little bit more. So if you're not going to feature flag an entire dashboard and you're going to roll this out in phases,

how much of the redesign of the dashboard is focusing on new feature work versus going backwards and actually like revamping some of the existing architecture.

Derek: I'd say that there is very much a lot of new feature work happening right alongside the improvements. I've been using those features as opportunities to start fresh, as opposed to kind of just working with what we have.

Like, let's think about this from the ground up, , no matter what it's going to look like. We understand that it's going to be visually consistent from the rest of the app. But why make this fit into the existing design system and then have to go back and retheme it again, , as opposed to just accepting those, that kind of intermediate state while we continue to push the rest of the visual design throughout the dashboard while we bring in new features.

For instance, we just adjusted pricing and new pricing pages came out inside of the dashboard there, but That went from we want to ship something in January to we had been working on something for a little while and like, let's just get it out. Like, why don't we, you know, why, why do we want to wait until January?

This is an important improvement to the users that will lower bills. So we want to provide that value now. So, there is very much new adjustments being made while the underlying architecture is being explored and improved on as well. Custom roles, we just, again, shipped custom roles within there, and that was a massive feature.

We have some more improvements that we want to continue to make in it. But the importance of, like, getting to a beta and getting this to users to start using that so we can get feedback and make adjustments is extremely important.

The design culture at Clerk

Ridd: All right, let's talk culture and team a little bit. You've mentioned the influence of planet scale a few times now. Can you talk a little bit about what elements or characteristics from your time there are you trying to bring into this new opportunity at clerk and how that impacts the culture that you're even trying to create,

Derek: planet scale is a unique team. , I have been wanting to write a blog post about the experience of working there because it was pretty eye opening. You have a lot of extremely talented thought leaders in the industry in one room, and they have all experienced how they don't want to work and wanted to make sure that coming to planet scale, they don't run into those same issues there.

And it was very apparent. , it's very important to eliminate as much process as possible and enable, , the individual to work the way that they want to work to execute the way that they want to execute at the velocity that they want to work as well. , I don't ever remember any deadlines on features at planet scale.

, when I said that out loud to a former coworker, apparently there might have been assumptions, but they were just never really vocalized , the process was. Someone deciding on what we're going to kind of work on us being able to influence it, but it usually came from, at the leadership level, And we would support multiple features kind of happening at the same time But we were never communicated when we needed something by because We just wanted to create the best thing possible and we're working with the best people possible So why do we have to time box this?

I have a big issue with deadlines. Setting a deadline is going to either allow the person to stretch out that amount of work over that period of time, or have to eventually descope the project to be able to meet that arbitrary deadline. Now we did have launch weeks at PlanetScale. We knew that we were going to want to ship a feature at that time so there was, maybe that could be called a deadline, but they were so far ahead that we knew, like, we wanted to nail this.

But when it came to updating the branching page, I remember David and I were never told when that was going to be due, but we just told that that's what we were needed.

And then he and I worked together. For what we think should be the solution for this and then I designed and built right along him while he did the back end and the API and then we met in a PR to where it was just paint by numbers to where he's just plugging in API endpoints and that process of working was way more velocity than I've ever experienced anywhere else. We never had to sweat a deadline, but we just pushed each other to ship constantly. There were also very , small teams there. It was two of us, maybe a third. I don't even remember having a third on a feature. It was usually a product designer and an engineer on something. And we just shipped features fast. It was, it was definitely because of the process of how we work,

Ridd: I want to double click on it because it doesn't a hundred percent click to me you're building a system that intentionally removes this need and pressure to de scope how does that. Contribute to velocity in a culture of shipping when there's always more details. There's always more polished.

There's always more features that we can add as designers.

The design culture at Clerk

Ridd: All right, let's talk culture and team a little bit. You've mentioned the influence of planet scale a few times now. Can you talk a little bit about what elements or characteristics from your time there are you trying to bring into this new opportunity at clerk and how that impacts the culture that you're even trying to create,

Derek: planet scale is a unique team. , I have been wanting to write a blog post about the experience of working there because it was pretty eye opening. You have a lot of extremely talented thought leaders in the industry in one room, and they have all experienced how they don't want to work and wanted to make sure that coming to planet scale, they don't run into those same issues there.

And it was very apparent. , it's very important to eliminate as much process as possible and enable, , the individual to work the way that they want to work to execute the way that they want to execute at the velocity that they want to work as well. , I don't ever remember any deadlines on features at planet scale.

, when I said that out loud to a former coworker, apparently there might have been assumptions, but they were just never really vocalized , the process was. Someone deciding on what we're going to kind of work on us being able to influence it, but it usually came from, at the leadership level, And we would support multiple features kind of happening at the same time But we were never communicated when we needed something by because We just wanted to create the best thing possible and we're working with the best people possible So why do we have to time box this?

I have a big issue with deadlines. Setting a deadline is going to either allow the person to stretch out that amount of work over that period of time, or have to eventually descope the project to be able to meet that arbitrary deadline. Now we did have launch weeks at PlanetScale. We knew that we were going to want to ship a feature at that time so there was, maybe that could be called a deadline, but they were so far ahead that we knew, like, we wanted to nail this.

But when it came to updating the branching page, I remember David and I were never told when that was going to be due, but we just told that that's what we were needed.

And then he and I worked together. For what we think should be the solution for this and then I designed and built right along him while he did the back end and the API and then we met in a PR to where it was just paint by numbers to where he's just plugging in API endpoints and that process of working was way more velocity than I've ever experienced anywhere else. We never had to sweat a deadline, but we just pushed each other to ship constantly. There were also very , small teams there. It was two of us, maybe a third. I don't even remember having a third on a feature. It was usually a product designer and an engineer on something. And we just shipped features fast. It was, it was definitely because of the process of how we work,

Ridd: I want to double click on it because it doesn't a hundred percent click to me you're building a system that intentionally removes this need and pressure to de scope how does that. Contribute to velocity in a culture of shipping when there's always more details. There's always more polished.

There's always more features that we can add as designers.

Deep Dives

Get our weekly breakdowns

Insights + resources from top designers 👇

Lauren LoPrete

Director of Design Systems @ Cash App

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

James McDonald

Designer @ Clerk

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

HC

"

I've been binging Dive Club lately and the quality is nuts

Literally the only show about design I watch”

Eugene Fedorenko

"

I've been binging Dive Club lately and the quality is nuts

Literally the only show about design I watch”

Eugene Fedorenko

hello@dive.club

Ⓒ Dive 2024