What I've found is that while engineers will often focus on getting the implementation just right, they will just as often get stuck on murky architectural decisions. All things considered the decision is murky because the alternatives aren't clearly better, so the correct path is "pick one, try it, reflect later" rather than "debate hypotheticals until an impasse."
I've seen many engineers who are good at these murky architectural decisions, and I've also seen otherwise detail oriented engineers lock up a team on the debate around architectural decisions for so long you could have tried both ideas by then.
I've been working on a project involving some highly optimized C++ code, where the smallest architectural mistakes can cause serious slowdown. My architectural strategy thus far has been to 'just try' all of the decent options and then pick which one is the fastest. It's been working out well, but luckily my code is ~1K lines and the cost of doing this is minimal. (fun fact: template classes >> polymorphism in terms of speed, also, cache yo trig functions)
In contrast, I worked on a partial refactor of a fairly large (~150KLOC) code base, and the 'just try it' approach was definitely not an option due to the person-months work required to even make a small dent. That took quite a lot of thinking to figure out a reasonable path forward. And a lot of diagrams...