How to Say ‘No’ to Other Designers and Developers

We recently did a post on how to tell your clients "No" which broke down the multiple considerations that need to be weighed when you are approaching this ground under these varied circumstances. Along with this handy online flowchart, Should I Work For Free? has you pretty well covered on that end. Now we bring you the other side of that coin: how to say "No" to other designers and developers that you might be working along side in any given project. [fblike] Let's face it, we all know that there is a right way and a wrong way to handle these occurrences, however, when we find ourselves facing such a situation, we tend to just charge forward without any considerations being made whatsoever. This can lead to a number of issues arising out of this working environment unnecessarily, especially since with just a little more thought and effort on our parts, these potentially volatile situations can be diffused properly. Just like we did in the last installment, we are going to start off by examining the various project points that we need to take under consideration before we boldly step forward and start throwing wrenches into the proverbial works. Once we have covered those things that we should always keep in mind, then we will look at the delivery itself for some final tips on moving out of the "Yes" person.

Is This a Personal Project?

First off, when you are working with another designer or developer and you come to a point where you have to tell them "No", there are considerations that should be weighed that all fall in your path if the project you are working on is a personal one. This will determine the best way to handle the situation and proceed toward the project endgame.

Whose Idea Was It Anyway?

If you are working on a personal project then the first thing to consider when you are telling your teammates "No", is exactly whose idea is this project that you are tackling? This helps to make your course of action a little bit clearer. Or rather, it should. After all, if the idea that gave rise to this whole project is yours, then telling the others "No" on suggested solutions or approaches is not like you are challenging them, it is simply like you are holding to your original vision. It is your project and you have a solid idea of how you want to achieve it. So telling the others "No" is a bit easier. However, on the reverse side of that, if the idea for the project was not yours, then telling the others "No" can seem more like you are challenging their ideas and implicating that you know what is better for their project than they do. So you have to naturally handle those instances with a gentler approach. Not only that, but if the project was initiated by someone else, then you have to understand that your objections may not stand, and the others might proceed in spite of them. That is something else that you have to be prepared for. Also, in these cases, remaining insistent and clinging to your objections will only tend to complicate the working environment and relationships, so be prepared in team situations and to accept compromises. Even if you are a key player in making this project see the light of day, if the idea for the project belongs to someone else, then they tend to be the understood head of the hierarchal structure and therefore, all final decisions should be left up to them. After all, it is their vision — we have merely agreed to help them see it through. In Short:

• If the idea for the project is yours, then saying "No" is easier as it is expected to be your responsibility.
• If the project belongs to another, then saying "No" is more like challenging their vision.
• If the idea is not yours, then expect for your objections to be overruled and your cooperation to be expected to continue.
• Whoever’s vision brought the project into play, tends to be the final shotcaller.

What Part Were You Brought in to Play?

Another consideration that we need to weigh when we are thinking of telling other designers or developers on our team "No", is the part that we were brought in to play on this project. Our expertise is usually what gets us into this position and it is this expertise that we are expected to bring to the table. So when we find ourselves on the verge of saying "No", we have to consider if the impacts of this objection fall strictly under the umbrella of our expertise or not. Is this simply a personal objection that we have, or is it our skills telling us that this is not the way to go forward. If it is our expertise that is warning us about this way forward, then we should always speak up. After all, that is what we were brought in for. If it is a personal reason that we have, then we may not feel as obligated to mention it or voice our objection, which might be the right way to proceed. If we have a personal disliking of the color orange, but for the project it communicates well with the message, then yes we should more than likely let it go. However, if it is a choice being made which takes the project places we do not feel comfortable with, and which we believe can hurt the integrity of the project then our personal objections need to be heard. For the comfort of our working environment and for the project itself. Chances are, we are not the only ones who will have this reaction. These reactions are another perk of having your perspective on the team. When we are working as part of a team, it is easier for us to be able to step outside our role as collaborator in areas that are not strictly under our expertise, and into the role of user. Many valuable insights can be gained in juggled perpsective, and often times we are brought into a project so that we can provide both personal and professional project assessments. In Short:

• Both our expertise and our personal reactions can favorably impact the project when we constructively voice them.
• Anytime our expertise urges us to object, then we have an obligation to tell our teammates our concerns.
• Our personal objections that do not fall under the umbrella of our expertise can provide valuable insights to the project from a user’s perspective.
• Not all of our personal objections are necessarily vital to the project’s course of action.
• If a projected course makes us uncomfortable in any way, we also have an obligation to tell our teammates about our objections.

Is There Room to Compromise?

Whenever we are working with others and we come up against a barrier which makes us inclined to tell our teammates "No", we have to consider this before we act: can we find a way to make this work without compromising our reputation or personal code? If the answer is yes, then perhaps we should accept this compromise and move on with the project. After all, whenever we tend to be attached to a personal project, we tend to be doing so for the fun of it all. So if we do not have to make things unnecessarily complicated, then why not keep with the spirit in which we signed on to the project in the first place and just roll with it? Even if the project is one that we initiated, there are times, when we may find that yielding to the expertise of those we are working alongside is the best possible course of action for the project. So if we can find the room to compromise and still reach our desired outcome, then what is the harm in being flexible from time to time. In fact, these kinds of compromises can serve to keep the entire team morale up, and that is always good for the working environment of the project. If the others always feel as if their ideas are being shot down, then their level of interest and passion for the project may start to decline. In some cases, compromise might not just be the best way forward, in order to get your project to see the light of day, it might be the only way forward. Sometimes our lack of expertise in areas of the project could be a hindrance if we do not leave ourselves a little bit of room to compromise. In Short:

• If we can reach a compromise without compromising ourselves or the project outcome, then it may be the best way forward.
• Most personal projects are began out of fun, compromising could help maintain that spirit and tone for the project.
• Compromising with your teammates can help to keep up morale during the course of the project.

Where Do You Go From Here?

Whenever you feel that you must tell the other designers and developers with whom you are working with on a personal project "No", another fact to consider would be the future. Not only the projects, but yours as well. Does this mean the end of your inclusion in the project? And if it does, do you wish to work with these people again in the future? If it is your project and you are telling them "No", does this mean the end of their parts in the project? Which in turn, could mean the proverbial back burner for the project until you can replace them. Or worse, it could spell the end of the entire project altogether if they cannot be replaced. So where things do go from here, plays a big part in how we handle this situation for sure. If we wish for the project or the working relationships to continue, then we need to handle the "No" with kid gloves and find ways to soften the blow that this kind of rejection can inevitably be packaged with. Explain the reasons why we strongly feel that this is not the right course of action. Try to control any negative wake left behind us. Whereas, if we feel that our involvement in both the project and working relationship has run its full course, then we do not have to dress up our objections — we can simply let them be voiced and let their impacts have whatever wake they might. This is not to say that we should ever set out to burn any bridges in the design or development communities, no. But more saying that there are instances where we will inevitably care less if our telling others "No" has lasting effects upon certain projects or groups. Then there are going to be others where we are careful to ensure that we leave things in a more positive way. In Short:

• In personal projects, where our "No" leaves things overall, should still be a concern for us.
• If this means the end of our involvement with the project or the other designers and developers, and we wish to work with them again, then we should handle this with tact and care.
• If this means the end of our involvement with the project of the other designers and developers, and we do not care to work with them again, then we tend to handle it more bluntly.

Is This a Professional Project?

Now we come to the considerations that you need to weigh when you are working with other designers and developers on a professional project and you have to reject an idea of theirs for one reason or another. Given that on professional projects there tends to be money and contracts involved, you saying "No" can have much heavier repercussions, and therefore deserve even further considerations than have already been discussed.

Who Brought Who On Board?

Just like who the idea belongs to on a personal project can establish a sort of hierarchical structure to the working order, on professional projects, who brought who on board the project can also attach the same structure to it. Now, naturally the client gets to set the pecking order however they see fit, though as a matter of professional courtesy, if you have been brought aboard the project by another, then you might want to first voice any objections you have to them. After all, it could end up reflecting upon them anyway, given that they are the reason you are working on the project. So why not give them a heads up? Now if we decide that we must tell the others that we are working with that we are not going to comply on something, and we first go to the person who brought us on board, we have to understand that we effectively put our way forward in their hands. If they listen to our concerns and decide that we should not press this issue, but instead compromise, then we might just have to accept that and move on — one way or another. Either by accepting their decision or leaving the project if we feel we must. Or if they decide to push the issue with us, then we at least have an ally as go forward with our concerns. But either way, if we take it to them first, then we are not only acknowledging this hierarchy, we are somewhat agreeing to follow it. This is not to say we cannot challenge their decision by further voicing our concerns, it just says that once we have acknowledged their position in the structure, going around it tends to come with heavy consequences. This should be known before we proceed. In Short:

• If we are brought into the project by someone else, then it can reflect on them when we say "No" to the others on the team or refuse to comply.
• It might be considerate to first voice our concerns with the one who brought us on board out of professional courtesy.
• The one who brought us on board can effectively be installed as the one who decides our course forward.

Should This Go Over Any Heads?

Another consideration that we have to make when we are telling the other designers or developers that we are teamed with a "No", is how far up the proverbial chain should you go? Is there any reason for our concerns or objections to be taken beyond just the other members of our team? Given all that it is involved once again in a professional project, with regards to revenue and contracts, we have to decide if what we find ourselves coming up against warrants full disclosure to the higher ups, or if in fact, this is a concern that could be worked out amongst the team ourselves. Here we tend to let the situations guide and gauge our responses. For instance, if we are working in a team and another asks us to help cover them by picking up some of their slack, we might be able to decline without it being a big deal. However, if we find that this same person is always asking for our help to pick up their slack, thus effectively dragging the project down with them, then we might have to take our objections a little further and let someone else above us know exactly what is going on. This way they can take the necessary actions to improve on this aspect of the team or project environment. After all, there are bottom lines to be considered. So there are times when we find that it is simply not enough to tell another member of the team "No", but that we have to take these objections to others in order for them to have any true impact on the project at hand. This is not always an easy or popular route to take, but it tends to always be the route that best serves the project in the end. In Short:

• There are times when it is not only appropriate, but it is necessary, to take our objections further than to just a single member of the team, or to just the team itself.
• Given the weight attached to professional projects, sometimes saying "No" to another teammates may not be enough.
• Situational indicators can often determine how high up the chain of command to go with our objections or concerns.

Where are the Deadlines and Relationships?

Another consideration that has to be made when you are telling other designers and developers "No", especially with a professional, paid project, is the impact your objection will have on the overall project deadline. Now this is not to suggest that you should bite your tongue just to meet the looming project end date, only to say that you should keep this in mind when you handle how to approach this "No". Your approach is further determined by the status of your working relationship with the others within the team. The stage that you are at and the distance you have between you and deadline can determine how you tackle any project refusals. If things are just getting started, then the rejection of ideas is natural in what tends to be the brainstorming stages. If you are new to working together, and just getting started there, then again it is natural to reject each others ideas as you feel each other out, even though you may feel reserved and a bit guarded. During the middle of a project or pairing, as things are more entrenched and people are more invested, then telling someone "No" can be trickier. More tact tends to be required and you have to be more willing to propose alternatives not to just reject out of hand. In the latter stages of a project more tends to be required than just a rejection, we have to be willing to explain ourselves. Though in the latter stages of a working relationship, this rejecting of ideas gets easier once again, and less complicated with ego and pride even with a deadline looming. So where you are at in the project and in the partnership with the other designers and developers can also effect the way your rejection is taken by the other members of your team. And they should also be given their full weight and consideration as you prepare to tell them "No". In Short:

• The stage you are at both in the project and the working relationship can effect not only how you approach telling the others "No", but also how they take it.
• The project deadline should never be out of focus as you discuss your objections, in fact it should define your approach.
• The closer the deadline, the more comprehensive as well as helpful your rejections should be.
• The more developed the working relationship, the easier telling your team members "No" will be.

Where Do You Go From Here?

Just like with the personal projects, in professional ones, you should consider where exactly this saying "No" leaves you. Always ask yourself how this will impact the future. Is this going to have an impact on the rest of your time with this company? Are you going to have to work with these other designers or developers again on future projects? And of course, you always have to ask yourself, do you care if these areas are effected by your decision to decline an idea or say "No" to a project? Though admittedly, the answers to those questions rely heavily on just what it is you are being asked to do that you are turning down. For instance, if you notice that your company is trending towards taking on clients that you find more and more objectionable (for whatever reason) then you might be fine with letting some bridges burn as you refuse to comply. Even if you know it could mean the end of your time with the company. In which case, be as open and honest as to why you object to the work and be sure that it is gotten on record. However, if you find that it is only one particular project that you find yourself on where you feel you must say "No", and you do not want it to negatively impact your stay and status with the company and the others you work with, then you might want to find more even-keeled approaches to these refussals. When it is all said and done, we may not have a choice as to who we are going to be partnered up with from project to project, but as long as we know where we are hoping to end up in the end, then the way forward tends to become clear. Not only that, but the way to handle saying "No" also gets a little easier to see. In Short:

• Always keep where you want to go from here in mind when you are saying "No" in professional projects, just like in personal ones.
• If you feel like the company you work for is beginning to take on more clients that you object to, and you do not care to remain with the company, be open and honest.
• If you feel like this project that you object to is not the norm, and you wish to not have your refussals hurt your future with the company, be more tactful and less confrontational in your approach.

The Act Itself

Now that all of those other considerations have been made, there are some underlying rules to handling these kinds of refusals that you want to keep in mind. These do not vary much from the rules we talked about in the client post, however they apply here as well so we had to cover them too. The other designers and developers that you are working with, or that you could potentially be working with tend to appreciate when we adhere to these guidelines in our rejections.

The Golden Rule

First things first, whenever you are telling another designer or developer "No", remember the golden rule: Do unto others as you would have them do unto you! It applies here as well. We have to remember that whenever we tell someone "No", there is a chance that they might not take it well. So we need to put ourselves in their places. If you were in their shoes, how would you want this to be done? This should at least ensure that, above all else, we handle these situations with some modicum of respect. Even if you know that bridges may get burned in the process, as long as we take their feelings into consideration, we will come out of the situation having walked the higher, more respectable road. As we have said before, not many people respond favorably to being told "No" about anything, but if we always come from a place of respect and understanding, no matter what we are met with in return, then we have done all that we can to ease this possible blow. It may not be the easiest approach to take, but it tends to produce some of the best results. In Short:

• Put yourself in their shoes, and ask how you would like to be treated in their situation.
• Always be respectful when you are telling others "No" — it tends to make the situations less volatile.

The Courtesy Call

Speaking of respect, the next rule of handling these situations tends to come from this same arena, and that is the rule of the courtesy call. This is not always a literal call, as much as it is a virtual heads up, so to speak. You never want to just leave the requests that you have received from other designers and developers unanswered and unaddressed. You should always take a moment and do them the courtesy of getting back to them on whatever issue they have sent you to tackle or provide your take on. But unfortunately, in this fast-paced business environment, timely returns on their requests are not always possible. Couple with that, that usually we are not in any big hurry to forward our rejection so we tend to backburner our ‘No’s rather than send them along in a timely manner. However, none of this means that we should just give up on getting back to them altogether and just continue to work the project without communicating with the others you are teamed up with that you will not or cannot comply with their request. Often times, when someone from the team reaches out to another member of the team, for most any reason, they will put themselves in somewhat of a holding pattern until they hear back. Causing the project progress to potentially grind to a halt while we ignore the issues or queries sent to us via the team. So we should always take a few moments each day and reply back to any project inquiries or change requests that we have gotten that day, whether we feel like addressing them or not. In Short:

• Be courteous enough to reply with your declines in a timely manner.
• Do not leave others hanging in a holding pattern because you do not want to tell them "No".
• Take a few moments out of each day to specifically address any other team member concerns you have been sent.

Never Be Vague

Another rule that makes a huge difference in the refssal arena, is one that we covered in the previous post, but whose relevance remains intact in this case, and that is not beat around the bush with your declines. Often times in order to ease the blow of our disagreement or objection to something in the project, we tend to not be as direct about the whole thing as we should. But you want to be sure that everyone understands that you are giving a definitive "No", and to do that, we have to make sure that we are not being vague at all, but instead are giving a clear signal that is not going to confuse the issue. In Short:

• Always be as clear as you can when saying "No" and use concise language to not confuse the issue.
• Do not let your discomfort with deciding to decline allow you to be vague and dance around the issue.
• Everyone always needs to be on the same page, and your decline is no different.

Be Forthcoming When Appropriate

When you are dealing with other designers and developers that you are working with on a project and you feel like you must say "No", then you want to be as forthcoming with the details as you can appropriately be. If you can, provide them with more than just a "No", give them a glance at your reasoning. If there is a particularly bothersome element of the project that makes you uncomfortable, they might eliminate this troubling element in favor of bringing you on board or keeping you on board. Naturally, there might be some of the reasons that you wish to keep to yourself, and that is completely acceptable. But when and if you can, provide them with some insight behind your decline. In Short:

• Try not to just tell them "No", but to give them a peek at your reasons when appropriate.
• This is not arguing for full disclosure across the board, but some idea as to why you are declining is respectful and appreciated.

The Tone Tells It Like It Is!

Just like we discussed in the last post, any time we are communicating with others, we have to be aware of our tone at all times. This is one of those understood communicative rules, but one that we still tend to forget in this digital age where many of our communications take place in the virtual realm where our tone of voice does not accompany our words, and nearly any tone can be applied over the top of them. This is not always within our control, but it does allow us to remain alert and watch out for our tone to say more than we intend it to. Going over our thoughts or messages before we share them is key for helping to safeguard against this unintended tone attachment. In Short:

• In communication, especially in today’s digital world, it is quite easy for the tone of our words to be misinterpreted.
• Vet your thoughts and messages for instances where unintended tones can be applied.

That’s That!

That wraps up this side of the discussion, but once again, we turn the topic and the dialog over to you. Feel free to keep dissecting this discussion in the comment section below, or raise any points that you disagree with, not to mention those you feel were not covered enough (if at all). So take the reigns and keep the topic growing below.

Consider Some of our Previous Posts:

• When Designers and Developers Work Together is a post to check out for more on how designers and developers can work alongside one another.
• Improving Client Relations and Enhancing the Work Process: for all of you out there who are having difficulties with clients.
• Breaking Down the Design Process: knowing when the price is right!

(ik) [fblike] Featured Image by Nadine Shaabana on Unsplash