Ep. #8, I Only Work On Ugly Products

Steve Boak: 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 dev tools companies and why dev tools companies should be prioritizing design.

Dom Nguyen: Hi, Steven 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: 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, I kind of start with consumer products and kind of experienced a breadth of other challenges running an agency, coming from clients in the education space and the consumer space and the engineering space. Kind of everywhere.

Steve: I thought the story of your agency being 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 just to suit their needs.

Dom: Facebook and Teehan+Lax is one of the notable big acquisitions. Where we came from, 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 we were... In an agency you tend to build software for the end user and you can build it 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 that add 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 dev tools are kind of like the supply chain of the software industry. You know, 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: 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 at an agency, you have this natural incentive. You have a budget, a timeline and, no matter what you might think, your job is 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 client's 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 it that it was sort of a natural evolution of the business, which sort of makes sense.

Dom: It does.

Steve: The best of them know, I mean even Teehan & Lax. I would routinely look at their portfolio of work for inspiration. 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. It's definitely a big challenge.

David Dollar: - So, your design agency got acquired by Meteor. You're coming onboard 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: 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: So you kind of come in and get to start fresh with a new developer tools company, it's got to be an interesting experience.

Dom: Yeah. It's a challenging experience.

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

Dom: 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 has now become part of the sprint cycle. And the way that 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: In many ways it's a blessing that we are designing tools for the people that we so closely work with everyday. 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, often times 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 lock step in the same direction, and that's something that one of the learnings that an agency can bring into a product company in general. And, I'm sure you've probably had a similar experience, Steven.

Steve: Yeah, that is actually a really interesting twist on the logic from before. I think it's 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. 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 byte shedding is happening in product companies than in agencies for sure. I also think that the idea of designers just being acquired into a dev tools 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 the 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. And Meteor, if the audience doesn't really know, it's a development framework that helps engineers build great experiences faster. When I say great experiences faster, I mean they've 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 the 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.

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

Dom: I don't remember what employee number I was. I was in the 20s, 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? 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? I think they brought us on at a pretty good time, of course I'm biased. Primarily because they were launching a product. So rather than... 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, or essentially a SaaS product. 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. Before you brought that up, I was going to say it's never too early. Start with design as soon as you possibly can. There are some cases though in dev tools, as you know, if you're building a framework, an open source product, that you're 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. I find that the companies that either don't need it or 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 the 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 dev tools 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 dev tools 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. Often times 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: 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 the designer is to translate immense machine effort into something that is usable, and documentation is one of your primary levers for doing that.

Steve: I just had a moment thinking while you were saying that about how boring that must sound to a designer, your job is now to work on documentation. But that gets to another question, which is why should a designer join a dev tools company? And, that might not sound so great. You're working on documentation, you're understanding how people write code. And so, why should they do it all? Why not focus on something that already has great design, Facebook, Pinterest?

Dom: 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. At a dev tools 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. Your impact might be, the color of a button or the shape of a button or the visual aesthetic of a specific micro site. 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 everyday. They use my tool everyday. 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 going to 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 dev tools 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 challenge that you end up facing is a bit different, too. In Saa S companies and especially in dev tools companies, you end up having a shorter feedback loop. So, your audience, they're using your product everyday. 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 changes 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 dev tools 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, 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.

David: So, I'd be interested to know here 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. 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 have done a little bit of coding, or at least lightly touched 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 you need to be great at coding to be effective in an organization as the designer in the same way that I don't think a 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 are looking for someone maybe with some technical aptitude, but they certainly have to be able to unpack hard problems, I have to say that for sure. You know only then, if you found someone who is strong, who's able to unpack the problems and who's curious enough to go and talk to people, then writing code is cool. It's a nice benefit. My ability to code has gotten so much better since joining dev tools companies.

Dom:

Yes. If you want to learn to code, definitely join a dev tools 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 anyways.

Steve: Yeah, so when I was looking for my first job in software, I started looking at small start-ups 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. Yeah, that's really cool. If you're a designer who wants to learn how to code, join a dev tools company.

Dom: It will be trial by fire.

Steve: You'll learn a lot. You'll develop a specialization too.

Dom: Yeah, absolutely.

David: Last episode we were talking a little bit about things that we look for here, trying to find people that would be naturally talented at developer experience. We mentioned that we saw some correlation with people that contribute to open source, and you know, 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: 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 is constrained to the visual sphere of things at the superficial level. But, I haven't found that to be the case.

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. 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. 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's really lagging behind software development in this respect, that we don't have this contribution to the community thing.

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

Steve: Again, we're kind of drifting here, but the closest thing I think now with this new age Birt saving tool is that... There are two really interesting things that I think have happened in the last couple of 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 interactions. So now you've got components and interactions which are kind of like the fundamental pieces of that. It's closer to open source.

Dom: Yeah, those are great products to bring up. The closer you get to code, the closer you get to that 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 cohesive vision that you present to users and taking from that piecemeal doesn't often work.

Steve: I've never found myself thinking this yet, but that might be an interesting acid test for a designer. 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: That's definitely something that we've been very interested in at Meteor. Specifically, I've been very interested in producing reusable components and 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: Again, incidentally, it's how developers write code too. You model the component and then you instantiate it and it actually works pretty well as a way of communicating between teams.

Dom: I had a question for Steven 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 that'll depend on the space your 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. I've worked at three monitoring companies now, and so, right way, I saw this as a differentiator for us. It was, I thought, one of the only ways that we were going to 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 awhile, 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 dev tools 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. You know, 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 where you don't have to think about a lot of the details. Sort of very similar to what Meteor is doing, I guess, with general webstack development. Just trying to make this nice cohesive single experience that sort of sits on top of an enormous amount of complexity underneath. So, I think the real reason to compete on design is that. 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: 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. 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 will get a little bit niche, but do you find that among Silicon Valley Illuminati, your fellow start-up colleagues, that they are less likely to spend money on developer tooling?

Dom: I think that there's a myth that start-ups 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 in less time.

Steve: So, I see this question looming on the board and I have to ask it now. Do you think that dev tools 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: I think it's interesting. I think it depends on what kind of time scale you're talking about, right? I think if we talk about 50 years into the future, programming computers is probably going to be more like describing an algorithm to an AI voice recognition, I don't know. It probably won't be typing text into them. I think we're going to 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: That makes a lot of sense. Never say never, I suppose.

Steve: 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. There will never be as many people invested in this problem as there are in other problems that are affecting a lot more people. I think David's point is really interesting too, that what we think of as programming might fundamentally change pretty soon. That could completely change the way this works.

Dom: 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 the space is growing and that there are a lot more opportunities to do developer experience in more and more ways.

Dom: That seems to be the trend. The classic trope is that 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. It also increases the amount of developer tool products.

Steve: With every new cycle of technology, there's a new generation of products. We spend a lot of time talking about containers and micro services, and there's a whole new crop of products to manage and deploy and monitor and you know, 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.

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? From a design point of view, there isn't much of a precedent for design in developer tool companies. 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 you have to bring to the table.

Your job as the designer is to bring the design thinking and design process into an organization that you join.

But you also might realize that, as the 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. Are they going to 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 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. Those problems often aren't really related to how the company appears.

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

Dom: Absolutely. 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 multi-disciplinary people, like designers or whomever.

Steve: I think it would be really cool as a designer joining a dev tools 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." That would demonstrate so much of an understanding and 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's where we think the problems are. Go and explore how you can solve them."

Steve: I've been in 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: It's often unclear what you're going to be evaluated on as the initial designer, especially in a company that doesn't really have design DNA. You kind of make your own role. You definitely make your own role in that situation, and you're working off of your own agency, you're own moxie to get projects done.

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

Dom: One last question, Steven, that I wanted to bring up was 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?

Steve: Start on one product, or like...

Dom: How do you as a designer move from an agency model to getting into developer tools?

Steve: This would be a really interesting series of conversations. 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 in 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, like a letter to a designer at a consumer product company about what you would need to do to transition to working on dev tools. And, I think it's a pretty long list. Like I was saying before, one of the biggest mistakes I think I've made is not really appreciating how developers worked. I think you can only do that by talking to developers. 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. 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. I don't think we could possible explain that, but you need to learn it. What would you say is the number one?

David: It's interesting, I feel like I'm kind of like the open source trumpet over here. 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 know, you come at a project you might want to submit some changes, but now you come into 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 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, 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 it's 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 the project up and running. Folks have to realize that not everyone is going to be technical enough to contribute.

Steve: You definitely have to want it.

Dom: You have to want it, but also there is a baseline of knowledge that you need to get a project up and running and then to contribute to it. Often times what you'll find is that 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 even have pencil or paper and they need to write an essay, you know? They just don't have the right tools.

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 is one of the original contributors to the Django project. He got involved because he couldn't 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. So, he contributed to the design of those views. That was a major contribution to that project. That is interesting. We had never seen it. 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: 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 React to see themselves using and see themselves building a component similar to an example designed by a designer.

Steve: As you were saying, I think part of it is definitely building the tools that ought to be able to make those contributions. Because it's not going to be easy, but it will only get better. As we were saying, I think we've all gotten better at writing code since joining dev tools companies. If that's a path you're looking for, working on an open source project would be like bootcamp. It would be a great way.

Dom: A place where, just this conversation made me think be about it, is we talk about dev tools companies as one giant entity that requires a lot of technical knowledge. But, if you break dev tools 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 might also me 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 spread sheet. Where else can you find that? You can find that in Excel or Google Sheets. What do those abstractions often look like? They often look like graphs or tables. You can start contributing without necessarily needing every bit of domain knowledge.

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

Dom: A feature that people seem to like.

Dom: Thanks Steven 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. See you next time.