To me the biggest blocker is unclear requirements in the edge cases (this is maybe the final 10-20% of a project). You get to a point where it's unclear which of a few options to move forward with, in a way that will affect the UX of the feature, and this isn't mapped out in the story or the wireframes. So you have to go back to product and get direction, which often takes a lot of time (product loves to meet, to measure, to a/b test, in my experience they hate to just make a decision). In smaller orgs this is often easier, the engineer can just decide, and then make a note w/ product to follow up later with a final decision that we'll follow back with later, and only if it seems better than whatever decision was made. In a big org, process gets in the way here.
I've encountered this so many times in my career, having worked on a lot of UI that product and UX designers came up with.
At first I would spot potential missing pieces in the UI designs as they were proposed and would work with PM and design to come up with workarounds. I did also notice that PMs like to set up meetings to go over them, but often the specific details don't have a massive impact on the actual usability, but still a decision has to be made.
In the early stages, so much of the product design is hypothetical to everyone. Even though you could drill down on specific details, nobody really wants to, unless you're the engineer who has to implement it. This often means it's hard to communicate precisely the design issue you need to address (and often, it's "only" an issue because the implementation has to choose an option).
So, what I eventually would do over time was just work as far as I could until I had a concrete issue I could demo and explain easily to PM and design. Before I'd bring up the issue to them, however, I'd come up with a couple of best-effort solutions. (Not completed, although sometimes I could hack something together.) Usually I'd prefer one solution over the other. I'd present both options and give enough pros/cons to show why my preferred was better, but I wouldn't tell them necessarily that that was my preference, just the facts about what you get with it over the other.
More often than not, product and design would just go with my recommendation. It's true that they really don't care about a lot of nitty gritty details, and often they have bigger fish to fry, so it's a great way of making progress.
Obviously, there are some tricks to how you present the pros and cons to ensure you get your way, but obviously as a senior member of the team, you need to do what you think is best of the team and overall product.
Good point, but why can't you do the same thing in a big org? Of course there are different kinds of orgs, but in my experience doing what you described (just make a decision yourself and note it to stakeholders later) is always the most expedient. The only ways I've seen it go wrong is if that decision entails a lot of work (choose the simple thing) or you get overly committed to a direction and don't actually want to come back to iterate it.
The slowest-to-ship engineers are the ones who refuse to do a bit of design thinking or copywriting when they hit the inevitable unspecced case and instead think "not my job!". It really is your job to find all of those cases, but going a bit outside your domain to suggest the simplest solution (usually by coding it up) rather than spinning up the meeting merry-go-round is going to make you 2x more valuable than the engineer who just gets blocked.
And a lot of those orgs do 'spinning up the meeting merry-go-round' as a baseline.
I would love to find solutions, run them through other developers to make sure it won't be a disaster to maintain, and present them. But more often than not, anything beyond 5 minutes of investment isn't worth the personal time investment given the organization. There are just too many hurdles.
From my experience, most developers are still treated like idiot savant children capable of doing the one thing the 'helicopter parent' managers can't do.
Unclear specifications in the edge cases is the definition of requirements engineering and the reason why such an approach usually isn’t the best for any moderately complex application.
If the person who wrote the requirements could formulate them precisely, they might as well have done it themselves in code rather than as requirements.
As a coder you just have to get used to it. Your job is to fill in the blanks so the higher ups can focus on the big picture.
This is why iterative planning (agile) has become so popular. You implement the most important use cases first and from there go through the edge cases together.
