If I suggest a simpler prototype approach, incorporating internal customer feedback, with a second long term cycle of engineering, the response from peers and management borders on disdain or contempt. I am a team lead and get this response from all angles.
I’m no tech stick in the mud. Where scripting and RDBMS worked for 20 years, I incorporate “new things” where needed: Go for speed, Spark and S3 where vertical systems don’t scale; Rust when performance of a non-GC language is needed.
Conflict occurs when I resist over engineering: _Everything_ in a container; Kubernetes by default, as in 10 node clusters (am aware of its utility in much larger deployments); Clever code that will be extra work for future contributors to grok. Anywhere resume driven development appears to be creeping in.
I believe one of the responsibilities of management (and team leads) is to reign in architecture astronauts, but I rarely see it and am discouraged from doing so, in some cases due to fear of upsetting the “10X engineers” [1].
I have seen this across 4 companies in 15 years, with increasing severity. Is “build to minimum requirements” no longer appropriate? Have I selected roles poorly, and my experience is abnormal? Do people still just get stuff done both in the short and long term [2]?
Or is it time to hang up my spurs and take up golf?
The trends I blame are 1) computing power has become so crazy cheap these days that nobody cares about overengineering or even doing engineering at all, 2) lower quality of software developers; back in the day, it took deep interest (since software wasn't as lucrative a job) and considerable skill (since computers were very limited) to enter the software industry and succeed, and 3) fetishization of the latest software development fads. These trends are too large to successfully be bucked but, hey, there are worse places to be than being paid well to watch other people flush their own money down the drain.
[2] “Get stuff done” != “Break shit and move fast”. That is an entirely different problem. I’m not referring to disrupting industries or putting people in space. I’m referring to typical, somewhat mundane business technology.
If so, a vacation/sabbatical could be needed if it's a temporary thing. If it's permanent, finding a promising startup with a defensible business model to be a first-round employee might be a better option. They skew towards hiring A-players (not always, but usually).
If staying for some time: Popularity != engineering soundness. Fools and novices are allergic to simple, especially if they've never built solid anything at scale or worry about work being taken from them. It doesn't sound a collaborative/consensus environment either, maybe a toxic, religious, adversarial one containing outsized egos who want their solutions advanced because it's job security for them, and anything else gets in their way. You could try asking them what are their specific objection(s) to seek their honest feedback. Using self-deprecation can be helpful too.
Personally, I don't use Go anymore for the past 2-3 years. I prefer Rust for speed, Haskell for generality and Crystal for rapid prototyping. I'll use anything to get a job done, because real customer problems and real solutions are rarely perfectly-crated masterpieces in your favorite tech stack.
IMHO, Go got too popular, fashionable and full of needy noobs who dragged the ecosystem down. (Ironically, I remember telling a head-hunter in about 2011 he was dead wrong and to never call again since he arrogantly proclaimed Go was going "nowhere.") I hate K8s and systemd because they're overkill, "emperor's new clothes" amoeba-ware that are poorly-conceived, poorly-executed and of marginal benefit compared to what they replaced. It's important that "new" projects crammed down our throats because of celebrity and techno-fashionabilism not be easily compared to today's latest flavor Javascript library. Only after exhausting attempts to fix deficiencies in existing solutions, then deeply consider/seek feedback about the impacts, UX, behavior and interop of proposal through project-based RFCs.
That's my 2c from ~25 years being a code monkey punching buttons on glowing boxes; and maybe I'll accidentally write Shakespeare one of these days. ;-)