Brian Lovin, product designer at Github and previous co-founder of Spectrum, talks to Maze about his design journey, starting with the early days at Buffer to then co-founding Spectrum and his current role at Github. Topics include the decision to fundraise or go the bootstrap way, the ability to say 'no' to customers, and the importance of being surrounded by great people for making smart product decisions.
The Optimal Path is a podcast about product decision-making from the team at Maze. Each episode brings in a product expert and looks at the stories, ideas, and frameworks they use to achieve better product decision-making—and how you can do the same.
You can follow Brian on Twitter (@brian_lovin) or check out his website.
Follow Maze on social media:
To get notified when new episodes come out, subscribe at maze.co/podcast. See you next time!
Ash Oliver:
Welcome to the Optimal Path, a podcast about product decision-making brought to you by Maze. I'm your host, Ash Oliver, UX Designer & Design Advocate. Great products are the result of great decisions, decisions that deliver value for customers and the organization. In this podcast, you'll hear from designers, product managers and researchers about the ideas and forming decision making across all aspects of product development.
Ash Oliver:
Today, I'm joined by Brian Lovin. Brian wears many hats. He's a designer, podcaster, writer, and software tinkerer. He's currently a product designer at GitHub, and before that, co-founded Spectrum.chat. Brian, I'm so stoked to talk to you today. Thanks for being here.
Brian Lovin:
Hey, thanks for having me. It's good to be here.
Ash Oliver:
We're going to get into deep detail about your expansive career path, inclusive of your side projects that have been following you along the way. I want to hear about your life as a product designer and also as a founder, but I thought maybe we could start by hearing a little bit more of the personal founding story and what led you into design.
Brian Lovin:
Yeah, sure. I'll pull out a couple of key moments when I was in middle school and high school. Like some key moments that stand out are the first time I ever wrote HTML in a text document and previewed it in the browser. Right? And this magic moment of, "Oh my God, I can do an inline style background colon blue and the web updates, and it's in my browser and I'm a magician." So that's a key moment where I could write code and see it come to life in some way.
Brian Lovin:
That maybe transferred into NeoPets in Myspace land. So NeoPets for people who don't know was where you could raise virtual pets. We've almost come full circle here in 2021 with CryptoPets and stuff. On NeoPets, you had a profile and you could insert custom CSS. And so that was my exposure to, "Wow, there's something that somebody else has put onto the internet that I actually have some creative license over." And I was really into styling my profile and people would create themes and share those themes and sell them and build communities around them. That was really cool.
Brian Lovin:
I guess, maybe very similarly, another moment that stands out is creating Myspace themes, early MySpace days, of course, you could literally just destroy your profile with your own CSS. It was a free for all, but that was fun. Anyway, so that was my journey into just tinkering on the internet. I would say that led me into creating websites, which led me to creating blogs. This was in high school, and towards the end of high school, I created a website called the Kollection, spelled with a K, it was like a music discovery website.
Brian Lovin:
So I ran that for five years, all the way through college. It was very fun, exciting, but that period was when I went from blogging to being more interested in the software behind the blog like, "How do we actually grow this? How do we build it in a more organized way? How can we build experiences on top of the blog that make this more fun and interesting to use?" So we were one of the first blogs that introduced a persistent audio player that would follow you around as you navigated around, and this was on WordPress. So there was some really interesting custom hackery going on there.
Brian Lovin:
And I would say that was the side project that really helped me build enough of a portfolio that I got the attention of Joel and Leo at the time, the founders of Buffer, and so that was my first product design job, and I worked at Buffer. I was the first full-time product designer. This was in 2013 maybe, and I worked there for a few years.
Brian Lovin:
Then I went and worked at Facebook for a little while, and then I left Facebook to start a company with a couple of friends, Bryn Jackson and Max Stoiber called Spectrum. Then Spectrum was acquired by GitHub in 2018, and I've been at GitHub since then. So almost three years.
Ash Oliver:
I'm sure that we'll get to this in our conversation, but how many of your either side projects were career endeavors had started by, I'll build a better X, Y, Z?
Brian Lovin:
Yeah. Yeah, of course. Yeah, they've always been, I have this itch that I want to be scratched and the existing solutions suck and little bit of like, I don't know, arrogance. I think I can do that better than somebody else who's thought about this way longer than I've ever thought about it, but I bet I can do it better. You get a little ways in and realize, "Oh, actually it was quite challenging. I understand now why maybe other solutions have been subpar up until now." But I think it's that process that is still worthwhile to go through.
Ash Oliver:
Yeah, absolutely. Well, can you talk to me about the inspiration and those very, very early days of coming together around Spectrum?
Brian Lovin:
Yeah, sure. The context here is in 2014, 2015 is when I started recording the Design Details podcast with Bryn Jackson, and around the same time, another person on the internet named Jonathan Cutrell started a podcast called Developer Tea, and we launched around the same time and we had fun chasing each other up and down, it felt like technology charts of ... This time it was the iTunes podcast section, right, before the podcast app. We reached out to Jonathan, and it just felt like a cool match. Right? Like we're designers, you're a developer talking about developer stuff, wouldn't it be cool if we could send each other listeners and build a little bit of a community together?
Brian Lovin:
And so that's what led to us co-founding Spec.fm together. So Spec was a podcast network for designers and developers. We ended up with like 10 shows on the network, couple of design, mostly developer podcasts. One of the things that we did alongside the network was, have a Slack workspace for our community. This was, again, quite a while ago, to the point where Slack was still up and coming. It wasn't really an established thing, and this was also at the time pre Discord being a big thing, there weren't a whole lot of community, forum-y kind of software options on the marketplace.
Brian Lovin:
So we chose Slack, and Slack was okay, it's good for presence and knowing that people are online and you get some real time chat, but you end up answering the same questions over and over again. There's very little outside discovery, you can't really Google for content within a Slack channel. We wanted to be a little bit more accessible to the web. So we looked around at our options which at the time was Slack discourse, which is forum software, open source forum. There was Facebook groups and they all had these trade offs of like, "Okay, well, discourse is the most forum-y and can be indexed on Google, but we don't like the way it looks, we don't like the way that we would customize it, it doesn't feel like it has a good presence.
Brian Lovin:
Not a lot of people use Facebook these days and Facebook also isn't accessible to the outside web in the ways that we want." So we're just looking at the options. They all sucked, and we just decided, "You what? I think we can build our own and do better." That was the start of Spectrum. So Bryn and I were working on that, and then Max Stoiber, he is a prolific open source developer, most notably known perhaps for styled components, and he had a very similar problem.
Brian Lovin:
So we were using styled components to build the first version of Spectrum, we were talking to Max, Max was telling us how he has the exact same problems with community management and communication for the styled components community, and so that's how we all paired up. That was the three of us, Bryn, Max and myself. And we set out to build better, I guess we called it forum software, maybe just chat software for large public and distributed communities on the internet.
Ash Oliver:
Beyond the initial ideas, can you describe for me what it was like coming together? Like was it organized chaos or was it ... Do you really have defined roles as to how everybody was going to play a part? You said this was your first major transition into running your own company.
Brian Lovin:
Well, we actually waited into it, I think in a smart way. So at the time I was working at Facebook, Bryn was working at Figma, Max was working at a place that I cannot remember the name of, I'm very sorry. We all had full-time jobs. When we started working on Spectrum, Spectrum also was a side project. So our approach was, we're going to build a beta on nights and weekends and get it out there and just see if people want this. We had the perfect test group, which was at the time, the Slack channel or the Slack group for the Spec.fm community. That's what we did. We built the side project, or the beta. I think it took us two ish weeks to build the first version. It was very hacky, it was very bad.
Brian Lovin:
We built it on top of fire base, which had made it really easy to stand up and ended up having some more constraints down the road. But we did all this while we had full-time jobs. So at this point we hadn't committed like, "Oh, we're going to go start a startup." No. We put the beta out, people liked it, people used it, we were having fun building it. And what happened, at least for me was it became the thing that I couldn't stop thinking about, nights, weekends, I would dream about it, I would be in meetings at work daydreaming about it. It was just this thing that I could not wait to get home every day, open my laptop and start building.
Brian Lovin:
When you have that feeling for weeks on end with the same idea, that was just a sign. So anyways, with the beta out in the world, people are using it, and that was enough, that gave us, the three of us, enough confidence to sign a pact where I don't know that we actually signed anything, but we all kind of agreed. "All right, let's do this. Let's all pick a day that we're going to quit our jobs and go start working on this full time." That's what we did. I remember very clearly the day that I told my manager I was leaving, we had a conversation. I'm like, "All right, meeting's over." I walk outside, call Bryn right away. We're both like, "Did you do it?" Yeah. We both quit, something like that.
Brian Lovin:
We all quit around the same time, and then we were off. But I felt like we had de-risked it a little bit. I'm not a huge fan of this mythology of like, "You got to quit and then just go build something from scratch." I think there are more pragmatic ways to get into a startup. De-risk a product, build it on nights and weekends, get early users and feedback without necessarily sacrificing your primary income. That seemed to work for us at the time.
Ash Oliver:
Yeah. That's amazing. Can you talk to me a little bit about what it was like testing it? So you said that you built it, you put the beta out there. How long was that process for and what specifically were you necessarily looking for that really solidified the de-risk?
Brian Lovin:
I wish I could say we were really scientific about it, but we weren't. I think there was still just a lot of gut feel here. We built the beta in a two or three weeks maybe, and we told our Slack community about it and people moved over and started using it. I think we just looked for, are people using it and then using it the next day, or are they coming back in a way that we can tell? Are we having conversations with the same people?
Brian Lovin:
So I guess that was one sign. Another thing, we had a list of things that we wanted to accomplish, that we felt like the other products in the space weren't accomplishing. Right? Like Slack was great because it was real time, but it was a walled garden, you couldn't Google anything. Same with Facebook, not real time, but you couldn't Google for anything, wasn't accessible to the outside web.
Brian Lovin:
So what we were looking to build was something that was firstly accessible to the web. We knew that organic search engine growth was going to be one of our main drivers for new users and discovery. So we wanted to build that, but we recognized how important presence was and feeling like people are online at the same time. So we tried to thread this needle, and honestly, I'm not sure that we ever got there. I think this is where every community product struggles today is, how do you get a good mix of sync and asynch communication?
Brian Lovin:
And Slack ends up with threads, Discord ends up with threads, I'm not sure that Facebook has a good real time option alongside their posts, but everyone struggles with this. Especially when you're working with communities who are all around the world, they're spread across multiple time zones. You need a way for people who are online at the same time to feel connected and feel like they have that back and forth right away. But if an important conversation comes up that you want to be discoverable to the outside web or for people to be able to chime in on later, need a way to extract that into a post or something that has a discreet URL, that people can reference in the future, search for really easily.
Brian Lovin:
So those were some of the ideas that we were trying to build out and prove. And again, I'm not really sure we ever quite got it right, but that's what we wanted to do. So for us, every conversation, I guess, was a thread that had a URL that was indexed by Google. We indexed chat messages, which was like a whole other technical challenge to figure out how to do that in a way that actually makes sense. And eventually, towards the end, we experimented with having side rooms. We called them water cooler chat rooms, where it was only peer chat, and then if you wanted an actual discreet thread with the URL, you had to go somewhere else. Those were some of the ideas we were poking at.
Ash Oliver:
Well, it sounds like you had a really good understanding of who you were designing for. Did that primarily ... Like talk about also like gut-feel, did that primarily come from research that you were doing or interacting with the groups that you had in the Slack community, or how did you get that clarity around what you were going after?
Brian Lovin:
Well, ultimately it was a problem that we had ourselves, and I've found this throughout my career. I really like working on, not only products to solve a problem I have personally, but also products that I use to build the product. Right? It's like we would use Spectrum to collaborate and talk about how we were going to build Spectrum. Same thing with Facebook, you use Facebook to build Facebook, GitHub, you use GitHub to build GitHub. It's like this is a pretty consistent theme for me. There's trade offs.
Brian Lovin:
There are downsides to working in that style. Right? Like you can become perhaps insulated from the outside world and the changing landscape, or you just prioritize your own needs over perhaps changing customer expectations. So there are some trade offs, you got to be worry of that. But for us at Spectrum, we all had this problem, and the people who were coming on board at the beginning were designers and developers in our community. And we knew who they were, and we understood what designers want to talk about and what developers want to talk about. Right? Like developers want a way to type code. Okay, we're going to build a way for people to type code, and that's better than at least at the time, what Slack and Facebook groups and other products like that offered.
Brian Lovin:
That was helpful. We knew who our audience was, and then we were also part of that audience. Ultimately, I think at some point we strayed from that, and I think that was one of our mistakes in hindsight. So as Spectrum grew, we tried to make it generalized for any kind of community. We said, we want not only designer and developer communities, but why not cooking communities and music communities and art communities and all this kind of stuff? And the problem that we encountered is, we didn't know how to market ourselves, we didn't know how to pitch the product, we didn't know how to prioritize features.
Brian Lovin:
So for example, developer communities have a different set of expectations around tooling and functionality. Right? They want GitHub integrations. And design communities, perhaps slightly something else. They want a way to preview Figma files in line, or be able to embed a Framer prototype. And then of course, every other community wants different kinds of things. Right? And so, because we tried to prioritize, I guess not prioritize any particular kind of community, but rather build a generalized solution for any kind of community, we ended up building just a lot of product. We built a lot of one off features for different communities who asked for different things.
Brian Lovin:
And ultimately I think this led to a little bit of feature below, or at least what ended up happening is, we built a lot of V1s of features that never really got the V2 iteration. Because remember it was just three of us this whole time. So, a good example is one community wanted analytics. They wanted to know who's most active. Who's the most helpful contributor, how many posts are being created per week. And so we go and we build an analytics dashboard and then that analytics dashboard is just stuck forever in V1. We never get back to it, and like some other communities never asked for that. They don't care about that. So we never got to build features for them.
Brian Lovin:
Anyways, we didn't have enough focus on building a really great sticky and core experience, and instead we prioritized a lot of one-offs, and this is really hard. I mean, I think everybody struggles with this. At least I still struggle with this today. Like you will hear from a customer that has a very compelling case for why a feature should exist. Right? They will say, "I encounter this problem with GitHub or with a GitHub mobile apps, like please solve it with this." And you as a designer, your brain immediately goes into solution mode. You're like, "Oh, I bet, we could just add a toggle here, and it would do that, or we could just put a button here and you would do that." And multiply that by a few months, a few dozen customers, and you just have shit all over the interface.
Brian Lovin:
And it takes a lot of discipline to synthesize lots of different kinds of customer feedback into a more appropriate solution or even harder still is telling customers that sounds really useful, and I know that you need that to use our product, but we're not going to build it. Sorry. At least I never got to the point of feeling super comfortable saying that. So we'd be like, "Yeah, yeah, we'll get to it. We'll get to it." And then we'd try and spin up a really shoddy first draft of it and then ship it to him and move on.
Ash Oliver:
Well, what you're talking about here is like so applicable. I mean, like it's exasperated in my mind by thinking of the three of you trying to go accomplish this very wide endeavor but absolutely is applicable to enormous teams and companies, because as you said, it just multiplies, if the big team is maybe resourced to be able to build more things still doesn't matter if they're just Frankensteining things together. I'm curious about when you noticed that this was a problem at Spectrum, did you all come together on that or was it a slow burn? When did you recognize that this was occurring?
Brian Lovin:
That's an interesting question because Spectrum was working, it was growing quickly. We were onboarding big communities for people who were around. Like we had, I think, Figma had their official community on Spectrum. We had a huge community for Sketch, for Framer, for React. Like some of these communities had 10, 20,000 members, very active. They were growing. We were seeing a huge amount of traffic from search engines and we were growing organically. Things were working. It's really, really hard to tease this apart, like where the mistake was. But I think one thing that we did, which maybe slowed us down or caused us to second guess ourselves was we tried to monetize fairly early and we never really figured out monetization.
Brian Lovin:
And I don't know, there's a meme in Silicon Valley. It's like, "No revenue your startups valued at $10 billion. And as soon as you have some revenue you're valued at five times that." So, we tried to make money early to the point where we were making like a few hundred dollars a month and that suddenly became an interesting metric for us to try and move. And we wanted to become sustainable and we wanted to become profitable. We didn't want to be an ad model. We didn't want to necessarily go too deep down the VC billion dollar or bust path. And monetizing community products is really, really hard.
Brian Lovin:
Like a lot of the community products that exist out there today, maybe some of them are making some money, but they're certainly subsidized by venture capital because you have to hit a certain amount of scale to have enough people on the platform where it's sticky enough that they're going to eventually pay for features or whatever, like Discord Nitro and all these kinds of things.
Brian Lovin:
Yeah. I don't know. Pricing is hard. And my hunch personally is that we focus too much on monetizing and becoming profitable too early. We were also perhaps irrationally opposed to ad models, which made it even harder for us. So to bring all this back to your original question, like when did we start noticing that things weren't working. It wasn't ever really clear that things were, or weren't working because the pricing monetization stuff wasn't, but the product was growing, and people were using it and we were getting great communities on board. So we always had this little bit of attention. Yeah.
Ash Oliver:
Is there any advice that you would give to people that are facing themselves in that conundrum?
Brian Lovin:
Oh, I mean, maybe the cliches, focus less but better, make sure the core product is good. Right? Like those kinds of things. I think maybe an important lesson that I don't know that we ever totally agreed on was, what do we envision the long term of this company to look like? So for example, if you want to go out and do the billion dollar or bust venture capital model of building a company, that's totally fine. You should just have it in your head ahead of time that this is the route road you want to go down. Right? Like, "Okay, I'm going to go raise a seed round and it's going to get me to some point where I can hopefully raise an A, which will get me to some point to hopefully raise a B."
Brian Lovin:
And once you're on that train, you're either looking for a huge acquisition, you're IPOing or I don't know, magically, you start making hundreds of millions of dollars. Like that is a path. Another path is the indie hacker route. I don't know if you're familiar with like indiehackers.com and like the bootstrap model where a lot of people would prefer to have a team of three people running a business that makes a million bucks a year, which is pretty respectable, but like, "I don't need to be a billionaire, I can be very happy making a hundred thousand dollars a year and being in full control of my business, having really little overhead, not having to manage a huge team, dealing with investors and that kind of stuff."
Brian Lovin:
I don't know, this is all hindsight. Right? At this point, this is four years ago. But I think at the time we weren't really sure what we wanted to do. We started out, bootstrapped. We bootstrapped ourselves for about six months, but then we raised the seed round, actually pre-seed, we raised close to half a million bucks. And then we tried to raise again towards the end. And we had not the most convincing pitch for that raise. I think we were trying to pitch to investors who were expecting us to become the next Twitter or the next Facebook, but we weren't even sure if we wanted to do that. So there's just some lack of clarity on what we were actually striving for, what we wanted the final outcome to actually be.
Brian Lovin:
So, advice for people is, think about that. What kind of business do you want to run? What kind life do you want to have? Do you want to go big or bust, or do you want to try and build slow and steady? And the slow and steady route has its own challenges. Right? Like you have to solve monetization earlier. You have to have revenue and strive for profitability, and that might lead you to build a different kind of product, like a consumer app that relies on scale to build an ads-driven business model, might not be the best thing to bootstrap, but something else that you sell to businesses for $50 a month, a hundred dollars a month, that provides a service or utility that is very clearly adding value to that business, and they wouldn't even blink it paying for, that seems totally reasonable. So, yeah. That's another thing to think about.
Ash Oliver:
So then coming up to the point of the acquisition, what stands out to you about that moment? Did GitHub approach you? What was that like?
Brian Lovin:
Yeah, I mean, at a high level, a huge percentage of anyone who had ever joined Spectrum was a developer. Our biggest communities were developer communities. And so we started talking with GitHub because GitHub of course is also a community of developers. There's a huge social element to GitHub with user profiles. And of course, conversations that happened in repositories. This was before GitHub discussions. But until now, people were having community conversations on issues and a lot of people would create Slack teams for their repos. So, there was already a lot of community activity happening on GitHub, and we had built a product that had a lot of developers on it.
Brian Lovin:
So, that's when we started talking and why it made sense as a fit. And then why we ultimately, ended up with GitHub is, I mean the three of us independently use GitHub, loved GitHub. We talked about like, as soon as an acquisition's on the table, you got to consider alternative options. What are other companies that we might want to also shop around to, talk to, learn about their teams, just to make sure we're not just falling in love with the first option that we find. And we went down that path a little ways, but independently, each of us wrote down companies we would ever want to work for, teams we would ever want to be a part of, products we would ever want to build. And independently, all three of us, but GitHub is number one.
Brian Lovin:
And so, these boxes all just got ticked, right time, right place. We had a product that was relevant that GitHub was trying to invest more in that space, and we all just loved the team and enjoyed using GitHub. That's ultimately what took us down that path?
Ash Oliver:
Well, what happened once the acquisition went through? And I believe that you joined GitHub under the mobile projects team. So what was it like being on the inside after the acquisition?
Brian Lovin:
I don't know. Well, we joined and we made our announcement post and I think it was at the top of Hacker News and our servers melted, our database crushed under the load, I spent the first week at GitHub, extremely tired in a haze. I was just fighting fires 24/7. Everything was crashing. It was really embarrassing. It was not fun. I wouldn't wish this upon anybody. When your servers crash ... I'm not a backend engineer, but it's the three of us. Right? The database is offline, Max lives in Europe, he's asleep. I've got to go figure it out.
Brian Lovin:
It's funny. Those moments where you are the only one who has the power to fix something, are moments of huge growth. Those were the moments where I learned a lot and actually developed as a developer, like I learned how to code by just being in situations where if I don't fix it, it's going to be offline for eight hours until Max wakes up. And of course, a lot of times I would have to wait eight hours until Max woke up to come help me. So anyways, we joined, first couple weeks, incredibly stressful.
Brian Lovin:
Spectrum, we had a really interesting transition within GitHub, Spectrum existed, it continued to grow, but pretty soon after I joined maybe a couple of months, I found myself drawn to a new project, which was the mobile apps. The time GitHub didn't have mobile apps, they had tried in the past, and there was talk about reviving that effort. There was an open source project by a fellow named Ryan Nystrom called GitHawk, which is an open source iOS app to interface with all of your GitHub stuff. And I heard rumors through the grapevine that GitHub was going to acquire his project.
Brian Lovin:
And so, I just got interested because I had some mobile experience working at Facebook. I like designing for mobile. I think it's incredibly fun. And it's like, "Oh, what if I could do mobile, like GitHub? That sounds great." So I started just pestering the people in that process. There's a lot of stuff happening in those first six, eight months, but what came out of it was, had my foot in the door on the mobile apps, was really excited about mobile at GitHub. They did acquire that open source project GitHawk. And so Ryan and I just started working together, brought on some great mobile engineers. We built the team and the first version of the product.
Brian Lovin:
And I think it was around a year after I joined that we announced the beta to the world, universe, which is GitHub's conference every year. So anyways, that's how I ended up on the mobile team, and have been working on that ever since.
Ash Oliver:
I'm wondering just as we finish up the conversation around GitHub before I bring you to our fast five segments is, has the decision making process for you ... I'm sure obviously the environment is entirely different, it's no longer the three of you, you're part of a much larger team now, but has the decision making process and how you think about coming to decisions changed since your time at Spectrum and now at GitHub?
Brian Lovin:
I would say it's changed. I have a better sense of what to look out for that could be a mistake or a sense of going down the wrong path. I think the thing that stands up most of my mind, which is just still incredibly tempting to solve problems for people who reach out and request a feature, I still find that to be incredibly satisfying to go and solve that particular person's problem. And it requires a lot of discipline to not and to wait, look for the right abstraction, say the biggest area.
Brian Lovin:
One of the biggest areas where I've leveled up at GitHub is thinking about using design as leverage and looking for opportunities to build leverage into your products. So rather than building five features that do five different things, is there an abstraction that would allow you to build one feature that would enable those five user intents to be possible?
Brian Lovin:
Anyways, that's what I like to think about a lot at mobile. Like where are areas for us to build better abstractions, so we don't have to just keep adding buttons and widgets and sliders and all this kind of stuff, but rather tools that create more, tools that solve more problems than just one specific user's need. Still very hard.
Ash Oliver:
Well, I mean, it feels like to me, listening to your story, that it's connected to the learnings that you had at Spectrum of not going too wide in the path and really being very clear around what you're solving for.
Brian Lovin:
Yeah. I mean, a good example of that is, if you look at GitHub at the time was a 10, 12 year old product. So the question was, what should we build on mobile? Do we just recreate everything? And we did have to really focus in and think about what do people want to do when they're on their phone? What would people want to do on GitHub on their phone? And you can pretty quickly whittle away a bunch of edge cases or setting screens or different stuff that exists on github.com where it's like, "Actually that thing only really makes sense when you're on a keyboard and you want to be typing code or doing something more complex."
Brian Lovin:
When you think of the phone, it's like, "I want to open it for 10 seconds and leave a quick comment. Or I want to just be alerted with a push notification that something has happened or needs my attention." So you really quickly narrow in on those functions. And so that's why we support things like notifications issues, poll requests and not a whole lot else. And that lens of everything that happens on GitHub, what makes the most sense on the phone has been really useful and has helped us say no to a lot of things.
Ash Oliver:
I'm sure that there's been more people involved in that process, but something that really stands out to me about you is that you're incredibly good at that abstraction process. Being able to really not just take the problem, but understanding the root question and then going out and figuring out how to solve that.
Brian Lovin:
I'll peel back the curtain a little bit, surprise, it's actually just being surrounded by a lot of really smart people who we all talk in spiral towards the truth together. I think the only way we arrive here at decisions that end up being good are because design, engineering, product, leadership, like everyone is whittling down an idea into something that is more pure and true and correct.
Brian Lovin:
My first intuition's always wrong, but as soon as I show it to some engineers, show it to some other designers, get some feedback from a customer, like that's where you whittle it down. And I really do like that phrase spiraling towards the truth. It is a reminder for me that a lot of the things I design will get scrapped and we might see a new variant of that emerge in the future, but that new variant, even if it looks the same and feels the same, is being designed with a lot more context and history and prior art, and is hopefully slightly closer towards the center of actually solving a problem for a customer.
Brian Lovin:
And you only get there by iterating a lot, being wrong a lot, throwing dumb ideas out a lot. You just want to be surrounded by people who will call you out on that, who are willing to jump in the ring with you and explore the dumb ideas until hopefully something good emerges. So anyways, it's funny that you have that perception of me, because from my point of view, it's like, "I can't do this on my own." I'm just so lucky to be with really smart people who are fun to collaborate with.
Ash Oliver:
Before I let you go, I'm going to ask you these fast questions. These are general questions that I ask everybody here, and you can answer in as much detail as you'd like. The first thing that I want to know is, what's one thing that you've done in your career that has helped you succeed, that you think very few other people do?
Brian Lovin:
I'm sure I could think a little bit longer and come up with a more eloquent answer here, but I will just say learning how to program.
Ash Oliver:
I love that. It's an endeavor that I'm pursuing myself.
Brian Lovin:
It has opened more doors for me, has helped me grow as a designer, has helped me get promotions, has helped me think about software in a different way. I am a better designer for knowing the materials that I'm designing for. Right? I don't think it's a prerequisite or a requirement, but all I can say is, it has certainly made everything I've done possible. So I'm very happy that I learned and continue to learn programming. Highly recommended.
Ash Oliver:
That's huge. Next question is, what is the industry related book that you've either given or recommended the most?
Brian Lovin:
I don't read a whole lot of design books. I listen to some design podcasts and read some articles and stuff. A book that I've come across recently that I really enjoyed and think I convinced everyone on my team at GitHub to buy it. I hope some of them read it, is a book called Orbiting the Giant Hairball: A Corporate Fool's Guide to Surviving with Grace. And it's by this fellow, Gordon MacKenzie, who worked at Hallmark.
Ash Oliver:
Hallmark Cards?
Brian Lovin:
Hallmark Cards. And he was high up in the corporate, like ladder there. I don't know how to really describe this book. The title is the point. Organizations are messy, processes are messy, they are this hairball. He talks about how to thrive at work is to not become stuck in that hairball, but rather to orbit it. Right? That hairball has gravity. Your company has HR systems and hiring processes and payroll, and things that has figured out that are messy, but they work. It is a solid core structure. My goal as a designer is to orbit that and use that gravity to move faster and get momentum without necessarily getting sucked in and stuck in the weeds.
Brian Lovin:
It's not an ebook, you have to buy the physical version of it, because the book itself is an artifact, the design of the pages is an artifact. It's illustrated with some wild drawings and visualizations. It's very short. I think you could read it in a couple of hours. Man, just even talking about it now, I'm like, "Wow, I should go reread that book." But that was the most recent book where right when I put it down, I just went and messaged all my coworkers. I said, "This is what we all need to be doing." I hope some other people found it useful.
Ash Oliver:
Oh my gosh, I love that. Yeah. I've never heard of it, but I'm absolutely going to check that out. All right. Last two questions, Brian. What's an unusual ... this is one of my favorite questions specifically that I was looking forward to asking you. What's an unusual habit or an absurd thing that you love.
Brian Lovin:
Okay, this isn't a habit, but I suppose this is unusual because I've always gotten comments on this. When people are describing things to me, I have to close my eyes and I visualize it in my mind's eye, and I kind of nod along as they're talking. I have been made fun of for this, I mean, in a playful way. Right? Like I'm in meeting with somebody or I'm in a meeting with a group of people and somebody's like, "I think we should build this feature and it's going to work like this, it's going to look like this." And I'm sitting there and I've closed my eyes and I'm nodding along and then they'll stop and go, "Are you listening to music? Are you still here? Can you hear me? Are you taking a nap?"
Brian Lovin:
I don't know, that's just the way my brain works. Like if someone is describing something to me specifically in software design, an interface, describe a flow for me, I can close my eyes and replay, like I create a computer screen or a phone screen in my mind and replay it. I suppose that's unusual and looks really weird from the outside, and I have to remember that it looks weird to the outside like, oh, someone's having conversation with me and I'm closing my eyes and tuning them out for a second while also listening to what they have to say. I look at the ceiling, I take some hallucinogenics, and then I can really visualize that prototype. It's great.
Ash Oliver:
Final question, Brian, what do you think that you're known for?
Brian Lovin:
So I think people tell me that I build a lot of stuff. Like I'm a curious person. I like to build, I think staff design is an example of this itch that I had in my brain and I just had to go and scratch it. I have lots of projects that are like that, and over the years, those have accumulated, and so when people look through my website or my work, they're like, "Wow, you've done so much stuff. You write a lot and podcasts a lot, and you're constantly doing things."
Brian Lovin:
From my point of view, it doesn't feel like that, because that is at this point, like years and years of work that has accumulated, and I go through many months at a time where I don't do anything new at all, but perhaps that's what I'm known for. Is like, "Oh, that Brian guy, he makes stuff."
Ash Oliver:
Amazing. Well, Brian, thank you so much for chatting with me today. It's been so incredible to learn about your journey through Spectrum and obviously joining the team at GitHub. Thank you so much for all you do for the design community. Where would be the best place to point people to find you, if they want to learn more about you and your work?
Brian Lovin:
Thank you for having me. This has been lovely. I guess my website, Brianlovin.com or Twitter, my handle is Brian_lovin. Those are the two places that I'm working on and hanging out. That works?
Ash Oliver:
Amazing. Thank you so much. The Optimal Path is hosted by myself, Ash Oliver, and brought to you by Maze, a rapid user testing platform designed for product teams. If you enjoyed this episode, you can find resources linked in the show notes. If you want to hear more, you can subscribe to the Optimal Path by visiting maze.co/podcast. Thanks for listening, and until next time.