Season 2
|
Episode 9
Lessons from the founding designer at Linear
Adrien Griveau
Founding Designer @ Linear
Sep 21, 2023
Sep 21, 2023
|
1:05:16
1:05:16
music by Dennis
About this Episode
In this Deep Dive, Adrien Griveau gives us an all-access pass to design at Linear 🙌 We talk about how they approach design systems, traits they look for in candidates, how Adrien works with engineering, and a lot more!
We even get into strategies to stand out as a design candidate when applying for roles at startups (hint: it's not showing off your button components).
We can all learn something from this one ✌️
Deep Dives
Get every episode
Free lessons from the top designers 👇
Fonz Morris
Lead monetization designer @ Netflix
Mia Blume
Past leader @ Pinterest, Square
Jorn van Dijk
CEO @ Framer
Femke
Design lead @ Gusto
Kenny Chen
UX lead @ Google
Join 8K+ designers
HC
HC
HC
HC
Deep Dives
Get every episode
Free lessons from 👇
Fonz Morris
Lead designer @ Netflix
Mia Blume
Past leader @ Pinterest, Square
Femke
Design lead @ Gusto
Kenny Chen
UX lead @ Google
Join 8K+ designers
HC
HC
HC
Deep Dives
Get every episode
Free lessons from the top designers 👇
Fonz Morris
Lead monetization designer @ Netflix
Mia Blume
Past leader @ Pinterest, Square
Jorn van Dijk
CEO @ Framer
Femke
Design lead @ Gusto
Kenny Chen
UX lead @ Google
Join 8K+ designers
HC
HC
HC
HC
Transcript chapters
How Adrien got the role
[00:00:00] Adrien: Yeah. Um, so I'm, I'm originally from France, uh, from Paris. Um, uh, was working there for a startup studio called if on the other times, uh, they, They created a lot of, like, SaaS companies. One of them is maybe Font, that is the most known, like, I mean, in the U. S. Um, and that's where I kind of started to discover, like, productivity tools, uh, as a designer, uh, SaaS software.
And then I had the opportunity to move to the U. S., uh, to work for Microsoft, uh, because one of the French company, uh, called Sunrise at the time got acquired, and, uh, They kind of proposed me to, uh, to walk with them. So we build Outlook mobile for some years. Uh, they also, it was very like large company.
Uh, Microsoft big in SAS, uh, was a big time for them also because they. Well, I cancelling the windows phone. And, uh, so the challenge was like, okay, how Microsoft looks like, uh, in iOS or Android, which are not that platform and how you kind of create the language for them there. So that was basically my role there for like sometimes.
Um, and we were working a lot on GitHub, uh, internally, even for design. Um, that was because the company was remote and we were also like sharing all the knowledge. And I really liked this, this process at the time, because when I joined. I already had like the historical things on like what's going on, like what the decision they will take at the time and how people think about features and stuff.
So I got really in love with Github, but also as a designer, I had a lot of functionalities that I didn't like. They were mostly for engineers. So, uh, with some friends, we build a Mac app called GitScout. and so I really started to get very interested into like productivities, like product management, uh, issues, ticketing at the time, uh, and trying to get the best from the GitHub API, but also on top of that, having a nice, nice Mac app experiment that would be mostly useful for PM or like designer where you just want to Discuss things, but you don't really need to have like all the developers, uh, tools inside.
Um, and then, on that on the side for a long time. Uh, moved back to Europe, uh, moved to Portugal actually, uh, where I was mostly freelancing and working for some startups, very early stage. which was good because I was missing this kind of... mindset of work, which is early says company, uh, being at Microsoft for sometimes it was like very refreshing for me and yeah, and then Gary, uh, CEO of, uh, linear, which is also a designer, uh, it has need to be mentioned, uh, that's, uh, that's going to be very important, I think for the rest of the conversation.
Also, uh, the interaction we had together, uh, when we started building out, they reached to me and I think what we did at the time. Uh, kind of inspire them a bit to create, you know, I'm not sure like what could be the real story there, but it's mostly about the new us. I think we kind of also set the tone of some ideas that they liked and, um, and we had a lot of big discussion together about like, okay, what.
what they were building. I knew also what were the problems in this space. Uh, how do you compete with bigger tools when you are a small company? Uh, it's a big challenging. So it's not just only about the product, but it's also about the strategy. How are you going to distribute an app like that? How do you going to make people change their workflow for companies?
This is a big major. Pick to choose a tool like that, because all they are like informations and, uh, the way they're going to build a product is going to be based around the tool. So you really have to be convincing. What about what you do? Um, and I was, I got very seduced by their strategy, the way they were thinking about the company, the future of it, the approach they took.
So we started to work together. Like, so I joined the company more than 3 years ago now. they already had a, like a small product, uh, that was working, like was doing the basic, like very classic issues. the, the design, uh, basis was there. Um, maybe we can talk about that later on, but yeah, it, it was, um, I really like the, the, the direction.
And so basically the way we operate is that we have a team in Europe and we have a team, uh, in the base US base. So my goal was. Uh, and my role was also to, like, mostly take care of the design part, uh, for the Europe team. And this started, uh, for sure, Cary's CEO also, so as a designer, he has less and less time.
Um, and the strategy with Linearm is always to grow with our customers. So we started, like, being used by teams of, like, five, six people. Uh, our team was pretty small, two at a time, we were about like five, six people, too. And, uh, as company grow, you want to make sure you have the right set of features and functionalities inside the tools so they can, um, actually still use the product.
So, like, since the start, also, we really, really take care of, like, customer's feedback. It was, it's deeply implemented in the way we work. Uh, we try to be, Always on top of like, what are the new people joining? What do they like? What don't they do? Like, so we try to always react pretty quick when we see that there is an issue or like when people like something we double down on that too.
Um, and it's been the strategy so far. And so we grow with some of our customers, um, then realize what are the new challenges for bigger companies that now are bigger than us. Like we are about like 50 people, uh, at the moment, but, um, Like we have people that are thousands of employees using linear and so you have always new challenges and the idea was like always to see like, what do they need and how we can make them work better to build better product.
Um, so that that was technically the strategy that I really liked. And when I joined the company, I think it was very smart from them to to set this direction. Which kind of helps you in terms of the product side to don't overthink when you build and be like, okay, if those people need this, that means that maybe other people will need this.
Um, so yeah, that's basically one of the reasons why I'm there now. Uh, and, uh, it's been a big, nice, very nice journey. And I'm very excited, uh, building this product every day.
How Adrien got the role
[00:00:00] Adrien: Yeah. Um, so I'm, I'm originally from France, uh, from Paris. Um, uh, was working there for a startup studio called if on the other times, uh, they, They created a lot of, like, SaaS companies. One of them is maybe Font, that is the most known, like, I mean, in the U. S. Um, and that's where I kind of started to discover, like, productivity tools, uh, as a designer, uh, SaaS software.
And then I had the opportunity to move to the U. S., uh, to work for Microsoft, uh, because one of the French company, uh, called Sunrise at the time got acquired, and, uh, They kind of proposed me to, uh, to walk with them. So we build Outlook mobile for some years. Uh, they also, it was very like large company.
Uh, Microsoft big in SAS, uh, was a big time for them also because they. Well, I cancelling the windows phone. And, uh, so the challenge was like, okay, how Microsoft looks like, uh, in iOS or Android, which are not that platform and how you kind of create the language for them there. So that was basically my role there for like sometimes.
Um, and we were working a lot on GitHub, uh, internally, even for design. Um, that was because the company was remote and we were also like sharing all the knowledge. And I really liked this, this process at the time, because when I joined. I already had like the historical things on like what's going on, like what the decision they will take at the time and how people think about features and stuff.
So I got really in love with Github, but also as a designer, I had a lot of functionalities that I didn't like. They were mostly for engineers. So, uh, with some friends, we build a Mac app called GitScout. and so I really started to get very interested into like productivities, like product management, uh, issues, ticketing at the time, uh, and trying to get the best from the GitHub API, but also on top of that, having a nice, nice Mac app experiment that would be mostly useful for PM or like designer where you just want to Discuss things, but you don't really need to have like all the developers, uh, tools inside.
Um, and then, on that on the side for a long time. Uh, moved back to Europe, uh, moved to Portugal actually, uh, where I was mostly freelancing and working for some startups, very early stage. which was good because I was missing this kind of... mindset of work, which is early says company, uh, being at Microsoft for sometimes it was like very refreshing for me and yeah, and then Gary, uh, CEO of, uh, linear, which is also a designer, uh, it has need to be mentioned, uh, that's, uh, that's going to be very important, I think for the rest of the conversation.
Also, uh, the interaction we had together, uh, when we started building out, they reached to me and I think what we did at the time. Uh, kind of inspire them a bit to create, you know, I'm not sure like what could be the real story there, but it's mostly about the new us. I think we kind of also set the tone of some ideas that they liked and, um, and we had a lot of big discussion together about like, okay, what.
what they were building. I knew also what were the problems in this space. Uh, how do you compete with bigger tools when you are a small company? Uh, it's a big challenging. So it's not just only about the product, but it's also about the strategy. How are you going to distribute an app like that? How do you going to make people change their workflow for companies?
This is a big major. Pick to choose a tool like that, because all they are like informations and, uh, the way they're going to build a product is going to be based around the tool. So you really have to be convincing. What about what you do? Um, and I was, I got very seduced by their strategy, the way they were thinking about the company, the future of it, the approach they took.
So we started to work together. Like, so I joined the company more than 3 years ago now. they already had a, like a small product, uh, that was working, like was doing the basic, like very classic issues. the, the design, uh, basis was there. Um, maybe we can talk about that later on, but yeah, it, it was, um, I really like the, the, the direction.
And so basically the way we operate is that we have a team in Europe and we have a team, uh, in the base US base. So my goal was. Uh, and my role was also to, like, mostly take care of the design part, uh, for the Europe team. And this started, uh, for sure, Cary's CEO also, so as a designer, he has less and less time.
Um, and the strategy with Linearm is always to grow with our customers. So we started, like, being used by teams of, like, five, six people. Uh, our team was pretty small, two at a time, we were about like five, six people, too. And, uh, as company grow, you want to make sure you have the right set of features and functionalities inside the tools so they can, um, actually still use the product.
So, like, since the start, also, we really, really take care of, like, customer's feedback. It was, it's deeply implemented in the way we work. Uh, we try to be, Always on top of like, what are the new people joining? What do they like? What don't they do? Like, so we try to always react pretty quick when we see that there is an issue or like when people like something we double down on that too.
Um, and it's been the strategy so far. And so we grow with some of our customers, um, then realize what are the new challenges for bigger companies that now are bigger than us. Like we are about like 50 people, uh, at the moment, but, um, Like we have people that are thousands of employees using linear and so you have always new challenges and the idea was like always to see like, what do they need and how we can make them work better to build better product.
Um, so that that was technically the strategy that I really liked. And when I joined the company, I think it was very smart from them to to set this direction. Which kind of helps you in terms of the product side to don't overthink when you build and be like, okay, if those people need this, that means that maybe other people will need this.
Um, so yeah, that's basically one of the reasons why I'm there now. Uh, and, uh, it's been a big, nice, very nice journey. And I'm very excited, uh, building this product every day.
Early user interviews
[00:06:12] Ridd: You mentioned this relationship with early customers and also just to, again, highlight the fact that you were a founder of a company called get scout. So you were deeply embedded into the space. I'd like to kind of get a little bit more of a lens and how you were knowing what to build in those first three, six ish months.
Because as a founding designer myself, when I kind of look back at my own experience in those early days. Yeah, we were talking to customers when it made sense, but a lot of times it felt like we were just heads down building what we kind of knew and felt confident was table stakes for the product. And so maybe you could talk about what those early user conversations were in the early days, and maybe even how Linear's approach to user research has evolved over the time that you've been there.
[00:06:58] Adrien: I think there is. One big, change that we bring on the table regarding SaaS product, um, is the fact that we had this linear method. That's something we still show on the website, which is what do we think you should do when you build a product? And we really think that the product is not there to match your workflow, but actually also to give you a new way, a new workflow on how you build things.
And that most people in tech companies, which are customers, most of the time, uh, they like to build things that I, there are coders, there are designers. And so the process part, uh, for them is something that is kind of blurry sometimes, or also like very organized in different way. But when you are excited to build, you don't want, want to think too much about your process.
You actually Want to just do things and make sure you communicate well with your team and that things get done and that you're making progress. And so one of the approach of is now is was also to kind of restrain you to certain set of feature like there was not that much customization in the tool that you really have to basically follow the way we think you should do things.
Um, so the, the designs and the product challenge were always the balance between what do people want, but what are we going to deliver? And I think this has been very different. So when we take customer feedback, we don't, we want to hear people problems like people problems are very different. Uh, we have very different kind of team that operates with us.
Uh, they all have different products, different markets, but in the end they have common problems, but they don't express those problems. So the thing is also to always balance between what people are saying, what are they struggling on and how do you deliver? Like, uh, so some people come out sometime with some solutions for us.
Oh, you should do, like this button should do that and stuff like that. So you need to hear those. Sometimes they have good ideas, like it's never bad. Uh, but most of the time you also have to understand the common pattern of those problems and realize that the solution could be somewhere else. And sometimes also the solution can be way simpler than what people are expecting you to do.
and by the fact that we have the same setup for every user, they have issues, they have statutes, they have labels, like everybody is using the same set of features. We are also able to use this data, provide you this data in a different way than actually the problem you think was a feature, it's actually just displaying it differently for you.
Um, so that's, that's a lot of discussion for sure internally, a lot of testing. Um, and, uh, it's, uh, it's very hard to, to explain, okay, why we designed this, this way. It's mostly like discussion apparently, uh, and also I feel like everybody in the team is very product oriented, even the engineers, even the people at the support.
So everybody's putting his head down on like. Trying to make the product as much as possible the best, uh, but yeah, I don't know if I answer right your question there, but,
Early user interviews
[00:06:12] Ridd: You mentioned this relationship with early customers and also just to, again, highlight the fact that you were a founder of a company called get scout. So you were deeply embedded into the space. I'd like to kind of get a little bit more of a lens and how you were knowing what to build in those first three, six ish months.
Because as a founding designer myself, when I kind of look back at my own experience in those early days. Yeah, we were talking to customers when it made sense, but a lot of times it felt like we were just heads down building what we kind of knew and felt confident was table stakes for the product. And so maybe you could talk about what those early user conversations were in the early days, and maybe even how Linear's approach to user research has evolved over the time that you've been there.
[00:06:58] Adrien: I think there is. One big, change that we bring on the table regarding SaaS product, um, is the fact that we had this linear method. That's something we still show on the website, which is what do we think you should do when you build a product? And we really think that the product is not there to match your workflow, but actually also to give you a new way, a new workflow on how you build things.
And that most people in tech companies, which are customers, most of the time, uh, they like to build things that I, there are coders, there are designers. And so the process part, uh, for them is something that is kind of blurry sometimes, or also like very organized in different way. But when you are excited to build, you don't want, want to think too much about your process.
You actually Want to just do things and make sure you communicate well with your team and that things get done and that you're making progress. And so one of the approach of is now is was also to kind of restrain you to certain set of feature like there was not that much customization in the tool that you really have to basically follow the way we think you should do things.
Um, so the, the designs and the product challenge were always the balance between what do people want, but what are we going to deliver? And I think this has been very different. So when we take customer feedback, we don't, we want to hear people problems like people problems are very different. Uh, we have very different kind of team that operates with us.
Uh, they all have different products, different markets, but in the end they have common problems, but they don't express those problems. So the thing is also to always balance between what people are saying, what are they struggling on and how do you deliver? Like, uh, so some people come out sometime with some solutions for us.
Oh, you should do, like this button should do that and stuff like that. So you need to hear those. Sometimes they have good ideas, like it's never bad. Uh, but most of the time you also have to understand the common pattern of those problems and realize that the solution could be somewhere else. And sometimes also the solution can be way simpler than what people are expecting you to do.
and by the fact that we have the same setup for every user, they have issues, they have statutes, they have labels, like everybody is using the same set of features. We are also able to use this data, provide you this data in a different way than actually the problem you think was a feature, it's actually just displaying it differently for you.
Um, so that's, that's a lot of discussion for sure internally, a lot of testing. Um, and, uh, it's, uh, it's very hard to, to explain, okay, why we designed this, this way. It's mostly like discussion apparently, uh, and also I feel like everybody in the team is very product oriented, even the engineers, even the people at the support.
So everybody's putting his head down on like. Trying to make the product as much as possible the best, uh, but yeah, I don't know if I answer right your question there, but,
Overview of his first few months at Linear
[00:09:58] Ridd: Oh, that's great. That's great. One of my favorite parts of being a designer is like that early stage where you're establishing a lot of the strategy, you're creating a lot of things from scratch, you're making new Figma files everywhere. Can you drill into that first month or two? What were some of the original things that you were doing as the new founding designer?
[00:10:17] Adrien: Yeah, for sure. I think, um, the, the few months was actually to get along with Carrie and understand, like, what was his original thought on, you know, um, I think one of the, the change we would like to operate, uh, in the SAS while he was at the time, a lot of people were using those cartoon character all around the place.
Uh, it was very colorful and. We host, we always had this feeling that Actually, SAS product and tooling like professional product want to look more a bit more professional, maybe, and for sure, like, it was a big visual differentiator, like for more competitor, so I think that was also the strategy to go there, but also us, we were kind of tired of like this very colorful interface that would work.
Actually, most of the time, sometimes add some noise on top of, like, people just want to operate something quick. Um, so the, the very first days and months was like also getting what Cary has done with the basis, the direction of the design, but how we will adapt it and make this brand evolve with all the new features we wanted to have.
Like at the time we didn't have planning features. Did I have like most of the things we have now, like the product was very small. So, um, I think the early on was me discussing how we can take these days, things that he had created and that he has fought with the team and how are we going to make that grow and make that work for like even larger audience. Um, and I think that's, uh, a discussion that is still happening now is like, uh, if you look at the brand back in the day until now, there was still these common things, but we also bring a lot of new stuff to this brand, a lot of new narrative, a lot of new visual. So the discussion is way all the time about like, okay, is it still linear, but it has to change also because people want to have new things.
So it's, it's, it's been a lot of like getting along together, getting. Getting the trust because also working, uh, as two designers on a very early on product is also about like the trust. And, uh, I think my part of it was really like showing him that I really believe in the direction of it and showing him that I was able to actually.
Translate that better, make it evolve so we can have, uh, we can have a very good, um, relationship. We were only two designers for almost a year. Then after we had Edgar join us, uh, he's from Argentina on the U. S. side, um, working mostly now on the website and also still doing some product. Now we have more designers coming up to dinner this year.
But, uh, so we were only two designers for almost a year, which was, um, A very exciting time to actually build collaborate a lot together every day on like how we can make that better having early discussions about like how it now will be looking one year, two years, three years. So that was, yeah,
Overview of his first few months at Linear
[00:09:58] Ridd: Oh, that's great. That's great. One of my favorite parts of being a designer is like that early stage where you're establishing a lot of the strategy, you're creating a lot of things from scratch, you're making new Figma files everywhere. Can you drill into that first month or two? What were some of the original things that you were doing as the new founding designer?
[00:10:17] Adrien: Yeah, for sure. I think, um, the, the few months was actually to get along with Carrie and understand, like, what was his original thought on, you know, um, I think one of the, the change we would like to operate, uh, in the SAS while he was at the time, a lot of people were using those cartoon character all around the place.
Uh, it was very colorful and. We host, we always had this feeling that Actually, SAS product and tooling like professional product want to look more a bit more professional, maybe, and for sure, like, it was a big visual differentiator, like for more competitor, so I think that was also the strategy to go there, but also us, we were kind of tired of like this very colorful interface that would work.
Actually, most of the time, sometimes add some noise on top of, like, people just want to operate something quick. Um, so the, the very first days and months was like also getting what Cary has done with the basis, the direction of the design, but how we will adapt it and make this brand evolve with all the new features we wanted to have.
Like at the time we didn't have planning features. Did I have like most of the things we have now, like the product was very small. So, um, I think the early on was me discussing how we can take these days, things that he had created and that he has fought with the team and how are we going to make that grow and make that work for like even larger audience. Um, and I think that's, uh, a discussion that is still happening now is like, uh, if you look at the brand back in the day until now, there was still these common things, but we also bring a lot of new stuff to this brand, a lot of new narrative, a lot of new visual. So the discussion is way all the time about like, okay, is it still linear, but it has to change also because people want to have new things.
So it's, it's, it's been a lot of like getting along together, getting. Getting the trust because also working, uh, as two designers on a very early on product is also about like the trust. And, uh, I think my part of it was really like showing him that I really believe in the direction of it and showing him that I was able to actually.
Translate that better, make it evolve so we can have, uh, we can have a very good, um, relationship. We were only two designers for almost a year. Then after we had Edgar join us, uh, he's from Argentina on the U. S. side, um, working mostly now on the website and also still doing some product. Now we have more designers coming up to dinner this year.
But, uh, so we were only two designers for almost a year, which was, um, A very exciting time to actually build collaborate a lot together every day on like how we can make that better having early discussions about like how it now will be looking one year, two years, three years. So that was, yeah,
Creating a more professional brand
Creating a more professional brand
Designing with keyboard shortcuts in mind
[00:16:41] Ridd: I don't actually have that much of a background designing tools. And so something that I was so curious to ask you about in this conversation was what it was kind of like designing for people who kind of live in your tool to an extent and are really power users. Because when I first. Downloaded linear and started using it at Maven.
Immediately. The thing you notice is that it's designed to kind of be a mouseless experience. You can accomplish essentially everything with keyboard shortcuts. And I've always kind of wondered what is it like for the designer to create a product where keyboard shortcuts are a first class citizen and how does that impact your process?
[00:17:20] Adrien: we have to think that also there are a lot of people using linear without using the shortcut, uh, I think majority of people. More they use the tools, more they will use shortcuts, because also a lot of tools out there don't provide you shortcuts by default. Some people, they kind of discover the shortcut later on.
So I always design any feature that you can, should be able to do it only with using your mouse anyway. And I think the, the shortcut part actually is a new layer I had on top of it. And, um, to make sure that it can go faster. Um, and also. I'm lucky to enough to work with a lot of engineers that love shortcuts.
So we always have crazy discussion on Slack on like which letter should we pick for that and that. And so like most of the time, this is like the cherry on the cake that we add on top. Like, okay, how now we design something that everybody can use with a mouse, but how we can make it even faster with shortcuts.
So that's, that will be mostly the process around it. But. Also, our goal is to make sure that we have people that are not engineers that want to use linear like this is basically for us, like now that we have bigger companies, you don't only have engineers in linear. So we want to make sure that also they're able to use the product, but we always try to advocate to them and look, you can also use shortcut and you will even like it more.
So that's, that's, that's the balance has to be there all the time, but we make sure that. It's, and yeah, for sure, if you're only thinking with shortcut, it's very easy to design something, uh, because you don't need to create a lot of interfaces for click. But we still design things for, for mouse only. So it's always in my head.
That's the way I do it always after, but not at the first place.
[00:18:55] Ridd: Okay, that's good to know. Cause I was kind of wondering that, like, do you have this map of all the shortcuts that you have to keep track of and where, like, is it something that it's kind of slapped on before shipping? Or is it kind of earlier in the process? Um, because it is, I get the idea that like you learn it over time.
Like I, I remember even multiple times in. The Maven Slack, where someone would be like, wow, did you know that you can use this shortcut to accomplish X? And then everyone would be like, Oh my gosh, like I'm going to start using that. And so we've, I, we've kind of matured in our own usage of the tool over time as well.
[00:19:26] Adrien: I mean, my role also as a non engineer is to kind of remind them. So although that we don't have only shortcut people using the product and I think I kind of forced myself to don't use them too much sometimes to make sure I don't forget that you also have to click on some button to access some things in the app.
Um, but it's part of the process when we ship a new functionality or when we improve something to actually make sure that they are shortcut accessible, um, all the time. So that's something that is. naturally part of the linear process on when we ship stuff and also sometimes we only have discussions also about how we can improve the shortcut system.
That's one of the issues I think that is the biggest with shortcuts is that when you define a letter to do one action, if you some at some point you realize that this letter has been used already. And you want to change it is very hard. So you really have to, um, create a sort of philosophy behind a structure like many tools are doing different shortcut for doing sometimes stuff that are very similar.
So which one do you like the most? Which one do you prefer? So there is not like a standard way of setting shortcuts for a tool. And I think. If you try to copy too much a tool that already exists, you will end up in a nightmare because your tools is going to be different at some point and the shortcut logic for those tools is not going to adapt to yours.
So you have to create your own philosophy on shortcuts. a big challenge and a big discussion we have all the time, but, uh. It's, it's, uh, something that you have to involve people and discussions about like, okay, he's come on, triggering this or not. And sometimes we change, it's, it's happening that we can shortcut.
It's very rare. Um, and also you have to think that you always have different contexts. Like maybe if you're opening a new part of the project, we have some sort of that only adapt for this part of the project, but then if you're out there. So you have to make sure all the time that what are the possibility that I can use the shortcut, but we.
Trigger something that already is appearing on the screen. So that's that's always a big stuff We have to check but uh so far so good. We've been able to to provide the best experience. I think we can
Designing with keyboard shortcuts in mind
[00:16:41] Ridd: I don't actually have that much of a background designing tools. And so something that I was so curious to ask you about in this conversation was what it was kind of like designing for people who kind of live in your tool to an extent and are really power users. Because when I first. Downloaded linear and started using it at Maven.
Immediately. The thing you notice is that it's designed to kind of be a mouseless experience. You can accomplish essentially everything with keyboard shortcuts. And I've always kind of wondered what is it like for the designer to create a product where keyboard shortcuts are a first class citizen and how does that impact your process?
[00:17:20] Adrien: we have to think that also there are a lot of people using linear without using the shortcut, uh, I think majority of people. More they use the tools, more they will use shortcuts, because also a lot of tools out there don't provide you shortcuts by default. Some people, they kind of discover the shortcut later on.
So I always design any feature that you can, should be able to do it only with using your mouse anyway. And I think the, the shortcut part actually is a new layer I had on top of it. And, um, to make sure that it can go faster. Um, and also. I'm lucky to enough to work with a lot of engineers that love shortcuts.
So we always have crazy discussion on Slack on like which letter should we pick for that and that. And so like most of the time, this is like the cherry on the cake that we add on top. Like, okay, how now we design something that everybody can use with a mouse, but how we can make it even faster with shortcuts.
So that's, that will be mostly the process around it. But. Also, our goal is to make sure that we have people that are not engineers that want to use linear like this is basically for us, like now that we have bigger companies, you don't only have engineers in linear. So we want to make sure that also they're able to use the product, but we always try to advocate to them and look, you can also use shortcut and you will even like it more.
So that's, that's, that's the balance has to be there all the time, but we make sure that. It's, and yeah, for sure, if you're only thinking with shortcut, it's very easy to design something, uh, because you don't need to create a lot of interfaces for click. But we still design things for, for mouse only. So it's always in my head.
That's the way I do it always after, but not at the first place.
[00:18:55] Ridd: Okay, that's good to know. Cause I was kind of wondering that, like, do you have this map of all the shortcuts that you have to keep track of and where, like, is it something that it's kind of slapped on before shipping? Or is it kind of earlier in the process? Um, because it is, I get the idea that like you learn it over time.
Like I, I remember even multiple times in. The Maven Slack, where someone would be like, wow, did you know that you can use this shortcut to accomplish X? And then everyone would be like, Oh my gosh, like I'm going to start using that. And so we've, I, we've kind of matured in our own usage of the tool over time as well.
[00:19:26] Adrien: I mean, my role also as a non engineer is to kind of remind them. So although that we don't have only shortcut people using the product and I think I kind of forced myself to don't use them too much sometimes to make sure I don't forget that you also have to click on some button to access some things in the app.
Um, but it's part of the process when we ship a new functionality or when we improve something to actually make sure that they are shortcut accessible, um, all the time. So that's something that is. naturally part of the linear process on when we ship stuff and also sometimes we only have discussions also about how we can improve the shortcut system.
That's one of the issues I think that is the biggest with shortcuts is that when you define a letter to do one action, if you some at some point you realize that this letter has been used already. And you want to change it is very hard. So you really have to, um, create a sort of philosophy behind a structure like many tools are doing different shortcut for doing sometimes stuff that are very similar.
So which one do you like the most? Which one do you prefer? So there is not like a standard way of setting shortcuts for a tool. And I think. If you try to copy too much a tool that already exists, you will end up in a nightmare because your tools is going to be different at some point and the shortcut logic for those tools is not going to adapt to yours.
So you have to create your own philosophy on shortcuts. a big challenge and a big discussion we have all the time, but, uh. It's, it's, uh, something that you have to involve people and discussions about like, okay, he's come on, triggering this or not. And sometimes we change, it's, it's happening that we can shortcut.
It's very rare. Um, and also you have to think that you always have different contexts. Like maybe if you're opening a new part of the project, we have some sort of that only adapt for this part of the project, but then if you're out there. So you have to make sure all the time that what are the possibility that I can use the shortcut, but we.
Trigger something that already is appearing on the screen. So that's that's always a big stuff We have to check but uh so far so good. We've been able to to provide the best experience. I think we can
How Linear approaches their design system
[00:21:34] Ridd: recently posted something saying that design systems are the enemy of innovation. you explain that a little bit?
[00:21:40] Adrien: Me and Kari come from, he was lead designer at Airbnb, uh, when I worked at Microsoft also, like, design system was a big part of, like, the way we worked, um,
[00:21:50] Ridd: He was one of the very first people that introduced me to the concept. Like I remember reading his visual language posts, however many years ago that was, and he shaped a lot of my initial thinking, which is why I found your statement so interesting.
[00:22:04] Adrien: but to be fairly transparent with us, with you and, uh, we don't have a big design system, sadly now, um, the, one of the reason we don't have it is because we still think that the tools will evolve, uh, and, Thank you. As, as we are only two designers or like three designers for a very long time, we didn't have time to build anything like this.
And, uh, we are always aware that we might make bigger change in the UI and in the time to build a system that in the end, we might break in one or two days or two months. Is not worth it for us. And I think there are different stage of the company. We are scaling up in terms of design. So now we feel more and more the need to maybe having a proper design system.
And I think it makes sense for the stage we are entering now. But I think when you are very early on on your product, spending the time. Um, designing systems, uh, it's to me the time that you don't spend improving your product. So it's, uh, the, the philosophy behind there was that if you are alone or if you're one or two designer working on a product, the all the time you will spend designing the design system is the time that we're not building new things or improving the thing you already have.
And once you reach the stage where you can maybe have some time full, somebody full time in your team doing that, then you have product designer just doing product things. I think that. Shift makes sense, maybe, but I feel like, and I see that with younger designers I talk to, they are very excited about showing me their file with all their components in there.
But when I look at the product, I'm like, yeah, it's very different from what you're showing me now. And I think it's very hard if you are alone to maintain. Proper design system that look like the prod. Like most of the time, if I do small improvement, that will just take a screenshot of the app and just design on top of it, because in the end, what is the user looking at, like, okay, maybe your file look fancy and super nice.
But if in production, you don't have the same thing, uh, that there is a point for me, like everything that's happening behind this thing is nice. I'm very excited to see that happening. And I think we have better tools to do that. So for sure it's cool. But in the end, people looking at your productivity, what do they see?
And I think. That should be even, even more if you are early stage, really your focus on, like, what is the user experiencing every day and how you design on top of that. Also with real data, um, linear as a tool with a lot of text, a lot of data. So sometimes it's. It will take you forever to actually recreate a screen that already exists in the app.
Because you will have to create 1000 issues with a lot of projects, a lot of labels. So, yeah, you can just also grab a screenshot and edit it quickly and realize, okay, is this going to work or not? So, I think for us it's been... Very hard, uh, to create a proper design system that would scale quickly, uh, and that could have scaled the fastest way for us to build.
Um, and yeah, we didn't have the resources and actually we didn't feel the need to do it. So my, my feeling about that is really that It's not that you shouldn't do system. We have some basic font size, colors in Figma, like the very raw basic of what you do every day exists because it makes us faster when we design.
But if at some point you realize that your design system is just detaching components and then makes you actually slower than while you had an idea. The idea for me to the Figma file and to design file is that, Oh, you have a quick idea in your head. How fast can you make that existing to an image that you can share with the rest of the team and communicate your ideas instead of like how much time I will spend cleaning my files all the time.
I sometimes feel very. worried when I interview designer and talk about the clean file they create and all the like showing them all their buttons in the screen.
I'm like, Hey, that's, that's cool. Like you spend a lot of time on them, but can you demo something that is actually in production? Like, can you show me something that you actually build and people love? And that's, that's, that, I think that was an advice for young designer, build good stuff, uh, show stuff that are alive to people, uh, that will be, that's, that's why our job is the most important now, like the design, system and stuff is cool, but, uh, do you really do design just to create design system?
That's, uh, actually, that's not my perspective on things.
How Linear approaches their design system
[00:21:34] Ridd: recently posted something saying that design systems are the enemy of innovation. you explain that a little bit?
[00:21:40] Adrien: Me and Kari come from, he was lead designer at Airbnb, uh, when I worked at Microsoft also, like, design system was a big part of, like, the way we worked, um,
[00:21:50] Ridd: He was one of the very first people that introduced me to the concept. Like I remember reading his visual language posts, however many years ago that was, and he shaped a lot of my initial thinking, which is why I found your statement so interesting.
[00:22:04] Adrien: but to be fairly transparent with us, with you and, uh, we don't have a big design system, sadly now, um, the, one of the reason we don't have it is because we still think that the tools will evolve, uh, and, Thank you. As, as we are only two designers or like three designers for a very long time, we didn't have time to build anything like this.
And, uh, we are always aware that we might make bigger change in the UI and in the time to build a system that in the end, we might break in one or two days or two months. Is not worth it for us. And I think there are different stage of the company. We are scaling up in terms of design. So now we feel more and more the need to maybe having a proper design system.
And I think it makes sense for the stage we are entering now. But I think when you are very early on on your product, spending the time. Um, designing systems, uh, it's to me the time that you don't spend improving your product. So it's, uh, the, the philosophy behind there was that if you are alone or if you're one or two designer working on a product, the all the time you will spend designing the design system is the time that we're not building new things or improving the thing you already have.
And once you reach the stage where you can maybe have some time full, somebody full time in your team doing that, then you have product designer just doing product things. I think that. Shift makes sense, maybe, but I feel like, and I see that with younger designers I talk to, they are very excited about showing me their file with all their components in there.
But when I look at the product, I'm like, yeah, it's very different from what you're showing me now. And I think it's very hard if you are alone to maintain. Proper design system that look like the prod. Like most of the time, if I do small improvement, that will just take a screenshot of the app and just design on top of it, because in the end, what is the user looking at, like, okay, maybe your file look fancy and super nice.
But if in production, you don't have the same thing, uh, that there is a point for me, like everything that's happening behind this thing is nice. I'm very excited to see that happening. And I think we have better tools to do that. So for sure it's cool. But in the end, people looking at your productivity, what do they see?
And I think. That should be even, even more if you are early stage, really your focus on, like, what is the user experiencing every day and how you design on top of that. Also with real data, um, linear as a tool with a lot of text, a lot of data. So sometimes it's. It will take you forever to actually recreate a screen that already exists in the app.
Because you will have to create 1000 issues with a lot of projects, a lot of labels. So, yeah, you can just also grab a screenshot and edit it quickly and realize, okay, is this going to work or not? So, I think for us it's been... Very hard, uh, to create a proper design system that would scale quickly, uh, and that could have scaled the fastest way for us to build.
Um, and yeah, we didn't have the resources and actually we didn't feel the need to do it. So my, my feeling about that is really that It's not that you shouldn't do system. We have some basic font size, colors in Figma, like the very raw basic of what you do every day exists because it makes us faster when we design.
But if at some point you realize that your design system is just detaching components and then makes you actually slower than while you had an idea. The idea for me to the Figma file and to design file is that, Oh, you have a quick idea in your head. How fast can you make that existing to an image that you can share with the rest of the team and communicate your ideas instead of like how much time I will spend cleaning my files all the time.
I sometimes feel very. worried when I interview designer and talk about the clean file they create and all the like showing them all their buttons in the screen.
I'm like, Hey, that's, that's cool. Like you spend a lot of time on them, but can you demo something that is actually in production? Like, can you show me something that you actually build and people love? And that's, that's, that, I think that was an advice for young designer, build good stuff, uh, show stuff that are alive to people, uh, that will be, that's, that's why our job is the most important now, like the design, system and stuff is cool, but, uh, do you really do design just to create design system?
That's, uh, actually, that's not my perspective on things.
Avoid this mistake when applying at a startup
[00:26:28] Ridd: It's, it's a good thing to bring up. I mean, we've interviewed so many people at a similar stage in the company. And, you know, we started like six months after. And people would get into their portfolio presentations and just share this giant system file and look at all of my buttons. And actually it was, you kind of were digging yourself a hole a little bit that you would have to somehow sell yourself out of because it just doesn't really map that well to an early stage company a lot of the times.
And I love your comment about. Taking a screenshot of the app and designing something on top of it. That stretches me. But actually it makes a lot of sense because so often what happens when you're just heads down shipping in the early days is maybe you build 85 or 90% of what is in your Figma file and things get declared.
Okay, well, that's like a fast follow. We'll get there. Let's talk to, let's get some feedback first. And then like, how often do you actually. Go back and you run that playbook 10 times. And all of a sudden there are discrepancies between what is in Figma and what is in production code. And sometimes it actually takes more time.
Like I can think of specific pieces of UI in my head where. I actually had no representation of what was in production in Figma, because we just kind of shipped something and we never really justified going back to it. And it didn't even make sense for me to iterate within the context of my Figma layout because it didn't even exist in the real world.
[00:27:55] Adrien: the source of truth is what is important facing your user every day. Like to me, that's, and I know I was pretty hardcore also in the past when I was like applying to new company, but I was only sharing live product with them. And like in, when I walked on something that kind of change and disappear, I was not showing it in my for you anymore.
And I was just saying, okay, I worked on that back in the day. I have some screenshots now to share, but I always make sure I always add something that was actually live because Also, the role of the designer is also to talk with the engineer, make sure like the design is well implemented, discuss the last detail that are in production.
And I think that's also part of the job to make sure that what you decided to design and the way you made it will appear properly also in production and make sure like all the edge cases are well implemented and stuff. And I think that's also part of the role of the designer to make sure everything in production look good, look sharp.
Uh, and, and are relevant for people. So if a product live is very clean and very good, I think we also know that the designer behind the scene are like making sure that this will happen every day. And to me, that's way more important than actually your files, to be honest. So I think that's also one of the reason I, I feel like people should take more time reviewing what's live in that product because sometimes you have some sliding details that you can work on and I think that's, that's fine.
And it's better to work on those details than actually making them a fact. Um, and don't get me wrong, I think it makes sense to have those files because if you can design faster for them with those, uh, I think that's very good. Uh, if you feel like actually it's improving, you have an idea and you can sketch that quickly because you can import a few components and modify them.
That's, that's also very good. Uh, but when you are creating something new. You have to make sure that this will ship the fastest as possible. And, uh, you have also to take, it's okay to take shortcut. Nobody will know, uh, nobody cares and it's fine.
Avoid this mistake when applying at a startup
[00:26:28] Ridd: It's, it's a good thing to bring up. I mean, we've interviewed so many people at a similar stage in the company. And, you know, we started like six months after. And people would get into their portfolio presentations and just share this giant system file and look at all of my buttons. And actually it was, you kind of were digging yourself a hole a little bit that you would have to somehow sell yourself out of because it just doesn't really map that well to an early stage company a lot of the times.
And I love your comment about. Taking a screenshot of the app and designing something on top of it. That stretches me. But actually it makes a lot of sense because so often what happens when you're just heads down shipping in the early days is maybe you build 85 or 90% of what is in your Figma file and things get declared.
Okay, well, that's like a fast follow. We'll get there. Let's talk to, let's get some feedback first. And then like, how often do you actually. Go back and you run that playbook 10 times. And all of a sudden there are discrepancies between what is in Figma and what is in production code. And sometimes it actually takes more time.
Like I can think of specific pieces of UI in my head where. I actually had no representation of what was in production in Figma, because we just kind of shipped something and we never really justified going back to it. And it didn't even make sense for me to iterate within the context of my Figma layout because it didn't even exist in the real world.
[00:27:55] Adrien: the source of truth is what is important facing your user every day. Like to me, that's, and I know I was pretty hardcore also in the past when I was like applying to new company, but I was only sharing live product with them. And like in, when I walked on something that kind of change and disappear, I was not showing it in my for you anymore.
And I was just saying, okay, I worked on that back in the day. I have some screenshots now to share, but I always make sure I always add something that was actually live because Also, the role of the designer is also to talk with the engineer, make sure like the design is well implemented, discuss the last detail that are in production.
And I think that's also part of the job to make sure that what you decided to design and the way you made it will appear properly also in production and make sure like all the edge cases are well implemented and stuff. And I think that's also part of the role of the designer to make sure everything in production look good, look sharp.
Uh, and, and are relevant for people. So if a product live is very clean and very good, I think we also know that the designer behind the scene are like making sure that this will happen every day. And to me, that's way more important than actually your files, to be honest. So I think that's also one of the reason I, I feel like people should take more time reviewing what's live in that product because sometimes you have some sliding details that you can work on and I think that's, that's fine.
And it's better to work on those details than actually making them a fact. Um, and don't get me wrong, I think it makes sense to have those files because if you can design faster for them with those, uh, I think that's very good. Uh, if you feel like actually it's improving, you have an idea and you can sketch that quickly because you can import a few components and modify them.
That's, that's also very good. Uh, but when you are creating something new. You have to make sure that this will ship the fastest as possible. And, uh, you have also to take, it's okay to take shortcut. Nobody will know, uh, nobody cares and it's fine.
How Adrien collaborates with engineers
[00:29:52] Ridd: I'd like to talk a little bit more about that kind of QA process where you're really getting into the details of what is actually in code, because man, I've been using linear regularly for a while now, and there are no visual bugs that really stand out. And so I'd love to get more into what that looks like.
Like, how are you structuring those back and forth? How are you reviewing what's in production? What does it look like for you to give feedback to engineers? And. How do you kind of steward that process as an early designer?
[00:30:24] Adrien: I think the way I approach my work, um, is more to. I feel like 80% of my job is going to the trash, uh, most of the time. And I think my job is really to open new doors on, um, the thing we already have in the product. So most of the time my design will be very few screens showing up like, okay, this can look like that maybe.
And it could, uh, you, that's the way you would navigate to it. That's the way you will maybe use it. But then trying to give that in the hands of engineers very early on so they can start to build something maybe very scrappy that doesn't look like the design and maybe the design also because we'll work with a lot of data will end up being bad.
So the idea is to really start to work and by end with the design, the engineers very early on and implement those design on the go. That's why also I work with a lot of screenshots because maybe they will send me a first build. I will take this screenshot and say, Oh, actually this, what you did, actually, that looks better than what I did.
And it's not a top down relationship where like I send clean specs and they have to really integrate them this way. It's more like, okay, we are shooting at this direction with you. We start to building it together and then. That's a lot of back and forth. So I think the QA really happened at this moment.
And also we have this different way of shipping stuff to people. So we will ship it internally. Luckily we use the tool also internally every day. So we are really on top of like what's going on. And if we feel like something is weird, we try to fix it as up. and then when we do this back and forth, we like kind of releasing internally the feature.
So people start to use it also with the rest of the team. And that's where, like where we get a lot of feedback. And we always make sure that inside the company, if you don't like something in product, even if your role is like a sales guy or like support, you are able to actually adding a voice and have a deeply conversation.
And we have to justify why we did that. And that's why actually the biggest discussion happened. So the early use share. Uh, and you build the early, you will know if you are going the right direction or not. Uh, and sometimes, uh, I explore some design and we realize quickly that it's not going to work. So that I don't have to build the entire feature and tell the design.
I can just do one or two screen and realize, okay, this is going to be too much for now. Um, do the engineer at the time to do it, or actually it could be way simpler than what I'm trying to think about. So the QA really happened at this time, then we tried to build that with, uh, when we announced something in the changelog, most of the time it's kind of a feature you have to enable manually in Sandvina, so we have like. hardcore followers and linear users since day ones that really love to kind of review the feature for us sometimes too. So we got a lot of feedback for them. Then when we feel like it's been reaching that certain amount of users that we think will like this feature, we actually like release it with the public, uh, everywhere.
And then most of the time at this stage, we are pretty sure at like 80, 90% of the time that the future actually will work with most of the cases. that will not encounter new edge case and things like that. So we don't have a QA team inside. It's mostly us being in the Slack with the user all day, uh, checking Twitter all the time, make sure like everything is fine.
And there are some quick bugs. There are some tiny thing happening, but the, the answer is like, okay, but if the team is ready to fix those as fast as possible, actually less user will see them, but they do exist sometimes, but. We are, we always make sure that when something wrong is happening for user and prod, this is becoming now the first priority for us to fix it because this is people having bad experience with us and this is way more important that the new things we are building like we can if we have to postpone them a bit because working well, it's fine for us to make this, to take this decision.
And it's, uh, everybody in the team is aware that they should make sure the product is always right. So that's in the end, make us prioritize those visual bug and quit bug very easily.
How Adrien collaborates with engineers
[00:29:52] Ridd: I'd like to talk a little bit more about that kind of QA process where you're really getting into the details of what is actually in code, because man, I've been using linear regularly for a while now, and there are no visual bugs that really stand out. And so I'd love to get more into what that looks like.
Like, how are you structuring those back and forth? How are you reviewing what's in production? What does it look like for you to give feedback to engineers? And. How do you kind of steward that process as an early designer?
[00:30:24] Adrien: I think the way I approach my work, um, is more to. I feel like 80% of my job is going to the trash, uh, most of the time. And I think my job is really to open new doors on, um, the thing we already have in the product. So most of the time my design will be very few screens showing up like, okay, this can look like that maybe.
And it could, uh, you, that's the way you would navigate to it. That's the way you will maybe use it. But then trying to give that in the hands of engineers very early on so they can start to build something maybe very scrappy that doesn't look like the design and maybe the design also because we'll work with a lot of data will end up being bad.
So the idea is to really start to work and by end with the design, the engineers very early on and implement those design on the go. That's why also I work with a lot of screenshots because maybe they will send me a first build. I will take this screenshot and say, Oh, actually this, what you did, actually, that looks better than what I did.
And it's not a top down relationship where like I send clean specs and they have to really integrate them this way. It's more like, okay, we are shooting at this direction with you. We start to building it together and then. That's a lot of back and forth. So I think the QA really happened at this moment.
And also we have this different way of shipping stuff to people. So we will ship it internally. Luckily we use the tool also internally every day. So we are really on top of like what's going on. And if we feel like something is weird, we try to fix it as up. and then when we do this back and forth, we like kind of releasing internally the feature.
So people start to use it also with the rest of the team. And that's where, like where we get a lot of feedback. And we always make sure that inside the company, if you don't like something in product, even if your role is like a sales guy or like support, you are able to actually adding a voice and have a deeply conversation.
And we have to justify why we did that. And that's why actually the biggest discussion happened. So the early use share. Uh, and you build the early, you will know if you are going the right direction or not. Uh, and sometimes, uh, I explore some design and we realize quickly that it's not going to work. So that I don't have to build the entire feature and tell the design.
I can just do one or two screen and realize, okay, this is going to be too much for now. Um, do the engineer at the time to do it, or actually it could be way simpler than what I'm trying to think about. So the QA really happened at this time, then we tried to build that with, uh, when we announced something in the changelog, most of the time it's kind of a feature you have to enable manually in Sandvina, so we have like. hardcore followers and linear users since day ones that really love to kind of review the feature for us sometimes too. So we got a lot of feedback for them. Then when we feel like it's been reaching that certain amount of users that we think will like this feature, we actually like release it with the public, uh, everywhere.
And then most of the time at this stage, we are pretty sure at like 80, 90% of the time that the future actually will work with most of the cases. that will not encounter new edge case and things like that. So we don't have a QA team inside. It's mostly us being in the Slack with the user all day, uh, checking Twitter all the time, make sure like everything is fine.
And there are some quick bugs. There are some tiny thing happening, but the, the answer is like, okay, but if the team is ready to fix those as fast as possible, actually less user will see them, but they do exist sometimes, but. We are, we always make sure that when something wrong is happening for user and prod, this is becoming now the first priority for us to fix it because this is people having bad experience with us and this is way more important that the new things we are building like we can if we have to postpone them a bit because working well, it's fine for us to make this, to take this decision.
And it's, uh, everybody in the team is aware that they should make sure the product is always right. So that's in the end, make us prioritize those visual bug and quit bug very easily.
How to foster a culture that cares about craft
[00:34:26] Ridd: Layers basically become synonymous with craft and quality for so many designers. And what you just said was very interesting to me, where even as a startup, you're okay with prioritizing something that's already shipped, going back, making sure that it is excellent before moving on to the rest of your roadmap, what are some of the ways that that is reinforced?
Culturally, how do you have such a high bar for quality that everyone buys into? And you just understand this is how we are going to operate strategically.
[00:34:57] Adrien: I think it's coming from the hiring part. Uh, we, uh, everybody's that's. Work with us, uh, had to work with us for a week. Uh, that's part of the process. Everybody in the team had it since day one. they come in, work with us for a week, you have access to Slack, you have access to everything that as a regular employee, you will have access into Linear, and we kind of test you on something, um, we pay you for this week, so you're actually becoming a Linear Worker for a week, so I think that really starts from the hiring phases, where we want to make sure that everybody coming to the team also, uh, like product in general, that they have a love for it.
Nobody has to be the best designer or the best front end engineer in the world, but it has to actually have an eyes on things. And we know also from that, that how far we can push some people to take product decisions. And I think also on the everyday basis, if you're an engineer or designer and start off a project, you are making the decision, like you have to understand what you're building, why you're building it, like we make sure you talk to these users, uh, all our engineers like face support, once in they turn in terms of support.
So every engineer is facing support is facing real users every day. Understand also that when they ship something that's going to be seen by people and used by people. And we want to make sure that it's always in top of our mind that, yeah, we have happily people, everybody, every day clicking on stuff, uh, in linear, uh, or shortcutting stuff in there.
But yeah, it's, it's really. Uh, about the mindset of making sure that we always want to build the best product and that everybody in the team has a voice about that. So when you have a voice, that's why you also create discussions. So we take a lot of design decision in inner. So if you just joined the team, sometimes you're wondering why this, why this.
And then we start over those conversations with people. Oh yeah, this is why we did that. This is why we did that. And even starting those conversations, most of the time we have here that we are like. Yeah, I tell you why we did. We do that. So it's always about questioning yourself as an engineer, as a designer, as you always make sure that if you feel like this is there is something wrong.
If your intuition tells you that this is real, there might be a better way of doing it and actually taking the time to being able to express your ideas, having a discussion, facing feedback. And then most of the time there is always good stuff happening from that. So I think it's really about. Allowing people to feel like they are in charge of things, that they are responsible in what they think they do, so they have a voice, they can try things, or sometimes they are going to be wrong, but actually, if they are able to do that, and we push them to do that, I think they are becoming better and better at building products, and that's where, like The magic of the craft appears when you actually make sure you're working with people that care the same way you care about the product.
So there is no discussion about if a better decision is like a better solution. We found a better solution. We are sure that everybody would be excited to build it. So that's, I think it's a lot about convincing people about decision and also allowing yourself to change your mind. If you feel like, Oh yeah, actually this is a better solution.
And so it's a lot of discussions and make sure you discuss with the right people.
How to foster a culture that cares about craft
[00:34:26] Ridd: Layers basically become synonymous with craft and quality for so many designers. And what you just said was very interesting to me, where even as a startup, you're okay with prioritizing something that's already shipped, going back, making sure that it is excellent before moving on to the rest of your roadmap, what are some of the ways that that is reinforced?
Culturally, how do you have such a high bar for quality that everyone buys into? And you just understand this is how we are going to operate strategically.
[00:34:57] Adrien: I think it's coming from the hiring part. Uh, we, uh, everybody's that's. Work with us, uh, had to work with us for a week. Uh, that's part of the process. Everybody in the team had it since day one. they come in, work with us for a week, you have access to Slack, you have access to everything that as a regular employee, you will have access into Linear, and we kind of test you on something, um, we pay you for this week, so you're actually becoming a Linear Worker for a week, so I think that really starts from the hiring phases, where we want to make sure that everybody coming to the team also, uh, like product in general, that they have a love for it.
Nobody has to be the best designer or the best front end engineer in the world, but it has to actually have an eyes on things. And we know also from that, that how far we can push some people to take product decisions. And I think also on the everyday basis, if you're an engineer or designer and start off a project, you are making the decision, like you have to understand what you're building, why you're building it, like we make sure you talk to these users, uh, all our engineers like face support, once in they turn in terms of support.
So every engineer is facing support is facing real users every day. Understand also that when they ship something that's going to be seen by people and used by people. And we want to make sure that it's always in top of our mind that, yeah, we have happily people, everybody, every day clicking on stuff, uh, in linear, uh, or shortcutting stuff in there.
But yeah, it's, it's really. Uh, about the mindset of making sure that we always want to build the best product and that everybody in the team has a voice about that. So when you have a voice, that's why you also create discussions. So we take a lot of design decision in inner. So if you just joined the team, sometimes you're wondering why this, why this.
And then we start over those conversations with people. Oh yeah, this is why we did that. This is why we did that. And even starting those conversations, most of the time we have here that we are like. Yeah, I tell you why we did. We do that. So it's always about questioning yourself as an engineer, as a designer, as you always make sure that if you feel like this is there is something wrong.
If your intuition tells you that this is real, there might be a better way of doing it and actually taking the time to being able to express your ideas, having a discussion, facing feedback. And then most of the time there is always good stuff happening from that. So I think it's really about. Allowing people to feel like they are in charge of things, that they are responsible in what they think they do, so they have a voice, they can try things, or sometimes they are going to be wrong, but actually, if they are able to do that, and we push them to do that, I think they are becoming better and better at building products, and that's where, like The magic of the craft appears when you actually make sure you're working with people that care the same way you care about the product.
So there is no discussion about if a better decision is like a better solution. We found a better solution. We are sure that everybody would be excited to build it. So that's, I think it's a lot about convincing people about decision and also allowing yourself to change your mind. If you feel like, Oh yeah, actually this is a better solution.
And so it's a lot of discussions and make sure you discuss with the right people.
Why Linear looks for makers instead of executioners
[00:38:11] Ridd: You've mentioned now a few times this idea of a product engineer. And you've talked about how it's a very back and forth product process with engineering. It's definitely not waterfall. And even a lot of the strategy doesn't feel like it's super top down because there's a lot of ownership. Like I can tell that there's a lot of ownership amongst the people that are making the product to come up with the best decisions.
And I came across a different thing that you wrote earlier, which is you described linear's culture as being full of makers and not executioners. And I'm kind of hearing it even in everything that you're saying. And so I'm wondering for someone who's listening to this episode and envision themselves, maybe applying for some future role at linear, what are some of the ways that a younger designer could come across to you as a maker and not an executioner,
[00:39:06] Adrien: so. I will come back to I think what I think about myself. Um, I think one of the reason I walked in tech is because I think this is especially coming back from like maybe old school graphic design school where like print and stuff was involved is like, I think what I like about tech is that if you have an idea and you know a little bit of code or if you find a friend of you that know how to code, You are able overnight to create a product, create a landing page, put it out there, and actually face real market and users.
And I think that's A very unique industry in terms of being able to do that, because most of the time, if you have a restaurant, if you have whatever, it will take you months, years to actually build the product and then allow people to know about it and discover it. And if you made a mistake, you were not able to change it.
So I think by the fact that very early on, I always tried to build small business online by myself or with some friends. I really. Discover that, okay, you can do the best design, but there was still also copy marketing, how people will discover your thing. And I think when I see people as makers, I see people that, okay, I have a role.
I'm very good at design. I'm very good at engineering, but that doesn't mean that what I'm building is only that. It's also include a lot of other role, a lot of other problems that I don't maybe even know about. And. I think that if you have this kind of maker mindset, you're not afraid to actually try to do some copy, uh, even if that's not perfect, but actually, actually do it because you know, it's necessary.
And not just like when you design, do you use a lot of people? So more, do you try to come up with real text? Like that's to me the perfect example. No, if you do with Laura, so that means like, what are people going to write in your product? So maybe try to come up with real sentence that people might do in your product.
Then the design will change. So it's always thinking that actually you want to build something that yourself you will love to use. And if you take these statements, you're getting better on yourself to being like, okay, this needs to be improved. And maybe the thing I need to improve is not the thing I like to do, but they need to exist so the product could exist.
And I think that's when you swift, you swift that you also work better as a teammates, because if you're working with someone, so marketing that come back to you and say, Oh, look, actually this model, people don't see it. Why? Because it doesn't work. With what we are doing outside. And if you understand that product is a whole with a lot of different sections that will make as a glue thing together happen and actually excite people, you are actually getting outside of your role most of the time and in the decision you take and.
I think that's, that's really what I want to, to feel from people, uh, that like doing products in general. And then I say product, I'm including a lot of holes, but I think I want people to make sure that what they do is not just what they are paid or like, what is their role title is telling them, but actually to build the best product.
And if sometimes building the best product. Might make you want to learn something new or like discover that you have to do that instead of doing that you kind of going over The perception you have of this world because you're actually doing it So then you have even more respect or you know, which people you want to work with in the future because you know Like okay, I didn't know anything about marketing but when I start to market my own product I realize how hard it is sometimes so then when I work with marketing people I know which are the good ones or which are the one that's going to get me excited and so I think if you allow yourself to actually do stuff you don't like, or you do think you are not able to do it, that's why you are willing to be a maker.
Like you have to make something happen instead of just, yeah, I did my part. Uh, I don't understand. My design is perfect, but Muddy is using my product. Yeah, but what is the product, you know? So that, that's, I think that's the philosophy I got. And, uh, and, and this is sort of the mindset also, uh, the Founders of Linaire, Cary Thomas and Troy were looking into new people joining the team is like, do you have something, uh, that you build yourself or that like you, you run yourself.
So you understand what are the problematic of running a company. And I think it's a good advice for young designers that actually want to grind the market. Uh, I see it. Uh, I see that a lot happening online my life. Oh, yeah, I know I don't have any experience. So for sure people are asking for three years of experience, but I don't have this experience.
So how can I join? But nothing in tech is blocking you to build the tools on your own. And it doesn't have to be, uh, the new Facebook. It doesn't have to be, uh, the new Salesforce. It could be very something tiny that you just and your friend will use. It could be something that is very a prototype maybe.
And you want to get people excited on the landing page. It doesn't have to be even real, but actually building yourself things and putting out there. Make you realize all the problematic you will encounter as a designer. And actually it's a very nice project to present to people because you are the only owner, you have the, you take the decision, everything that happened in this product.
So until the marketing to the landing page, to the product itself, to the language you use. Uh, so I think that to me is the best thing you can display as a young designer to a founder that you want to work early stage because they are doing the same thing as you. And if they understand that you. I have a vision on those things that you are able to actually understand what is your role as a designer of building those things, you will get on the top list for sure.
So that's, that's, uh, really what I meant, but also build things, make thing. That's the best way to learn.
Why Linear looks for makers instead of executioners
[00:38:11] Ridd: You've mentioned now a few times this idea of a product engineer. And you've talked about how it's a very back and forth product process with engineering. It's definitely not waterfall. And even a lot of the strategy doesn't feel like it's super top down because there's a lot of ownership. Like I can tell that there's a lot of ownership amongst the people that are making the product to come up with the best decisions.
And I came across a different thing that you wrote earlier, which is you described linear's culture as being full of makers and not executioners. And I'm kind of hearing it even in everything that you're saying. And so I'm wondering for someone who's listening to this episode and envision themselves, maybe applying for some future role at linear, what are some of the ways that a younger designer could come across to you as a maker and not an executioner,
[00:39:06] Adrien: so. I will come back to I think what I think about myself. Um, I think one of the reason I walked in tech is because I think this is especially coming back from like maybe old school graphic design school where like print and stuff was involved is like, I think what I like about tech is that if you have an idea and you know a little bit of code or if you find a friend of you that know how to code, You are able overnight to create a product, create a landing page, put it out there, and actually face real market and users.
And I think that's A very unique industry in terms of being able to do that, because most of the time, if you have a restaurant, if you have whatever, it will take you months, years to actually build the product and then allow people to know about it and discover it. And if you made a mistake, you were not able to change it.
So I think by the fact that very early on, I always tried to build small business online by myself or with some friends. I really. Discover that, okay, you can do the best design, but there was still also copy marketing, how people will discover your thing. And I think when I see people as makers, I see people that, okay, I have a role.
I'm very good at design. I'm very good at engineering, but that doesn't mean that what I'm building is only that. It's also include a lot of other role, a lot of other problems that I don't maybe even know about. And. I think that if you have this kind of maker mindset, you're not afraid to actually try to do some copy, uh, even if that's not perfect, but actually, actually do it because you know, it's necessary.
And not just like when you design, do you use a lot of people? So more, do you try to come up with real text? Like that's to me the perfect example. No, if you do with Laura, so that means like, what are people going to write in your product? So maybe try to come up with real sentence that people might do in your product.
Then the design will change. So it's always thinking that actually you want to build something that yourself you will love to use. And if you take these statements, you're getting better on yourself to being like, okay, this needs to be improved. And maybe the thing I need to improve is not the thing I like to do, but they need to exist so the product could exist.
And I think that's when you swift, you swift that you also work better as a teammates, because if you're working with someone, so marketing that come back to you and say, Oh, look, actually this model, people don't see it. Why? Because it doesn't work. With what we are doing outside. And if you understand that product is a whole with a lot of different sections that will make as a glue thing together happen and actually excite people, you are actually getting outside of your role most of the time and in the decision you take and.
I think that's, that's really what I want to, to feel from people, uh, that like doing products in general. And then I say product, I'm including a lot of holes, but I think I want people to make sure that what they do is not just what they are paid or like, what is their role title is telling them, but actually to build the best product.
And if sometimes building the best product. Might make you want to learn something new or like discover that you have to do that instead of doing that you kind of going over The perception you have of this world because you're actually doing it So then you have even more respect or you know, which people you want to work with in the future because you know Like okay, I didn't know anything about marketing but when I start to market my own product I realize how hard it is sometimes so then when I work with marketing people I know which are the good ones or which are the one that's going to get me excited and so I think if you allow yourself to actually do stuff you don't like, or you do think you are not able to do it, that's why you are willing to be a maker.
Like you have to make something happen instead of just, yeah, I did my part. Uh, I don't understand. My design is perfect, but Muddy is using my product. Yeah, but what is the product, you know? So that, that's, I think that's the philosophy I got. And, uh, and, and this is sort of the mindset also, uh, the Founders of Linaire, Cary Thomas and Troy were looking into new people joining the team is like, do you have something, uh, that you build yourself or that like you, you run yourself.
So you understand what are the problematic of running a company. And I think it's a good advice for young designers that actually want to grind the market. Uh, I see it. Uh, I see that a lot happening online my life. Oh, yeah, I know I don't have any experience. So for sure people are asking for three years of experience, but I don't have this experience.
So how can I join? But nothing in tech is blocking you to build the tools on your own. And it doesn't have to be, uh, the new Facebook. It doesn't have to be, uh, the new Salesforce. It could be very something tiny that you just and your friend will use. It could be something that is very a prototype maybe.
And you want to get people excited on the landing page. It doesn't have to be even real, but actually building yourself things and putting out there. Make you realize all the problematic you will encounter as a designer. And actually it's a very nice project to present to people because you are the only owner, you have the, you take the decision, everything that happened in this product.
So until the marketing to the landing page, to the product itself, to the language you use. Uh, so I think that to me is the best thing you can display as a young designer to a founder that you want to work early stage because they are doing the same thing as you. And if they understand that you. I have a vision on those things that you are able to actually understand what is your role as a designer of building those things, you will get on the top list for sure.
So that's, that's, uh, really what I meant, but also build things, make thing. That's the best way to learn.
Deep Dives
Get every episode
Free lessons from the top designers 👇
Fonz Morris
Lead monetization designer @ Netflix
Mia Blume
Past leader @ Pinterest, Square
Jorn van Dijk
CEO @ Framer
Femke
Design lead @ Gusto
Kenny Chen
UX lead @ Google
Join 8K+ designers
HC
HC
HC
HC
Ⓒ Dive 2023
