I am asked to implement a design which I am strongly against. How do I say professionally "to me this is not the best design but I will implement it because you insist"?

I suspect that the lead developer does not want (or cannot) share the real reasons behind the design decision.

This question is about the right phraseology only.

  • 16
    I suspect the correct answer depends on company culture, and thus cannot be usefully answered in the abstract. Commented Oct 21, 2019 at 13:00

11 Answers 11


TL;DR You do not agree or disagree, you fulfill your obligation of informing about the potential problems. Providing the solution is secondary and even optional (it is ok to point out a problem that you do not know how can be solved). The tone is that you do not want to take the decisions, you want to help by informing those who take the decisions.

Avoid the "I will do because you insist" part. It sounds vindicative and gives the impression that, since you do not agree with the proposed solution, you are not on board with the project and will do the bare minimum.

Also, it is kind of redundant: if you are not the people who has to decide then your role is to accept the decision.

Just raise your objections for consideration, mainly by explaining the potential problems you see, not the solution that you would use. This allows the decision makers to gauge what is actually at stake; centering on your proposal could look like as an imposition. Make your statements opinions or even questions: no "This algorithm will be too slow" but "I think this algorithm will be too slow" or even "Aren't you worried that this algorith could be too slow?".

Avoid being judgemental about the current solution (no "it is bad/obsolete/wrong") and the people who designed it (no "I think he has hidden motives") to avoid conflict in a situation where you can only give advice.

Do a comprehensive list of all the issues that you can see and deliver it all together: complaining about one issue now and another two months later and another three months later would make it look as if you are just trying to stop the progress of the project or trying to find excuses to justify your failure. Of course some issues can only be discovered when you already have done some work on the project, but try to keep that to a minimum.

And last but not least, be conscious of the circumstances of the project. At the start of the project it is relatively easy to change it to address problems, criticisms at the end of the project when it is very difficult to change are probably less useful and could sound as excuses if the project has run into difficulties

  • 54
    "Aren't you worried that this algorithm could be too slow?" might be perceived by some as aggressive. Perhaps one might consider suggesting using language such as 'will this be fast enough for what we need given x,y,z ?" That is much more neutral / inquiring / taking team approach Commented Oct 20, 2019 at 22:16
  • 3
    And of course, bonus points if when making your arguments you can use concrete business cases to motivate them. For example, "when integrating with system X, they send the whole inventory at once, which can number up to 10,000 items; I am concerned that the algorithm presented here cannot deal with that many". Hopefully it can be prototyped to validate (or invalidate) your concerns ahead of time. Commented Oct 21, 2019 at 6:55
  • 5
    A good answer but there is cases where I would definitely be judgemental. I have a background in GDPR and I have had to correct a lot of software developers on how to handle personal data. But there we also occasions where I was overruled, and I implemented the thing in the decided on way. But I definitely let my boss know, in writing, it was a bad implementation.
    – Pieter B
    Commented Oct 21, 2019 at 7:56
  • 7
    @Nelson sometimes you need to be confrontational for a better working relationship in the future. Even with higher-ups. Avoiding all conflict is bad. As a software engineer you really need to be able to say something is a: "very stupid idea."
    – Pieter B
    Commented Oct 21, 2019 at 9:31
  • 5
    Avoid being judgemental about the current solution (no "it is bad/obsolete/wrong") - but sometimes things are objectively obsolete, like when they're designed to use obsolete toolkits / frameworks / protocols. Or not using current Android / iPhone guidelines. And sometimes things are objectively wrong, like design that blurs the line between ads and sponsored articles and genuine ones beyond what local laws allow.
    – Mołot
    Commented Oct 21, 2019 at 11:43

It's ok for you to discuss this with the lead developer and ask why this approach was used over another.

Treat this conversation as a learning exercise for you - there might well be reasons that you haven't thought about or considered.

Can I ask a question about the approach for doing this project? I thought at first it would be better to do <xyz> when I read the requirements document, is there a reason why this wouldn't work in this scenario?

  • 7
    I've made myself the rubber duck in these cases. Ask for the person to explain why their approach is the preferred one, and usually I'll either learn something new, or the other person gets a chance to really examine my idea, without it becoming an exercise in defensiveness Commented Oct 21, 2019 at 12:22
  • @JohnHerbert This is also the most likely way of actually getting it changed when you aren't holding (m)any of the cards; if you approach from ignorance (I want to do what you say, but <I need clarification to continue / I want to understand why this is the best option>) and try to walk them into their own issues it's much more likely they'll fix it, because they noticed the issue themselves. While I was enlisted, this worked plenty of times in the military convincing officers to do something different. Bonus points: it gives you an easy out if you're wrong. Commented Oct 22, 2019 at 19:41

If you think there will be future problems or inefficiency the professional thing to do is cover your back and do your best to make it work.

You may have the opportunity to be heard before the decision is made, but once it's made you pull with the team and do it professionally.

You cover your back by getting the instructions recorded via email if nothing else.

  • 1
    You may have the opportunity to be heard before the decision is made. Most often than not, the OP will only know the details of the decision after it is made. That should not stop the OP from warning of any potential issue that he can foresee.
    – SJuan76
    Commented Oct 20, 2019 at 11:24
  • 6
    Why is this downvoted? I am a software professional and roll with decisions, even when I disagree with them. But I will definately cover my A. If people come looking for heads to chop when something miserably fails, you want to have it recorded that you also though it was a bad idea.
    – Pieter B
    Commented Oct 21, 2019 at 7:50

Raise the concern -

"I have some concerns about the selected solution design. Is this open for discussion, or is it beyond the scope of my responsibility to bring this up?"

If they say something like "It is out of the scope of your responsibility, but if you tell me what your concerns are, I can pass them on to the appropriate people" - then that's a win because your concerns are heard.

If it's something more direct where they want your input, directly, that's even better.

If they come back and say "that is outside of the scope of your responsibilities and duties and we don't want to revisit it," then your response should be "I understand, thanks for answering my question. I will move forward with my work" - and your concerns are on the record, but you don't have the loaded language of "well, if you insist" which will come across as very begrudging, not really accepting, and not trusting of the other team members.


In agile project management and some other fields, there is the fist of five voting technique. A proposal is put to the group and on a starting cue, all show zero to five fingers. The exact definition of the various votes differs from writer to writer, but zero tends to be "no way" or even "veto" while five is "great, I'll organize it."

Somewhere in between, around two or three fingers, is "not my choice, but I'll faithfully try to implement it."

What you need to say is "I accept this decision and I will do my professional best to implement it. Ask me if you want to hear my objections/counterproposals."


As the question specifically requests phraseology, here are my suggestions, preferring words like concern and avoiding words like disagree and insist:

If given the task in a meeting where the lead developer may want to save face:

I have a concern about it, but I can certainly do it.
(this lets them choose whether or not to ask 'and what is your concern?' during the meeting)

If speaking in private:

Hi [name], do you have a minute? I have some concerns about [the project]. I think [the new menu design takes way too much space and will make the whole application harder to use]. I can certainly do it anyway, but I wanted to check with you before I do it.

If writing email (be cautious about cc's in such a situation):

I have a concern about [the new menu design for the project], specifically that [it may take too much space. This could even make the application difficult to use.]

Please confirm if I should go ahead with this?

  • Those are all excellent ways to phrase it. I have used all of them at different points in my career, and I don't recall anyone being offended. Another possibility is to characterise your concerns as "risks" rather than as reasons to do it differently. The difference matters because identifying risks is a normal step in project planning, and not generally perceived as a criticism. There may be "soft" reasons for doing it that way, such as "I've tried to fight that battle before, but management doesn't trust that technology". Such concerns are valid, if not technically optimal.
    – mhwombat
    Commented Oct 25, 2019 at 19:23

Ask for clarification

If you see problems in the design, ask about the desired behavior where the design breaks down. For example:

What happens when 5 users access this form at the same time?


How should I handle it when I get an HTTPError in this part of the code?

This will serve two purposes:
- It will show that you understand the design and its shortcomings, and
- It will help you solve the problems you see in the design itself.

This is often referred to as "The Socratic Method."


Depending on your role, you don't. At best, you might ask "have you considering something along the lines of design. I was thinking it might be better because of reasons".

Be curious.

  • 6
    In this sense, staying silent is agreeing. You can't say after a few months: "yes, I did think it was a bad idea for this and that reason."
    – Pieter B
    Commented Oct 21, 2019 at 7:51
  • 1
    @PieterB but saying "have you considered solution to potential pitfall, I was thinking it might be better because of how the pitfall can hurt us?" puts OP in the clear. Especially if there is a paper trail. If the pitfall happens, he can and should he pointed it out. If some other bad thing will happen, he at least can point out that he had bad feelings about this.
    – Mołot
    Commented Oct 21, 2019 at 11:47
  • @PieterB Silence isn't agreeing, but it isn't disagreeing either. A lot of times, again depending on your role, you're being paid to implement. The decisions have been made, and now is the time to act. However, if it's a ethical or legal issue, you do have the responsibility to speak up.
    – Malisbad
    Commented Oct 22, 2019 at 0:08

Given that the lead developer has the higher level vision of how this design would fit into the organization.

You could only disagree if the lower level details that you are implementing is causing problems.

For example, a design that is error prone and increases your firefighting/support workload.

Another example, a design that paint yourself into a corner. Additional workload that is not obvious is required for daily operation.

Question on how he could avoid these problems. Is there strategy or additional resources when things goes south. Of course most leader would promise everything, keep things on record when the leader throw you under a bus.


How about: "this looks for me not the best way but I will do because you insist"

I realise it's what the OP was, but why do people have to make up all kind of ways to put wording between the lines... Maybe it's cause I'm Dutch, we have the tendency to just say how it is.


The problem here is that you haven't been consulted from the get-go. Development is a collaborative process from start to end.

Moreover, I find it puzzling that you need ask us how to object to a design choice. Whenever a technical decision is being made there should be a debate as to its validity amongst the team.

The way it has always worked out for me and my colleagues, is if you wish to voice a disagreement with a choice you simply state it.

"I don't think it should be done like this."



And a debate ensues.

Sometimes it ends in "sorry, this is a result of a business decision, but I understand your point." which may be the case here.

In other cases it will result in "I hadn't considered x, you're right.", or in other cases you'll just be wrong, but you will learn a thing or two as a result of that debate.

So, to answer your question - just state your concerns. "Hey lead, I've reviewed the spec, but I'd like to suggest maybe we do it this way....". Ensuring you state the pitfalls to the current design and the benefits of yours.

As above development is a collaborative process, and if you're made to feel like you cannot contribute your suggestions to design decisions at this company then I suggest you find another.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .