In my experience, every time I get specifications from a product manager (PM) or mock ups from a designer, they are very vague and incomplete. When I'm told to implement things based on these specifications, I often find myself going back to them to get missing details and ask about use cases not covered. Sometimes, I'll have partway implemented something only for the specs to suddenly change after asking about a different part!
I'm aware many jobs list working with PMs and UI/UX designers as a requirement, but it has gone past an acceptable level for me - I do not want to use the word "incompetent" to describe how I view their work output, but that is how I've slowly grown to feel about it.
So a few questions:
1. Are poor specifications a common occurrence in the industry?
2. Is there a way to improve the initial and ongoing quality of specifications as a non-PM and non-designer?
3. Should software engineers have a say in the specs or should they defer to PMs and designers and stick to technical implementation?
4. What kinds of places will give software engineers control over these specifications?
5. Is there a role which combines pm/designer/engineer into one?
2) You can get a document and then write notes and send it back for amendments. If the people producing the requirements are useless, you will have a lot of revisions. This can be painful.
3) I think so, conceptually. Developers should be invited to review things to consider feasibility and also contribute ideas if they have any.
5) I would suggest being a senior developer at a startup might end up looking like that.
It's reasonable to expect tasks to be well defined and well scoped.
It's also true that the other roles that you are deriving your tasks from, are not ONLY scoping out tasks for you 100% of their time.
So collaborate, a ticket might have been written in haste, without all the information from a customer or stakeholder, and with the intention that it still needs to be fleshed out.
You should communicate what you need and work together.
You seem to want fully implementable tasks to be thrown over the wall to you to implement. Businesses will never build anything great working like that.
questions/answers:
1) (poor specs) yes but maybe not for bad reasons
2) (improve quality)communicate what works for you and find out what works for them, write a template.md file for what a good specification looks like and have them use that as a template.
3) (should engineers have a say?) Yes! This process should be a collaboration between the whole product team including you!
4) input is more appropriate than 'control'
5) Respectfully, I think you're underestimating the tasks of those other roles that you don't see. For any non-trivial product in a non-micro company with a tiny customer base this is not possible.
This way there’s zero back and forth.
2. Design reviews with the development team. You can also kick incomplete designs back to the designer. I often do, usually with suggestions.
3. Yes. Designers often put things in a design on a whim. Devs will work their butts off to implement it, when a small change might have made it simpler or more accessible or whatever. I've never had a designer push back with these kinds of suggestions
4. All of them, if you bother to speak up
5. Sounds like a nightmare.
Engineers who don't do that, a.k.a code monkeys, will be replaced by AI
For context: I've worked at a huge fortune 500 company with thousands of employees, a small startup with less than 20, and a mid size startup with around 150.
The big company hands down had the most thorough and professional PM and design process I've ever seen. Engineers were removed from the process. We (engineers) received fully specced out designs, with everything perfectly documented. Meetings to kick off projects were in depth and driven professionally by the PM. If questions arose, PM and Design hashed out answers and devs got a quick succinct response. There was never a meeting where a design was ambiguous or "hadn't thought of that yet". The PM and design team had spent weeks prior to coming to engineers, to think through everything and produce pages and pages of mockups.
Honestly, I loved it. As a developer I want to implement beautiful designs and not be burdened by "how should this flow work if X" or "what if Y happens" questions. I want to sit down, open my mocks, and start coding. If I ask questions, I want quick answers with designs.
At the smaller startups, this process was turned entirely on its head. Developers were a critical part of the product decision process, and often are asked to come up with designs on the fly due to missing, or incomplete flows. Whether employers realize it or not, this absolutely adds to the complexity of the job for the engineer. Now instead of facing the problem of how to implement something, I'm also faced with the problem of how it should look and sometimes even, how the entire user experience should feel.
TLDR: You'll wear many different hats at startups. If you don't want to wear those hats, I recommend looking for work at a large company and in the interview process, ask directed questions about the size and scope of their PRODUCT and DESIGN teams.
If their answer is "yea we have a guy" ... then you're going to be working with that "guy" to come up with product and design. If they say "we have a team of 20" then you are set.