Changing requirements mid-stream is absolutely fine (and often necessary), especially in a startup environment. In fact I make it a point to question and ultimately enhance requirements as I go, and the products I work on are better for it.
The real cause for irritation should be when the reason
for the change is due to ineptitude (poor planning, insufficient research, indecisiveness, poor communication, whimsy, etc). When there are good, justifiable reasons -- uncontrollable circumstances, data unknowable at the outset, reactions to competitors, etc -- engineers should understand the need to change midstream and get on board.
I have found that by far what drives me craziest is being treated like a robot. Engineers solve technical problems, just as designers solve usability problems, and just as 'business people' solve 'business' problems. Going to an engineer asking them how long it will take to do X -- where X is the solution that a non-technical person came up with on his/her own -- is flat out disrespectful.
Specialists are hired to solve problems in their particular field. When the problem-solving aspect of their job is taken away, they become resentful and bored, and the company is ultimately worse off for not allowing the specialist to solve the problems he/she is most qualified to solve. Sometimes it may seem subtle, but it has a big impact on my morale as an engineer. Am I seen as an expert in my field whose opinion is sought on all matters even remotely in my wheelhouse, or am I a robot that receives instructions and produces an output at a predictable rate?
"How long would it take you to do X (what) in such-and-such a way (how)?" is absolutely the wrong way to start a conversation with me about a new feature / initiative that I'm hearing about for the first time. The implicit assumptions are:
- You made the decision to do X without involving me in the conversation.
- You already know X is the right thing to do; you 'solved' the problem for me -- you just need me to implement your solution.
Not only does this diminish my self-worth, but it also de-values me in your eyes as a decision-maker / problem-solver. It makes me into a tool to be used rather than an expert that can help steer the decision-making process for things I am well-qualified to have an opinion on. Further, if I am assertive in pushing back against the pre-conceived solution I don't like, I am forced to be confrontational / argumentative -- and perhaps even an impediment to progress. That's just silly, but it was a set up, I tell you!
Instead, try this: "We have an issue: X (what). Can I get your ideas on how to solve it? My initial thoughts are we could do Y (how) to solve it. If you need some time to think it over, we can talk about more tomorrow (or whenever)." By simply starting the conversation like that you've respected me by involving me in the decision-making process and have (rightly) conceded that I have a wealth of experience / expertise that may be valuable in solving the problem. You've also mentioned your idea as something that needs to be sanity-checked against my experience / expertise, and that's a good thing because, frankly, technical solutions conjured by non-technical folks absolutely do need that.
I've been in the game long enough to know that it's always better to talk out solutions before implementing them. Others may not like it, and you may end up actually doing the originally proposed solution anyway, but until you have that conversation you are in very risky territory. 5 minutes of discussion is a small price to pay to prevent a potentially disastrous implementation just because the engineer wasn't assertive enough to ask questions.
And really, none of this is any different for any other profession. It's all about respect. If you hire / partner with a specialist, presumably your reason for doing so is because you recognize that they are more qualified in their area of expertise than you are. How foolish then to not involve them in discussions / decisions that pertain to their specialty! In theory most people would agree with that, but in practice I have seen plenty of the opposite.
And that, my friends, is what drives me the craziest as an engineer.