One of the most misunderstood and contentious relationships on cross-functional software development teams is the designer and the developer. When these two archetypes of people get in a room together, very often they end up talking past each other and the conflicts that they have could be resolved. In fact, they work much better when they have each other, but unfortunately a lot of the time these conflicts go unresolved because we're kind of speaking different languages. And beyond that, we tend to make bad assumptions about not only designers and developers and each other, but about people in general. In today's episode, we're going to talk about some of those assumptions, some of the bad patterns, the bad, tight casting and stereotyping of people in these roles, but we're more going to focus on how you can work better together. How can you, as a developer, work better with designers? My name is Jonathan Cutrell and you're listening to Developer Tea. My goal on the show is to help driven developers find clarity, perspective and purpose in their careers, and clarity is hard to find when things are ambiguous. When you're working on a software project, a lot of the problems that you are solving don't necessarily have one solution. In fact, very rarely do we only have one solution to the problems that we're solving, especially in uncharted territory. And companies that are fundamentally in the startup space where other people have not necessarily set up established patterns when there's very little regulation, when there's not really a lot of history of how these problems have been solved in the past. And so we end up approaching problems with our own mental schemas and our own experiences. And then when those things don't line up with each other, we might clash. And this is very much pronounced between the average designer and the average developer. When we talk about designer in this scenario, we're not simply talking about visual design, and this is a discussion that goes well beyond this scope of this episode. We're not going to try to define what a designer does, but we're talking about someone who is not necessarily writing code for production. These are people who may have been exposed to front-end code, but they don't necessarily know how to create maintainable code systems. Their job is more around understanding the user's experience, the different economic trade offs of a given interaction, and how to optimize for the best outputs for the user. That's their job. For the developer, our job as developers is to make possible what is previously just an idea. Now, that's an oversimplified explanation of these two roles, and that's on purpose, because when we come to the table with these two oversimplified roles in mind, very often, we see the conflict in our roles. On the one hand, you have a designer that is pushing for the most optimal user experience. On the other hand, you have the developer who is pushing to make something possible. When the most optimal user experience is difficult to make possible, the developer naturally is going to push for a simpler solution. The designer, when they realize that the thing that is optimal in their eyes for the user's experience, when they receive that pushback, they're likely to believe that the developer cares less about user experience than they care about feasibility. Now, interestingly, this leads to an improper perspective in stereotyping where a developer sees a designer incorrectly, once again, incorrectly sees a designer as idealistic or even unrealistic. Someone who believes that anything is possible and that they can have everything for cheap. And then on the flip side, the designer incorrectly sees the developer as the person who never wants to do anything with my ideas. A person who shuts down anything that isn't incredibly simple, anything that takes effort. They might even apply as extreme of a label as lazy to the developer. And interestingly enough, the designer may even feel held hostage by developers since the designer doesn't have the necessary technical skills to implement the thing that they're trying to implement. They may feel like they're held hostage, that their job is limited by what the developer is dictating or is saying they're willing to do. On the flip side, the developer may feel similarly held hostage by all of the designs that the designer is presenting, all of the design ideas, all of the interactions, all of these things may feel like they're restricting the developer from being able to be productive. And of course, all of these perspectives are purely perspectives, their opinions about how the world around us is operating. But a lot of the time we have the wrong opinions. A lot of the time our assumptions about the intentions of a designer or the intentions of a developer, they're just simply wrong. Like most interpersonal issues, a lot of this can be fixed by focusing on communication and actively rejecting bad assumptions about each other. We're going to talk a little bit more about how to do that more specifically. But first, we're going to talk about today's awesome sponsor, Linode. Linode is returning to developer to you. We're in the fifth, actually going on the sixth year of this show. We've already been around for five years. We're rolling into the sixth year and Linode has been around for many of those years. And for good reason, Linode is a company of developers, builds products for developers, whether you're working on a personal project or if you're managing your enterprises infrastructure, Linode has the pricing, the support and the scale that you need to take your project to the next level. With 11 data centers worldwide, including the newest data center in Sydney, Australia, enterprise grade hardware, S3 compatible storage options and Linode's next generation network, Linode delivers the performance you expect at a price that you would never expect. Get started on Linode today with a $20 credit. That's $20 in your pocket for listeners of Developer Tea and you'll get access to native SSD storage, a 40 gigabit internal network and industry leading processors, the revamped cloud manager, which is built on an open source single page app. You can find that at cloud.linode.com. They have nanoed plans. That's the small nano instance. Those start at only $5 a month. With these plans, you'll get root access to your server as well as the ability to use their well-documented API. It's an a version four at this point. They have a Python CLI and you can even get one click installs for things like WordPress, a lamp stack, game servers for Minecraft and plenty more. Use the promo code Developer Tea 2020. That's Developer Tea 2020 when you're creating a new Linode account over to Linode.com slash Developer Teato get started today. Thanks again to Linode for continuing to sponsor Developer Tea. So many of our career mistakes are interpersonal issues, our relationship problems, so many of them stem from a basic misunderstanding about communication or a bad assumption, a negative assumption, something that you believe on your own implicitly without any rational explanation for why you believe it, just a simple assumption about another person. These things can be incredibly damaging and they're very much pronounced in this dynamic. This episode applies beyond designers and developers, but this is such a common combination and such a common kind of head-butting duo. It's important for us to think about those extreme cases and then generalize this to our other relationships. So I want to talk for a moment though about how we can fix this problem. What are some guidelines? I'm going to give you three guidelines specifically in today's episode, three guidelines for working better with designers. As a developer, working better with designers and these should be very straightforward kind of principles that you can keep in mind when you're working with a designer and especially when you start to have conflict, go back and check yourself against these points of recommendation. Hopefully as you hear these, you'll realize, oh, I can understand how doing that could have changed a particular circumstance. This is one of the best ways you can learn about how you might act in the future. It's easy to listen to this and to agree with all of the things that we're going to talk about here in just a minute, but it's harder to figure out how do I actually apply this in a day-to-day level? How am I actually going to play this out and actually apply what I'm hearing in these particular circumstances? In order to do that or in order to kind of train yourself on that, I want you to recall a couple of bad moments, bad experiences that you've had with a designer. Then try to replay some of your thoughts, some of your rationale, some of your frustrations before you listen to what we're about to talk about these guidelines, replay that feeling. Take yourself back to that moment, try to feel what you felt then. Hopefully as we talk about this, some of those frustrations will be addressed. You'll understand how you might be able to think about things a little bit differently and you can kind of perform this retrospective post-mortem almost well after the event so you can attach this advice to an actual outcome that you've had in the past. Okay, so let's dig into these three guidelines as you begin to work more and more with developers. Here are the three guidelines. The first one is very simple. Figure out what you will optimize together. Figure out what you will optimize together. As we said earlier in the episode, designers and developers have different modes of operation and they have different things that they optimize for. A developer optimizes for feasibility and sometimes for economic viability. A designer tends to optimize for experience. Sometimes a designer will also optimize for economic viability but probably through a different lens and because there is a different perspective from both of these people, when they come together to create a product together, they actually have something that they're supposed to output together in combination. Then finding a common ground metric that they can optimize for. It doesn't have to be an explicitly measured metric per se but some common goal that both the designer and the developer can agree on. Now when they have a conversation discussing the trade-offs or the merits of one particular direction versus a different direction, they can point to their reasoning. Why are we choosing to do this way versus this way? This gives you ground to measure the rationale of your decisions together. For example, if you're optimizing for time to market and a goal is to reduce the total amount of time that it takes to release this particular feature. You might be able to, as a developer, make the case for simplifying a feature that is more complex than necessary to achieve whatever function that feature is trying to achieve. On the flip side, you may have a shared optimization metric of user delight and that may be going above what you normally would instead of just meeting functional requirements. You may also want to meet some extra unexpected surprise requirement, something that provides an additional kind of unique factor. This may not necessarily be the easiest thing to implement but it may also carry a lot of value based on your chosen metric that you're optimizing for. If you don't discuss this, what you end up doing is optimizing for your different metrics. What's important to one person isn't necessarily important to the other, even though you might have some shared understanding of the goal until you align explicitly on how you're going to measure against that goal, you'll continue trying to meet the goal with your own optimization strategies. The second guideline, allow headroom for character. So what do we mean when we say character in this format? Designers and developers choose to approach problems from their own unique experiences and tastes. So if every single decision that we make has to be compressed into some economic algorithm, why we chose that particular way of doing things. Then we lose a lot of the input that we would otherwise be providing based on our own experiences and taste. The goal of this guideline is so that both sides can be completely honest about their reasoning for choosing to do things in a particular way. Both sides can feel okay about saying that I like this style, that I think that this is the most interesting way to solve the problem. Or I think that this particular factor, this one decision that I made, I could have made it in five different ways and I personally like the second way, even though it doesn't necessarily have any particular merit over the other ways. This is a delicate guideline because sometimes we have to draw the line on our taste versus what we're optimizing for. Just because we like a particular way doesn't necessarily mean that that particular way is the most optimum for what we're trying to do, the work that we're actually doing. We have to disambiguate between what we're doing for our hobbies or as a side project where we have total kind of free reign to choose esoteric pathways just because they're interesting for example or a designer to choose an over-designed solution because it's interesting to them. Sometimes we're going to have to draw the line. But whatever is interesting to us when we bring it to work, we often enrich the product. This isn't a direct correlation. Interest is not a direct correlation to quality or to success, but it is a direct correlation to engagement. If you're interested in the work that you're doing, if you enjoy it, if you like the work that you're doing, then you're probably going to engage it differently. You're probably going to engage it more intentionally. To leave room for taste, leave room for character, provide some level of comfortability to talk about your work in terms of style, in terms of unique approaches, personal approaches, personal opinion, being some part of your reasoning for doing things. My third and final guideline is to avoid the power switch. What do I mean by this? Avoid shutting down the conversation. Avoid cutting off the possibilities. It's very easy to say no, that's not possible. To send one of the other person back to the drawing board. To kind of stonewall, to come to a complete disagreement and then stop. If you are on the side of the fence that is kind of providing feedback, if the designer is presenting an idea to you and you're supposed to provide comment on the feasibility of that idea, one of the worst things you can do is simply say no, it's not possible. Instead, avoid the power switch. Don't turn the conversation off. Keep the conversation flowing. You can explain in response to a designer presenting something that you think is difficult or probably not worth the effort, explain that it is probably possible to do that thing. Most things that a designer is going to present to you are likely possible unless they're asking for you to change some policy that another company has or something like that. Something that you don't really have the direct control over other than that. A lot of the things that were asked to build as developers are possible, but they're not necessarily possible within given restrictions. So your response should reflect that trade-off discussion, but it should also continue forward and try to find the next best alternative. What can we do instead? How can we adjust this in a way that still accomplishes what the designer is intending to accomplish? How can we collaborate on a similar solution or perhaps even a better solution that is possible given your restrictions? I want you to think about this this way and this is what I'll leave you with in today's episode. I want you to think about yourself as an accelerator of ideas, someone who makes things possible, rather than someone who shuts down ideas. Think of yourself as the opposite of that archetype, the idea accelerator rather than the idea killer. How can you encourage and enhance the ideas that designers and product owners really anyone outside of your engineering organization when they bring those ideas to you? How can you be seen as someone who empowers those people rather than the person that they don't want to talk to you, the person that shuts down their ideas? This is not something that you should do in a way that is artificial. You shouldn't pump up people's egos, but instead you should talk to them about working towards alignment, about finding good solutions that are economically viable and turn out to be optimal. Remember, finding shared optimization and leaving room for taste, leaving room for personal input for character and finally keep the conversation rolling. Avoid the power switch and instead find the next best alternative. Thanks so much for listening to today's episode of Developer Tea. I hope this was a helpful discussion on how you as a developer can work better with the designers in your work world. And this is, again, extends beyond designers that we're talking about how you can work with really anyone else who has differing opinions from you, people who have different objectives from you. Thank you so much for listening. Thank you again to Linode for sponsoring today's episode of Developer Tea. Also, by the way, Linode is hiring, however, to Linode.com slash careers, you can see the open positions there. And if you want to start a brand new Linode account and get that $20 worth of credit, ever to Linode.com slash Developer Tea, reminder that promo code is Developer Tea 2020. That's Developer Tea 2020. If you are a designer or a developer and you found today's episode particularly insightful for your relationships with the other half of that duo, then I encourage you to have a conversation about this. Have a conversation in your team, in your company, between you and another developer, you and a designer, and discuss how you can work better together and the assumptions that you've made, the bad ones that you've made in the past about each other. Also, of course, it would probably help if you send this episode to them so they can have kind of a background for this discussion. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrella and until next time, enjoy your tea.