Ep. #8, I Only Work On Ugly Products

Dom Nguyen: It's a blessing that we are designing tools for the people that we so closely work with every day.

Steve Boak: We as designers can't operate independently. We need our developers' feedback to understand if we're doing things right.

Dom: At a DevTools company, you end up having a large impact on a small audience, whereas in a consumer company you have a pretty small impact on a very large audience. Dev tooling multiplies the productive capacity of engineers. They're able to move faster and less time.

Steve: Hi, I'm Steve.

David Dollar: And I'm David, and you're listening to Don't Make Me Code, the bi-weekly series where we discuss developer experience and some of the unique challenges we face building developer-facing products.

Steve: Don't Make Me Code is brought to you by Heavybit, a nine-month program for developer-facing startups. For more information, visit heavybit.com.

David: And if you're interested in being a guest on this show, or if you have a specific topic you'd like us to dive into, you can reach us at dmmc at heavybit.com or on Twitter at Don't Make Me Code.

From Agency to DevTools

Steve: Welcome to Don't Make Me Code. We're calling this episode I Only Work on Ugly Products, and here with us is Dom Nguyen, product designer at Meteor, to chat about both why designers should be joining DevTools companies and why DevTools companies should be prioritizing design.

Dom: Hi, Stephen and Dave. Thank you guys for having me. I'm excited to talk about designers and dev tools and why I only work on ugly products.

Steve: And your personal story is really interesting because you've been a proper designer for a while now, including having your own agency, and have made the transition to working on developer tools. And we're curious to hear more about that.

Dom: Yeah, so a bit about my background. I work at Meteor right now as a product designer. Prior to this, I was the design partner in a software engineering and product design company. And then prior to that, I worked at a consumer company called Yummly, which services millions and millions of users.

Over the course of my career, I've kind of drifted towards the dev tooling and designing tools for engineers, all the way from my kind of start with the consumer products, and kind of experienced a breadth of other challenges running an agency, coming from clients in the education space, in the consumer space, in the engineering space, kind of everywhere.

Steve: I thought the story of your agency getting acquired by Meteor was particularly interesting for two reasons. I mean, one, that it happened at all, that a product company is out acquiring a design agency, but that this seems to be happening quite a bit. There have been a few big acquisitions lately, product and software companies acquiring entire design agencies to suit their needs.

Dom: Facebook and Teehan+Lax is one of the notable big acquisitions. Where we came from is we were kind of using Meteor in-house as a way for our agency to have a competitive advantage because what we saw in the software and the software tooling that Meteor was offering was a way for us to provide better experiences faster. We were using it kind of selfishly because it actually helped our bottom line.

And when the acquisition talks were in place, what we saw was that in an agency, you tend to build software for the end user, and you can build it like one app at a time, and that services a pretty small market, especially in the beginning. Part of the decision making around the acquisition for us was getting this opportunity to build tools at a layer of abstraction above just building software for the end user. We could build tooling that would help other people build software for their end users, and thus our impact could be multiplied.

Steve: Yeah. We were saying in one earlier episode that DevTools are kind of like the supply chain of the software industry, the same way that there's an entire network of suppliers for the automotive industry or the aerospace industry. This is how developers get their tooling and make their products. And so, yeah, that our impact is outsized by that we design tools that are being used by other software makers, and so potentially has an enormous impact.

Dom: Yeah, absolutely. We hope that the tooling that we create in the dev tool space makes our life easier too, all the way on down the chain, because it actually raises the bar for all types of products to be better.

Steve: Yeah, I also, having worked in an agency before, found that it's not an environment well suited to perfectionism, that a product company's sole purpose for its entire life as a company is to perfect that product or products that they're working on, and you iterate over and over and over. And that is your job. Where an agency, you have this natural incentive.

You have a budget, a timeline, and no matter what you might think, your job primarily is to get that project out on time and on budget. And so if you fall short of some design goals along the way, that will happen. And you'll make sacrifices that you would not make at a product company.

Dom: Absolutely. And the constraints of budget are definitely evident in the types of and the output of most agencies. As you said, you're not really incentivized to produce something that is the objective best, you're incentivized to produce something that satisfies your clients' goals at their budget. And sometimes your clients' goals aren't aligned with what their end users' goals are.

Steve: Yeah, and I know someone was out there declaring the death of the design agency in software, and that it was sort of a natural evolution of the business, which sort of makes sense.

Dom: It does.

Steve: The best of them though, I mean, Teehan+Lax, I would routinely look at their portfolio of work for inspiration, and the best ones are still putting out really amazing work.

Dom: Absolutely.

Steve: But it isn't easy.

Dom: Yeah. The best ones have the benefit of being able to pick and choose their clients. And in self-selecting the type of people that they work with, they can better determine whether the output of the finished product is to the design agency's quality standards. And it's definitely a big challenge.

The First Designer at Meteor

David: So your design agency got acquired by Meteor. You're coming on board into a new company. Did they already have any design talent in place, or were you guys sort of the first designers to come on board and lay out the foundation of what it was going to look like?

Dom: Yeah, so they didn't have any designers on board to begin with. So I was effectively the first designer. My partners are software engineers by trade, but they have a pretty strong background, if I might say so myself, in design. But yeah, I was the first designer for Meteor. Prior to that, they had kind of a rotation of third-party design contractors that satisfied their marketing and branding requirements.

David: Well, so you kinda come in and get to start fresh with a new developer tools company. It's gotta be an interesting experience.

Dom: Yeah. It's a challenging experience.

Steve: What were the hardest parts of making that transition? Like, what was the learning curve like, and what were the hardest parts of adapting yourself to that environment?

Dom: Yeah. The learning curve was a big challenge. However, it wasn't an insurmountable challenge. It would be a similar challenge in any significantly complex vertical, say, healthcare, where you need to learn the processes that are endemic to that specific industry. So too did I have to learn the processes that were endemic to what is essentially an R&D company.

So the learning curve was one challenge. Another challenge was bringing design DNA into an organization and overcoming the

Steve: The inertia?

Dom: Yeah. The inertia, that's a great way to put it. There's a focus on engineering as the first-class priority, and I think that makes a lot of sense. But seeing how design could complement and multiply that engineering effort.

Steve: Yeah, that one is an interesting one to unpack because that's something that I've dealt with too, and the day-to-day manifestation of that is the sprint cycles and how we handle them. And I don't know if this is true of other companies, but where we are, design is now kind of part of the sprint cycle. And the way we've chosen to adapt that is that we'll do kind of a pre-development sprint where we just kind of do a bit of design.

And it's not high-resolution visual design. This is not anywhere close to a final product. Part of the purpose of that is to sketch a workflow out for the developers to see and buy in on.

Because we as designers can't operate independently. We need our developers' feedback to understand if we're doing things right. So we all then come together after that first iteration and figure out if we have things right. And then only after development will we do a final visual design polish.

Dom: Yeah. In many ways it's a blessing that we are designing tools for the people that we so closely work with every day. And that makes user research and user testing that much easier.

Something that we learned in the agency is the discipline to have a production process in place that yields results. And so oftentimes what you have in new companies is the ability to do everything at once and the desire to do everything at once. However, in doing everything at once, you might have a bunch of people moving in completely different directions.

And when I say discipline, I mean getting the processes in place so that everyone moves in lockstep in the same direction. And that's one of the learnings that an agency could bring into a product company in general. And I'm sure you probably had a similar experience, Stephen.

Steve: Yeah, that is actually a really interesting twist on the logic from before. I think if the biggest lesson that product companies have for agencies is that perfectionism has a place that is found over years, agencies are used to thinking about things in terms of dollars and time.

And product companies do not do that. They waste weeks on things. And we're guilty of it today. And yeah, having that ruthless efficiency to think about a project as something with a finite term is something that I think we could all do better.

Dom: Yeah. It actually helps us move faster because we can kind of test our hypothesis in a very disciplined way, learn from whatever that hypothesis is with the product or with the idea out in front of users and then continue on rather than waffling or churning on an idea.

Steve: Yeah, a lot more bike shedding is happening at product companies than at agencies, for sure.

I also think the idea of designers just being acquired into a DevTools company is interesting because, I mean, not only are you trying to impact the culture and the process, but you now have to get them to think about design. So how did you fight your way into that?

Dom: I was lucky on two fronts. I was lucky in finding a company and finding partners for my consulting company that were extremely technical yet valued design as a first-class citizen in a software engineering context. And the second way was seeing a company in Meteor that valued the developer experience in a way that I've never really seen before.

Meteor, if the audience doesn't really know, it's a development framework that helps engineers build great experiences faster. And when I say great experiences faster, I mean they thought about the developer experience at a very detailed level and tried to optimize for things like onboarding to a new framework, what it's like to use their APIs, what it's like to consume their documentation, and really build features atop their framework. So I found it to be a pretty easy transition because the founders of Meteor and the company culture already thought about design, even though they didn't call it design.

Steve: Yeah, that actually came up last week in our last episode. I think, David, your story about the DX team at Heroku and the different languages and specializations and how that got started is interesting also.

When to Bring In Design

David: So I'm actually kinda interested, you mentioned you came into Meteor, what employee number? Like, how early was that in Meteor's life?

Dom: I don't remember what employee number it was. That was in the twenties, I think.

David: I guess I'm just curious after having that experience, do you wish that they had decided to bring in designers a little earlier? Was that a good time in the company's life to start really focusing on that? Like you mentioned, there was a little bit of inertia getting started.

Dom: Yeah, that kind of brings up the question of when is a good time to start thinking about design as a dev tool company. And I think they brought us on at a pretty good time. Of course I'm biased. Primarily because they were launching a product. If you consider a framework a product, they were launching another product that was a deployment service for Meteor-specific apps.

Steve: A paid product.

Dom: A paid product. Essentially a SaaS product. And with a SaaS product comes more requirements around what it should look like, and the user interface and the user experience are around that paid product.

Steve: Right, versus the framework, which is code.

Dom: Absolutely, which is, what you'd design in that case would be the documentation, the APIs, the kind of tutorials to get people on board. What you would design for a SaaS product is, what is the look and feel? What is the experience of going from page to page? What is the experience of accomplishing a user's goal in an interface or in a flow?

Steve: Yeah, that's an interesting distinction. I mean, before you brought that up, I was going to say that it's never too early, start with design as soon as you possibly can. There are some cases though in DevTools, if you're building a framework, an open source product, that your engineering team probably has a pretty good understanding of what, as you were saying before, the user experience of that is very much about the code and the development of it. And so a designer may have less to offer in that environment versus a SaaS product where you're creating a UI and a specific experience.

Dom: Absolutely. Yeah, I find that the companies that either don't need it or kind of are reacting to the fact that they need design often bring in designers at a stage where a designer's impact is constrained to a marketing or branding function. Whereas if you consider a designer as a champion of the user, then it kind of behooves you as a company to bring a designer into your company at the inception of a product or a product line.

Steve: So you're a designer joining a DevTools company. You're used to working on consumer products. Someone's trying to give you a lesson in where you will have the biggest impact at a DevTools company will be. What do you tell them to get them doing the best design work they can?

Dom: Understand that first, people are unlikely to change their usual behavior.

Engineers are especially unlikely to change their usual behavior. Design something that adapts to existing behavior rather than trying to create something completely new. Oftentimes that completely new thing will probably be wrong anyways.

But in general, identify the behavior of your audience and create something that is incrementally better than that existing behavior.

Steve: Yeah, I think the general theme of listening to their needs, first of all, and then also understanding how they really work, because that will almost certainly be a shock to someone who's never worked on dev tools before, the way that developers actually work.

Dom: Exactly.

Steve: And that the command line is powerful and documentation is powerful and boilerplate code is powerful.

Dom: Yeah, that's exactly right. Another side of that is it kind of brings up this idea of documentation being one of the core pieces of developer experience design. You can have an amazing product, an amazing framework, but without great documentation, no one understands how to use it. And your job as a designer is to translate immense machine effort into something that is usable, and documentation is one of your primary levers for doing that.

Why Join a DevTools Company

Steve: I just had a moment thinking, while you were saying that, about how boring that must sound to a designer. Like, your job is now to work on documentation. But that gets to another question, which is why should a designer join a DevTools company?

And that might not sound so great. You know, while you're working on documentation, you're understanding how people write code. And so why should they do it at all? Why not focus on something that already has great design, Facebook, Pinterest?

Dom: Oh, that's an excellent question. I think it comes down to what type of impact you want to have and the scale of that impact. So at a DevTools company, what's most often the case is that you end up having a large impact on a small audience, whereas in a consumer company you have a pretty small impact on a very large audience.

And your impact might be the color of a button or the shape of a button or the visual aesthetic of a specific microsite. And if you're okay with that, you should continue sticking with working at this consumer company. If you want your impact to look something like, I am improving the life of my users, which are engineers, every day, they use my tool every day, then probably consider a developer experience company.

Steve: Yeah, one of my favorite talks on this subject is the Ben Horowitz commencement address at Columbia, where he advises people to not follow their passion. And he gives a couple of specific reasons for it. One is that your passions may change over time. At 20, you might be into video games and K-pop, but at 40, you're gonna be into your kids.

So following your passion is something dynamic and that will change. And it's not necessarily a good guidepost for your career. And that following your impact, following the places and paths where you will have the greatest impact, is a much better one.

If you go to Facebook or Pinterest or some company where design has already been figured out, as you were saying, your impact will be small. But if you go to some starving DevTools company that is looking for their first designer, you'll probably have an opportunity to have a much bigger impact.

Dom: That's right. I would also add that the profile of the types of challenges that you end up facing is a bit different too. In SaaS companies and especially in dev tool companies, you end up having a shorter feedback loop. So your audience, they're using your product every day. You don't need to divine an insight based on a small amount of interaction over millions of people as you would do in a consumer company, you can just go ahead and ask your user, your engineer, your engineers.

And because the customer's goals are pretty clearly defined, it means that problem solving ends up being a bit more straightforward. Yeah, there's still a learning curve, and there's certainly a barrier to that of getting up to speed with domain knowledge. But it comes with the feeling of instant gratification of you being able to see the change that you made in the hands of your audience pretty instantaneously.

Steve: That's actually a really good point too. The proximity to our users is much closer, that even a pretty successful DevTools company might have hundreds or a few thousand customers, which you can almost be interacting with them on a one-to-one basis. And so you can learn exactly how they get their jobs done. And so you can feel very close to their needs.

Dom: Yeah. You can just call them up.

Steve: Yeah, and I guess at early stage companies we kind of take it for granted because we have to do it. But even as the company gets bigger, working on enterprise or SaaS products, you're still dealing with a relatively small number of people as opposed to the billions of people using Facebook.

Dom: Absolutely. Yeah.

Hiring Designers

David: So I'd be interested to know, when you're looking for new designers at Meteor, what kind of skills, background, etc., are you looking for? Is there anything in particular that you think makes somebody have a natural aptitude for this developer-facing design, or is there something about their background that usually intrigues you?

Dom: That's a good question.

I tend to focus more on their ability to break a problem apart and their desire to reconstruct that problem and to see that problem from different perspectives.

I'm specifically looking at product designers and user experience designers, more so than visual designers and branding and marketing designers, primarily because our needs just fit the shape of design a bit more. I don't have any specific insights for the exact traits of a designer at Meteor.

David: So do you look for designers that have maybe done a little bit of coding, or at least slightly touch the stuff? Or does that actually not really matter that much?

Dom: Oh, right. Almost everyone at Meteor codes. And that isn't a prerequisite by any means of being a solid contributor to Meteor, but people from marketing ops, people from community ops and elsewhere around the organization, they can all hang in the code. They know enough to be dangerous, and that also includes myself.

But does the ability to code necessarily make a great design hire? My personal belief is it certainly adds another tool in your toolbox, but I don't think that you need to be great at coding to be effective in an organization as a designer. In the same way that I don't think basketball coaches need to be LeBron James to coach LeBron James.

Steve: Yeah, that's a great point. That you can't look for the ability to code first and foremost. You're looking for someone maybe with some technical aptitude, but they certainly have to be able to unpack hard problems. And I think you said that for sure.

And then, only then, if you found someone who's strong, who's able to unpack the problems and who's curious enough to go and talk to people, then okay, writing code is cool, it's a nice benefit. My ability to code has gotten so much better since joining DevTools companies.

Dom: Yes. If you want to learn to code, definitely join DevTools company because you'll probably end up coding.

Steve: That is a great message.

Dom: And especially as the company is small in profile or small in team, then you're doing everything anyway.

Steve: Yeah. So when I was looking for my first job in software, I started looking at small startups, who, I wasn't gravitating towards dev tools, but it turned out that I found one because they were starved for design, and they were willing to take a chance on me and I was able to take a chance on them and it worked out. And yeah, that's really cool. If you're a designer who wants to learn how to code, join a DevTools company.

Dom: Yeah. It will be trial by fire.

Steve: Yeah, you'll learn a lot and you'll develop a specialization too.

Dom: Yeah, absolutely.

David: Last episode we were talking a little bit about things that we look for, trying to find people that would be naturally talented at developer experience. And we mentioned that we saw some correlation with people that contribute to open source and tended to be involved in those types of communities. I wonder if there's any sort of corollary with visual design, user experience design. Things like Dribbble come to mind, but people that have some sort of large body of public-facing work that you can take a look at, or something like that.

Dom: Yeah, yeah. I don't know if having a body of work on Dribbble or Behance is particularly indicative of being a great problem solver. It certainly helps if your problem was constrained to the visual sphere of things, the superficial level. But I haven't found that to be the case.

A GitHub for Design

Steve: So this is quite a ways off topic, but it's something I'm fascinated by, that there is no corollary of GitHub or open source in the design world, and Dribbble and Behance, they're, as you say, they're for finalized products. They're polish over process, and that with open source you get to see exactly how the thing was made. You can unpack it to the line of code.

There is nothing in the design world, and actually this is one of the most crazy things I think that separates design from development. There is no GitHub for design, and I don't know if it's a cultural problem with design or a technological problem, that there just is no GitHub for design yet. But it seems like design is really lagging behind software development in this respect, that we don't have this contribution to the community thing.

Dom: Yeah. I guess aside from the UI kits that are often released, those are pretty finished products though. When I say UI kits, I mean like Bootstrap or Material. It's someone else's vision, and it's released so people that don't have a design background kind of consume design work. Yeah, but you're right, a GitHub for design doesn't come to my head immediately.

Steve: Yeah, so again, we're kind of drifting here, but the closest thing I think now with this new age of prototyping tool is that there are two really interesting things that I think have happened in the last couple years. One is we've got these more component-driven design tools like Sketch, where now you can actually see a bit of design process. Like, how did they create these components?

And then with a tool like Framer, which is actually code, you can actually then script the interaction design. So now you've got components and interactions, which are kinda like the fundamental pieces of that. It's closer to open source.

Dom: Yeah, those are great products to bring up, and the closer you get to code, the closer you get to a free and open source model. And things that you can script are generally things that can be shared pretty easily.

The more that you get into visual design and the subjective aesthetics of a product or experience, the less you can really share, because the aesthetic paints a vision, like a cohesive vision, that you present to users, and taking from that piecemeal doesn't often work.

Steve: Yeah. I've never found myself thinking this yet, but that might be an interesting acid test for a designer. Like, have they been eager to pick up these new tools? Have they learned Sketch, have they learned Framer? Not for their own sake, but do they understand the component-driven design and how that actually benefits a product?

Dom: Yeah. That's definitely something that we've been very interested in at Meteor, and specifically I've been very interested in producing reusable components, from the visual design all the way down to the interaction design and the functionality of that component. As products move more and more into components, it's becoming evident that designers need to bone up on that knowledge.

Steve: And yeah, incidentally, it's how developers write code too. You model the component and you instantiate it, and it actually works pretty well as a way of communicating between teams.

Dom: Exactly.

Competing on Design

I had a question for Stephen and David here. You guys are founders of your own developer tools companies. Why, in your experience, should developer tool companies compete on design?

Steve: We were talking a bit about this before, but I think it'll depend on the space you're in. So Opsee is a monitoring company. Monitoring is a pretty crowded space. There are a lot of products, and one of the ways we need to compete is in our usability.

And I've worked at three monitoring companies now, and so right away I saw this as a differentiator for us. It was, I thought, one of the only ways that we were gonna find a competitive advantage in the market, was to have really, really strong design from the beginning.

And so part of it was just a function of being in the space a while, but the other part of it was being in a space that was crowded and was still a bit starved for design, so seeing an opportunity there. But I would not extend that to all DevTools companies.

David: I would agree with that to a certain extent, for sure. I guess my personal experience with Convox has been that Convox's primary product really is what we would call developer experience. We're essentially pulling together services that other people run, AWS and others, and really just trying to turn those into a different sort of experience dealing with infrastructure, where we reduce a lot of the complexity and where you don't have to think about a lot of the details.

It's sort of very similar to what Meteor is doing, I guess, with just general web stack development. Yeah, just trying to make this nice cohesive single experience that sort of sits on top of an enormous amount of complexity underneath.

Yeah. So I think the real reason to compete on design is, that is essentially the essence of good design, in my opinion, is being able to take something that's incredibly complex or rich or does a lot of stuff, but be able to convey that in a simple and expressive way that doesn't confuse you or overload you.

Dom: Yeah, you bring up a good point, Dave, in the fact that there's a lot of open source software that kind of solves many of developers' problems, from left-pad on down. But despite this wealth of free software, free to use, free to copy, free to do whatever you want with, it's clear that folks are willing to pay companies for their ability to create products that are simple and easy to use and straightforward, even if they're originally based on open source software.

Steve: This'll get a little bit niche, but do you find that among Silicon Valley Illuminati, like your fellow startup colleagues, that they are less likely to spend money on developer tooling?

Dom: I think that there's a myth that startups are so resource constrained that they won't pay for products like dev tool products. I think that their biggest resource constraint is time, and dev tooling multiplies the productive capacity of engineers.

And because it multiplies the productive capacity of engineers, it means that they're able to move faster and less time.

Steve: So I see this question looming on the board and I have to ask it now. Do you think that DevTools will ever catch up to consumer in design?

Dom: I'm also interested in what you folks think. I don't think so. I think that, primarily because it services a much smaller community. There's certainly competition that drives design and aesthetics and user experience to higher and higher levels, but just by the fact that it's a niche community, it's not being propelled in the same way that consumer products are being propelled to innovate on design. What do you guys think?

David: Yeah, I think it's interesting. I think it depends on what kind of timescale you're talking about, right? I think if we talk about fifty years into the future, programming a computer is probably gonna be more like describing an algorithm to an AI, voice recognition, something, I don't know. It probably won't be typing text into Vim.

And so I think we're gonna start to see trends in that direction, and that programming in general will start to look more like consumer products just because more and more people will be programming, whatever that looks like.

Dom: Yeah, that makes a lot of sense. Never say never, I suppose.

Steve: Yeah, and that's an interesting point, that the very nature of programming might change in such a way that it's more consumer. Almost by necessity we're dealing with a smaller market and a smaller audience. And so there will never be as many people invested in this problem as there are in other problems that are affecting a lot more people.

But I think David's point is really interesting too, that what we think of as programming might fundamentally change pretty soon. And that could completely change the way this works.

Dom: And who knows? I work at a developer tooling company that makes creating great experiences easier than ever before. So perhaps it's just the case where we're working at the problem from two sides. One side is making design and user experience a lot easier to build, and the other side is getting better design based on the amount of competition in a market. Those two factors alone might push design to the next level.

Steve: Yeah, there's no question that space is growing and that there are a lot more opportunities to do developer experience in more and more ways.

Dom: And that seems to be the trend, and the classic trope is software is eating the world, and software needs engineers to actually be built. As more engineers enter the market, the competition increases for them as users of your developer tool product. And it also increases the amount of developer tool products.

Steve: And with every new cycle of technology, there's a new generation of products. We spend a lot of time talking about containers and microservices, and there is a whole new crop of products to manage and deploy and monitor and everything that's specific to containers. And so with every kind of change in technological cycles, we get a fresh crop of products and a fresh opportunity to rethink design.

What Designers Should Look For

Dom: That's right. I think the question here is, what should a designer look for in a company, and specifically a company meaning an organization of individuals? And what should a company look for in a designer or be aware of when hiring a designer?

So from a design point of view, there isn't much of a precedent for design in developer tool companies. And because there isn't much of a precedent, design isn't in the DNA of most developer tooling companies. Because it's not in the DNA, that's something that you have to bring to the table.

And your job as a designer is to bring the design thinking, design process into an organization that you join.

But you also might realize that as a designer, the organization isn't really set up to run an effective design process. And what you're assessing is whether or not they value the design process, they're gonna give you the confidence to run that design process that you know yields results.

One of the red flags that I've seen as a product designer joining companies is if a company boils down design to just thinking that a product needs to be prettier, it's probably not where you want to join as a product designer.

Steve: Yeah, that's a really good one. Like during the interview, it might be really apparent in the subtext of your conversations that when someone says design, they're talking about visual design. And that would be a huge red flag.

Dom: And often that's not what a developer tool company needs anyways. What they need, but perhaps can't articulate, is they need someone to understand the problem space and solve problems. And those problems often aren't really related to how the company appears.

Steve: Yeah, and that they should, one, recognize that there's an opportunity to improve those things, and then two, I think as a designer you should feel that you won't have to fight for your place.

Dom: Yeah, absolutely. And as a company, this reflects back on the company too. So if you're a company and you want to compete on design, which is already a hard decision in and of itself, you also have to understand that you need to be willing to hand off the reins of certain parts of your product to other multidisciplinary people like designers or whomever.

Steve: Yeah, I think it would be really cool as a designer joining a DevTools company to walk in and have them present to me a list of their problems. Like, here are the things that we are not doing well right now. Because, I mean, that would demonstrate so much of an understanding and an appreciation for, like, we understand that this is bad. We've looked at it and we know it's a problem. Help us fix it.

Dom: That would make any designer's job so much easier. Here are what we think the problems are, and go and explore how you can solve them.

Steve: Yeah, and then I've been at early stage companies for a while now, so this is true of pretty much everyone that joins, but you need a certain amount of autonomy. And people have to be comfortable with that much autonomy. And as maybe a junior designer or the first designer at any company, you have to be comfortable with autonomy and you also have to own it.

Dom: Yeah. It's often unclear what you're gonna be evaluated on as the initial designer. Especially in a company that doesn't really have design DNA.

So you kind of make your own role. Or you definitely make your own role in that situation. And you are working off of your own agency, your own moxie to get projects done.

Steve: Yeah, and maybe step one is mapping the territory. You've got to figure out what even needs design help and where to start and working with them on that.

Dom: Sure. One last question, Stephen, that I wanted to bring up was, so you said you've worked on a lot of early stage companies now. How does the designer start? Like, how would you start in developer tools? Start on one product, or like, how do you as a designer move from an agency model to getting into developer tools?

Steve: Yeah. This would be a really interesting series of conversations. Yeah. I think it really does make a great topic, because one of the things that I think all of us have an interest in is recruiting more designers to the space.

And it is hard to sell designers on coming to our companies. They don't understand what we're doing. They don't necessarily like it. If you walked up to a designer, or if you were interviewing a designer and said, we need help with our documentation, they would be perfectly justified in running.

So it would make an interesting conversation about a letter to a designer at a consumer product company about what you would need to do to transition to working on DevTools. I think it's a pretty long list.

Yeah, I think, like I was saying before, one of the biggest mistakes I think I've made is not really appreciating how developers worked. And I think you can only do that by talking to developers.

And I was a junior, relatively junior designer when I started and was kind of closed off. I didn't have that much interest in going and having a bunch of conversations. Like, we had product people that did that.

And maybe it starts by just biting the bullet and trying to have as many conversations as you can to get at the root of how devs work.

And I don't think we could possibly explain that, but you need to learn it. What would you say is the number one?

Designers in Open Source

David: It's interesting. I feel like I'm kind of like the open source trumpet over here, but I'm sitting here wondering, is there a way for designers to actually go out and find open source projects to contribute to in the same way that programmers do or whatever, you know? Whether it's a project you use or whatever, there are a huge amount of open source, really useful tools and projects out there that are just suffering from a lack of cohesive design.

And I wonder if there's somewhat like the experience there, I know as a programmer, is usually very valuable. You come at a project, you might want to submit some changes, but now you come into the sort of the whole hierarchy of the project and have to navigate that and how to convince other people of the changes you want to make, and it seems like, at least kind of at first glance to me, that that same process would be really useful for, like, say, an interaction designer even. I don't know how to bootstrap that process.

Steve: I agree. I wish I could say I've been involved with open source projects, but yeah, many of them have a design component to them and there just aren't designers contributing to them.

Dom: Sure. That's an interesting point and is something that we at Meteor are certainly well poised to figure out. One of the barriers to entry for design in open source projects is actually just getting that project up and running. Folks have to realize that not everyone is going to be technical enough to contribute.

Steve: Yeah, you definitely have to want it.

Dom: You have to want it, but also there's a baseline of knowledge that you need to get a project up and running and then to contribute to it.

And oftentimes what you'll find is designers that don't code or that don't have a strong technical basis, despite being good designers, just have no way to get a project up and running. Like, they don't have pencil or paper and they need to write an essay, you know. They just don't have the right tools to

Steve: Yeah, and there probably is a certain subclass of designer that just won't show any interest or won't want to make that move. I was just pulling up the history of a designer that I really admire, Wilson Miner, who was one of the original contributors to the Django project.

And he got involved because he could write code, but he also, in this one blog post, and I might be butchering the history here, but I think there was a component in Django called generic views, and it was this idea that you could build views out of pieces. And I think that was a pretty new idea when he was getting started, and so he contributed to the design of those views. And so now, that was like a major contribution to that project.

And that is interesting. Like, we've seen it. I mean, some of the frameworks that have taken off, React or Docker.

If you were a designer contributing to that open source project early, that could potentially turn into an enormous opportunity for you.

Dom: Yeah. And an enormous opportunity for those projects as well, because what they get is examples that can draw users in, examples that look and feel like a real app, and because they look and feel like something that could conceivably be real, it's a much easier cognitive leap for someone that is exploring those projects in general, like a potential user of, say, React, to see themselves using it and see themselves building a component similar to an example designed by a designer.

Steve: Yeah, and as you were saying, I think part of it is definitely building the tool set up to be able to make those contributions, because it's not gonna be easy, but it will only get better. I mean, as we were saying, I think we've all gotten better at writing code since joining DevTools companies. And if that's a path you're looking for, working on an open source project would be like boot camp. It would be a great way.

Dom: A place where just this conversation made me think about it is we talk about DevTools companies as one giant entity that requires a lot of technical knowledge. But if you break DevTools companies into the type of product that they end up creating, so for instance, there might be a dev tool company for monitoring, like Opsee, right? But there also might be a dev tool company for reporting. And a lot of the same paradigms that you find in other less technical tools can also be applied to dev tools.

So for instance, reporting. What is the common theme of reports? I find that they're generally a thin abstraction on top of a spreadsheet. And where else can you find that? You can find that in Excel or Google Sheets.

And what do those abstractions often look like? They often look like graphs or tables. And you can start contributing without necessarily needing every bit of domain knowledge.

Steve: Yeah, that's a good point. Like data visualization or trigonometry or graphing, though not programming, like someone who comes from a background working on BI products, or, I mean, something that isn't DevTools at all but would have some of the same components, like building graphs or reports, that experience would be super useful coming to a DevTools company. Or at least Opsee or a monitoring company, because there's a lot of graphing involved. Yeah, and reporting always ends up being a feature we build.

Dom: A feature that people seem to like.

Yeah. Thanks, Stephen and David and Ted, for having me on today. If you want to get in contact with me or learn more about my take on developer experience, you can follow me on Twitter @domyen. D-O-M-Y-E-N. See you next time.

Steve: That's about all we have time for today. If you're interested in being a guest on the show, or if you have a DX topic you'd like us to dive into, you can reach us at dmmc at heavybit.com or on Twitter at Don't Make Me Code.

David: To learn more about Heavybit, visit heavybit.com. And while you're there, check out the library. It's packed with amazing talks from founders of developer tools companies and other industry leaders.