SWIMM UPSTREAM

Brian Douglas is the Director of Developer Advocacy at GitHub and a familiar face (or voice) in the world of software development and community.

Based on Brian’s experience building Netlify’s first design system, he shares his perspective on knowing when a start-up can build their own tool versus using one that’s available on the market.

What is SWIMM UPSTREAM?

The Swimm Upstream Podcast is a collection of conversations about knowledge sharing, code documentation, change management, scaling dev teams and more. Our guests come from all over the tech world, with some really interesting insights, stories, and… coffee hacks. Join Tom Ahi Dror, Co-Founder of Swimm (a Continuous Documentation platform that streamlines onboarding and knowledge sharing within software engineering teams), as he talks with some of the most inspiring engineering and dev team leaders in the industry.

Tom 0:00
They say that change is the only constant in life. On this season of Swimm Upstream, we're breaking down specific instances of change in software organizations when both technical and human aspects were involved.

I'm excited to welcome Brian Douglas. I must say that Brian has a really cool job as he's GitHub’s Director of Developer Advocacy, and also a friend of Swimm from our earlier days. Welcome, Brian. All right, let's dive in.

Let's kick things off with some warm-up questions. What have you been listening to on Spotify?

Brian 0:43
Well, I've got two small kids. So the one song that I've been listening to is the Encanto song, which is “We Don’t Talk about Bruno”. Yeah, it's like an every afternoon thing.

Tom 0:53
Amazing that they've graduated from the Elsa and Anna songs. I'm assuming, because that...

Brian 1:01
Yeah, there's an article about that, that Encanto has overtaken “Let It Go” as the most popular Disney song.

Tom 1:11
Okay, that's a tectonic shift for kids. Good to know.

So tell us about how you picked a specific story for us today to talk about change. Tell us about where you were at, where you were at in life and where you were at organizationally?

Brian 1:29
Yeah. So I picked a story from quite a few years ago when I was working at this company called Netlify. So today, I work at GitHub, leading Dev Rel there. But at Netlify, when I was still transitioning to become a full-time Dev Rel, I was maintaining the dashboard app at netlify.com. And in addition to that, we were also shipping a couple of different marketing sites like jamstack.org, or static10.com. And in order to ship front end, UI components, everything was hand-built from scratch, and would just mimic some Figma or Invision template. At that time, which was around 2017, Netlify had around 10 people. Design systems were a thing that kept getting talked about by designers - designers who were working with engineers and engineers who also were designers. And there was this sort of shift in the industry, as people were saying, “You know what, actually things like Bootstrap, you could actually rebuild that for your company specifically.” And people started sharing the secret sauce of how to approach that.

Brian 2:22
So at Netlify, we've made the decision to like, hey, let's take a step towards that direction. Because as we're shipping all these sort of side projects, marketing sites, but also still maintaining the actual UI for the app, the dashboard, it would be really nice to have a design system to have some consistency on the site itself. And one thing that kind of pushed us towards that direction is when we hired our first designer.

Tom 2:56
So tell us a bit about your role then and how it relates to design systems specifically.

Brian 3:05
Yeah, so I was hired at Netlify as a Full Stack Developer. But when I got there, I was the only one that was willing to write JavaScript. So I quickly became the Front End Engineer on the team. So day to day I would implement features that connected to the back end, and the API, and then connect that to the front end and add some React components. One of my first jobs there was converting Angular to React because we made a big shift in React at that time, it was very, very exciting. So we made the decision to switch to that.

Tom 3:42
So you described Netlify as having Around 10 people, right? So it's like an early-stage startup phase. Usually, at that point, if something didn't happen up until now, it's because really, it wasn't burning enough. Right?

And I mean, so I understand the designer came in and had, you know, all these ideas, obviously, but how do you get the organization to switch the way they think about a particular problem. And, you know, starting to think of it as something that's actually important enough to put one of our 10 people on it.

Brian 4:10
Yeah. And that's for a small team like that. And even engineering teams, because I now work in larger teams at GitHub, it's sometimes hard to justify, hey, we're gonna take some time of not shipping something to completion, to go and solve more operations or more of a developer experience problem. Looking at it now, even like looking at the other end, when we completed this, this design system transition, it makes sense that the investment of being able to ship quicker and faster, makes sense. But we were in a sort of uncharted territory, because not most design systems, if you leverage one, it was either a large open source one, or it was like Airbnb, or Facebook, who like gifted the community access to the design system. So like, he didn't have a lot of decision making, a lot of style choices. It was a sort of, you just sort of jump in, and all the decisions are made for you.

So in the context of Netlify, we ended up getting to a point where we had a good feature, a fully-featured application, we're growing, seeing good adoption. So to be able to take the time, and I think we only took like a week, maybe more than that more than a week or a week and a half of like actually sitting down putting some of the most basic components. The way we came to a resolution for this - that the decision was not to put every single thing in the design system to put some of the most hairiest questions. So things like grid systems, like how do we, how do we place things on the page. As a non-designer, I learned about the eight-point grid system from this process, and I've never stopped using it since then.

Tom 5:52
So there are two questions here that I think about hearing this. First, you know, making this change, choosing a low-hanging fruit, right? You mentioned that you see the value like there's a return on investment. What's that return like? Is it that everyone looked at this and said, yeah, this looks far better now?

Brian 6:12
So one, have a list of all the colors that we use on the page, like that showed value immediately because we were also shipping like little small, “growth-hacky” marketing sites. So we had like, speed test, which I don't think it's still alive, but similar like fast.com, which is Netlify, sorry, from Netflix. The Freudian slip is now happening, but Netlify had something very similar. And so be able to ship that really quick, which is just a form, put on your website, we’ll provide a score of how fast your site is. That is, that was something we're able to turn around pretty quickly, like having some basic things discovered. So it's no longer like, you know, like, there's a form need, how many rounded pixels you need on the form. And at the time, like it was 10. All this stuff is committed to memory. And the reason why it's committed to memory is because, like, once I went through this process, I don't build another site, a side project, or a future project, even GitHub without a design system in mind. Because what usually happens as you bring somebody in and we saw this with Netlify bring somebody in, and therefore you're going to engineer with us. No longer am I going to spend weeks with you trying to teach you like you know, it's actually this hex code, not this one. Instead, it's like, hey, go reach off the shelf. Here's the list of things that we've already decided on. And if you need to do something unique or interesting, add it to the design system, a lot of it is like an accordion type of list. So if anybody looks at the Netlify dashboard today, you'll see a lot of elements that look the same that you reuse in other places. So like the way the form and navigation feels so fluid and familiar when you go to each tab and within your deployments in your logs. It's because we're reusing the same thing over and over again, we're not reinventing for the sake of reinventing so instead of pulling somebody later in who wasn't there in the original decision process, they are able to hit the ground running like right away.

Tom 8:08
Another aspect of this, though, I mean, you're mentioning new people coming in and making it far easier to get them into the system. But when you're introducing something new like this, you also need to get the people that have been around for a while onboard, and sometimes that's harder. How do you go about doing that?

Brian 8:29
That just really comes down to making sure things are not as complicated as they need to be. So there was actually one part where we had to make a distinction and actually, this is very common in most design systems. GitHub has a design system today and we actually borrowed a lot of implementation details from them as well, ironically, because now I work at GitHub. But the decision to make marketing in UI like actual user dashboard, separate components was something we had to make that decision really quickly upfront, because with the marketing components, like they're gonna change as a site and as design aesthetics change culturally, within the community. That was something we had to put a stake in, say, okay, this is going to be way more fluid flexible, or gonna take way more chances on how things are presented, because it's the marketing site, it's the landing page. So anything that's a landing page, or anything that's meant to sort of attract an audience and convert them into signing up, like that's going to have way more artistic freedom and probably going to have way more updates. But when it comes to the UI - the UI needs to be consistent. Because I want to know if I need to change some variables, or if I need to change my site name, I need to know how to get there quickly. I don't want the experience to change drastically if I don't log in for three months.

Tom 9:47
It started from low-hanging fruit, showing a fast and very significant return on investment. Were there any surprises like challenges that you met in this process that surprised you that didn't go that easy?

Brian 10:05
So honestly, the most surprising thing, because at that moment, we had the first designer, we had another creative director who managed all the landing pages. That was something that they had to decide for themselves, for like creative direction to make that split. And honestly, more and more I see even tailwinds. Their UI components also have an aesthetic for marketing sites and for landing pages. And then they have a very UI friendly, dashboard-looking developer tool style design system. So like, once we sort of got past that hurdle, everything sort of just worked out where the UI could just get shipped really quickly. The marketing side could sort of have the design sprints when we call these, they were engineering catch-ups, but then they call them so engineering teams, they had to catch up, which is it sounds like a condiment. But the design team called the design mustard for that same reason. So they had these design mustard chats where they were to sit and talk aesthetically about design systems and like future and trends and stuff like that. So like designers want to design to like we give them that space to do that.

Tom 11:12
You know this is a good example of a startup starting to mature, right starting to work properly. And it sounds like this was a very good experience for everyone involved. So I wonder, did you see this type of dynamic repeat itself with other things like tests and things that are maybe even less popular?

Brian 11:36
Yeah, I mean, very true. Because when I first started at that company, we didn't write a ton of tests. Because I think, at the time React was at the point of for folks listening. If you use React, you know, Jest it kind of comes along for the ride for testing libraries. So Jest was still pretty much in its infancy at that point, so there wasn't a lot of a paved path for that. But as the industry sort of matured, and saw that testing was way more of a thing that you want to do with your UI elements. And now we have Cypress, and we have Apple tools that can do some visual testing. That's something we're able to approach. But in going back to the design system, identifying things like is it possible to create a framework or a library out of this experience. And that was the one thing that I noticed as an engineer, moving away from the design system like we had at Netlify, you will log in with GitHub or GitLab or Bitbucket. And it was intentional because we want to connect to your repos. But that file the API file to connect to GitHub, for example, that was all ad hoc, like we're just gonna jump in, make a decision on the API, figuring out how to sort of convert that JSON data to be usable. And it was just sort of like a wild wild west of a file to basically just like, good luck, nothing's tested, figure out whatever the endpoint that you need, make that work, and then move on with implementing the UI.

Brian 13:00
And something that we learned was, after we built our entire “SDK”, there are other tools out there, like Octokit, which gives us that same experience. Instead of me maintaining the thing, if something breaks or the API updates, instead, we can leverage open source tools or tooling to basically keep consistent. And then if we need to go ahead and commit upstream, I guess, which is, I guess, I don't know if you get to save the name of the podcast at least once during the conversation. But yeah, but basically commit upstream to help support the community. And I think that decision of knowing when to build your own thing, and when to use someone else's, is something you constantly have to make that trade-off as a fast-growing company. And I think what's great about nowadays is there's so many decisions made for you that if you wanted to only use JAMstack tools or want to only use tools off the shelf, like you can. And then once you get to the point where you're either growing out of it, or it's not meeting your needs, then you can make that decision of like, should we invest in doing our own design system? Or should we go pick something that the community has, like, adopted as a consistent standard?

Brian 14:07
So, and again, those will be trade-offs. But it's easy to have that conversation of like, Hey, we're gonna have to rewrite something, rewrite into support community support, have an onboarding path into hiring new developers, because everybody knows this one design system, or build our own, and then have an onboarding experience that maybe it might not be as nice because there are some decisions have been made. So like we've, we clearly drew the straight steak of like keeping the design system simple, like focusing on the hardest problems first, with the grid system, and like font sizes, and then move into something that's more elegant. Because as an engineer, I've noticed that as you make this, you solve the smaller problems and the spot, solve them in places that are bite-size and approachable. It's going to be much easier to bring somebody else on board, because in documentation, you can now have that conversation only about this one small problem, as opposed to like, here's like this opaque function that we don't know how it works, but it does. And we can't document it because it does, it does 60 steps. And we're just like, it's a magic function. No one wants to touch it. But that's usually a sort of a red flag to say, hey, too complicated. Let's break this down.

Tom 15:21
Okay, so now let's imagine there's a Full Stack Developer out there. They want their team to adopt a design system for the first time or something similar. Could you pick one technical and one organizational or human advice for them at this moment?

Brian 15:43
Yeah. One technical advice is that I actually focus on the simplistic things first, like when it comes to design systems, solving the simple problems. Like the grid is something I didn't realize was like the heart. It's kind of like the beating heart of the design system. That's actually way more important than aesthetically pleasing UI components that you can pick off the shelf, like understanding how approachable the grid is makes so much more sense. So approach it in that way, and approach it in a way that it should be explainable. So some of the basic pieces should be explainable. So that way anybody can approach it.

Brian 16:16
But then the other thing is, I'd actually caution folks to even consider choosing a community design system because very quickly as you build some of these small problems, as we saw at GitHub, we've solved problems like electron and Adam. And now we have, we've acquired the bootstrap creator who now created Primer. So like we're owning all these other problems, but also shipping a large platform with collaboration and tooling built-in and DevOps. So we have to make the decision like, do we still want to keep tending to solve these problems? And like, it's nice, because we're a well-funded company owned by Microsoft, that we can like, say, yes, we're gonna hire people, just for only the open source - only the design system. But as a growing company, you have to make the decision, like, do you want to always have a headcount only working on the design system? Or do you have to have three engineers instead, working on the UI? And then using community-funded community-contributed design systems as well? So that's a decision that more of like a longer tail, aesthetically pleasing conversation that you should have upfront? Like, do you want to be a design system company? Or do you want to solve your company's problems instead?

Tom 17:25
Would that be also the organizational advice? Or is there something else in terms of like, how do you get? And how would you get the least design-oriented people on your team on board? You know, except for giving them simple tools? Is there anything you can do to get them to appreciate the impact?

Brian 17:46
Yeah, honestly for organizational-wise, like, I am a big fan of having quick side projects. So a lot of folks, these look like hackathons or like a quick hack day, because like usually you have some downtime - hopefully have some downtime - if not like congratulations and raising your next round. Like maybe that's why you've got so much power in the sprint going right now. But giving space for people to like feel like they're sort of research and developing, like this could be a couple of hours on a Friday, or this could be maybe a week during the holidays. Because like, sometimes you have the weird weeks, we only have like two days of work. Those are opportunities that I love. I've always built it into my job as an engineer to have that space to be able to try things out.

Brian 18:32
So being able to try things out like the design system that kind of bend it or test it to see if it actually is going to meet the needs of like future, aesthetically pleasing design and UI that gives opportunity for continual decision making without even knowing you're actually doing that. So that was the other reason why we have a design system, we put that together at Netlify. Because again, going for the always shipping small growth hacky side projects, we needed a quick way to be able to say, Okay, we want something that looks kinda like Netlify feels like it's a Netlify owned thing. But it's like, you know, speedtests.org or whatever, to be able to ship it really quickly and like, test that at the API endpoint and that it worked out because Netlify it's a site, it's a site to help people deploy sites and do continuous delivery. So like, if we weren't able to ship sites quickly, and ship them on Netlify, then it's going to be harder for even our customers that even think about doing that themselves. So as long as we had the bar of entry to deploy stuff really quickly, then it made it easier to have that conversation.

Brian 19:36
So we kind of lucked out because the platform we were building, like alleviated that all the sort of pressure of like, oh, we can just deploy stuff for the sake of the plane. It's like, actually, we can because we're Netlify. So but you're in your company like there should, the hope is that you could have some space to be able to say, Okay, we're gonna try some new things out that are not going to break production or going to touch like the main flagship product. But let's just have a little fun and get to try things out.

Tom 20:03
Okay, great. Brian, thank you very much for coming on the show.

Brian 20:08
Yeah, it's a pleasure.

Tom 20:12
Thanks, everyone for tuning in. That's all the time we have for today. To read episode transcripts, check out our past season, suggest an episode or join our growing community of developers. Head to swimm.io that Swimm with two M's dot IO.