I'm the architect who also builds. When a client tells me "we need feature X", I ask first: Does X actually solve the problem? Only when the requirements are right do I write the first line of code.
On one project, the team gave me a nickname: Worry Eater. Because I grab the problems nobody wants — performance bugs, legacy code, edge cases in production. Not out of masochism, but because that's where the biggest leverage is.
The result: Queries from minutes down to under a second. Not by throwing more hardware at it — by understanding what the database actually does.