I am going to say something controversial: the engineering leaders I most enjoy working with are often the ones least focused on technical perfection. Let me explain.
Two Types of Leaders
Type A (Technically Obsessed): debates everything through technical excellence, slow code reviews, focuses on scalability we do not need yet, references how Google does things.
Type B (Outcome Focused): frames decisions through business impact, focuses on customer issues, builds for 12-18 months not 10 years, ships and iterates.
Guess which type delivers more value?
Example: Feature Flags
CTO from Google insisted on building distributed system for 15-person team. Took 6 weeks. Competitors shipped features while we built infrastructure.
Pragmatic director asked: what minimum do we need? Used LaunchDarkly in 2 days. Ran 12 experiments. Three became major revenue drivers.
The Pattern
Hyper-technical leaders use perfectionism to avoid uncertainty. Building the right architecture feels safe. Shipping imperfect and learning feels risky. But being wrong quickly beats being theoretically right slowly.
When to Slow Down
Security, data integrity, compliance, irreversible decisions - absolutely slow down. But that is 10-20% of decisions. The other 80% are reversible choices where speed matters more.
The Question
When should engineering leaders overrule for technical reasons? What is the framework?
Best leaders: understand which decisions are strategic vs tactical, move fast on tactical, slow down on strategic, articulate in business terms.
Thoughts? Where is the line between pragmatism and corner-cutting?