Engineering teams in young companies frequently work under a founder whose direction changes often. Some of that is correct — a founder who never changes course in response to evidence is a worse problem — and some of it is the avoidance that comes from a hard problem being replaced by a fresh one. From inside the team the two are indistinguishable, and the indistinguishability is what destroys morale.
The mechanism of the damage is unfinished work. Three efforts started and abandoned at seventy per cent produce nothing shippable, a codebase full of half-built paths, and a team that has learned its work is unlikely to reach users. After a few cycles of that, engineers stop investing effort in doing things well, because the expected lifetime of anything they build is short. That drop in care is very hard to reverse.
The mitigation that works is not resisting change but shortening what has to be finished. If direction changes every few weeks, do not start anything that takes twelve. Slice the work so that something usable exists at the end of two, even if the larger arc is uncertain. That way a change of direction leaves shipped work behind rather than abandoned branches, and the team accumulates a record of finishing.
Insist on an explicit stop rather than a silent drift. When priorities change, ask directly what happens to the current work — finish it, pause it deliberately with a note about the state it is in, or abandon it and delete the code. A founder asked that question will often decide to finish the current piece, because the cost of stopping becomes visible in a way it was not. And where the answer is abandon, saying so out loud is far better for the team than work quietly ceasing to be mentioned.
Then create one artefact that persists across the changes: a short written statement of what the company is trying to achieve this quarter and what it is not doing. It does not stop the changes and it makes them visible, because a new direction either fits the statement or requires amending it. Founders who see the amendment being written frequently reconsider, and teams who can see what changed and why tolerate the change far better than teams who only observe the effect.
