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.
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
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?
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.
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?
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?
or
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.
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."
-
"Why"
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.
