That's exactly the kinds of things I wish that I could do. In my experience it's mostly managers that want you to push features without any documentation and filled with bugs.
One thing that can really help in organizations that lack discipline is to define a detailed, rigorous definition of done and institute strict work-in-progress limits for each agile team. That way the team will be less likely to underestimate in the first place and everyone understands that time must be allowed for testing and documentation.
I'm fine with engineers fleshing out the technical specs(who else is gonna do it anyway?), but requirements come by engaging with the stakeholders, as you said, most notably your client(s).
And this is not a job for your engineers.
No matter where I've worked, most product is basically no one knows what they want until its built and sitting in front of them.
It's silly and counterproductive for engineers to expect managers to be all-knowing seers, and then act disappointed and put upon when those managers inevitably make mistakes. They're human too. Find a way to work with them productively.
Obviously an engineer is involved in the shaping of the requirements by interacting with the product manager or whoever(never the client). By asking questions, making inquiries and sometimes even poke holes into user stories that ultimately don't make much sense.
No one is all-knowing, no requirements are perfect, etc etc.
What I'm saying is that it's the job of the (Product) manager to understand what the client wants and to relay this into more tangible terms to the engineers.
As for knowing the business domain. Meh, sometimes maybe, but I can think of myriad of situations that it doesn't matter and it may not even make sense.
If you have dozens of engineers and you expect all(or most) of them to be familiar with the business domain, I'd suspect there would be some serious management/organizational problems in that company.
Often however, the manager takes a bit too much "artistic liberty" in relying what I said to the client, usually announcing features as done when that's not remotely the case or worse still, selling features as done which I don't even know about yet.
I've also learnt that when a client asks "How long?", the manager seems eager to give an eagerly short date, usually around two weeks, for even complex feature, before consulting the engineers and has the whole "I know what I am talking about here.", attitude.
Probably slightly too B&W for the shades of grey of HN.
Practically speaking, engineers wearing both product & engineering hats are effective and sometimes crucial part of the process. Obviously more so in LEANer teams. And less so long-running enterprise projects.
Right now we have a designer making mock up pages for me and we have a deadline. He is adding a fair bit of stuff that will need to be done with a mix of back end code and JavaScript. If we do things slightly differently I can code most of it in Django. If we do it exactly as he has done, i will need slightly less Django code, but the same amount of code again in JavaScript. Plus I find it better to have as much logic in the back end, rather than jumping between JavaScript and Python to work out where bugs are.
The designers must always collaborate with the engineers, if that's not happening it's bad project management :(
I also approve your tech/engineering choices :D
My first real junior dev job [1] gave me an ulcer. I only relaxed when I realised what you allude to: people yelled at me and complained about my working pace (and the fact I didn't... smile) but there wasn't anyone else willing to do the job I was paid a pittance to do, especially not with that money. I could just take my time and do my best in the time I thought was appropriate and let middle management go screw themselves. Poor bastards anyway- they were the de facto product testers so they probably had it worse than me in the end.
[1] In other words, working for a company that didn't give a shit about me and just used me in a "human-wave" sort of approach to development. This also came after a stint at a company that treated me fairly and gave me a full "software engineer" title, no "junior"s, so I had the chance to observe the difference between the two models very closely.
I get tasked with delivering arbitrary deadlines for impossible features and timelines to my team and managing the outcomes.
There really are no other reasons for some of these deadlines other than higher mgmt. competing against each other. There are no business reasons.
Long ago I just started ignoring them and giving my team deadlines that were both reasonable and obtainable. I don't want anybody stressed on a daily basis.
If mgmt thinks they can do better, go for it.
When the whole dev team is in on it it's actually not too hard to bake in extra time for the unseen things by just everyone taking longer than they would if they were doing purely what the managers wanted. (Though ideally by doing some of the unseen things the total time for future work will become less than it would have because you don't drown yourself in tech debt by trying to do the PM's MVP only every time... It's nice to have a PM who understands that tradeoff.)
I've become especially cynical of highly marketed "shiny" third-party things that are actually completely broken when it comes to technical innards:
MongoDB, Segment analytics, Unity3D game engine, to name a few...
Ahhh yes. Fancy website? Grandiose claims? Piece of crap.
Essentially plain text site? "just a tool"? Couldn't live without it
Aye, and that person would be called a "junior developer".
I usually like researching and fixing bugs, especially when they are mine. But compare business value between bugs versus new features and guess which one wins the most.
Problem is the boss wants a unique interlocutor, and one who says yes. Then if he is friendly enough, engineers will prefer to do a shitty job (rush "features" and even more bugs) rather than inconvenience their manager who already committed on behalf of the whole team.
Feedback about technical feasibility, time to implement et cetera really needs to go directly to the group demanding the feature, and their responses need to come directly back to the group implementing it. A competent middle man can help those two groups interact, but generally adding an extra middle layer reduces everybody's ability to function well.
Good management means the team can keep working fast. Bad management means that three-to-five years later, someone has to come in and really put their foot down and say "if you want simple features to stop taking six months we have to take the time now." But to be able to sell that message outside the tech team at that point, you sorta have to be an external "fixer" - IME, it's hard to sell your own ability to clean up the mess if you're seen as part of who created it, sadly.
Figuring out the difference between a place with good management and bad management if you're interviewing there can be tricky - but if they don't have tests, etc, and also can't tell you their plan to add them / why they're adding them now, that's probably a bad sign. Or ask them what they've shipped recently and how long it took - maybe easier to look for the symptoms than for specific process failings, since those could be wildly varied.
EDIT: I love working in flat structures where the total relevant number of people to what I'm working on is under 15. Either a small startup or a truly independent sub-unit. But there are few worse environments than a flat structure where 30+ people feel like they should have a say in a given feature.
It's been my experience, however, that when left to their own devices, developers tend to either learn new things or refactor code that's getting too hard to maintain. And both are important, critical even, but certainly no help in getting up to date documentation, fixing "painful" bugs, or writing good tests. In fact, they can even be counter-productive in that respect: heavily refactored code will invalidate at least part of its documentation and tests.
I worked outside of the Bay Area before coming here. I can tell you that the Bay Area tech has the worse managers. They drink the Kool-Aid way to hard out here.