The pattern is familiar
Engineers appear busy. Commits pile up. Architecture diagrams multiply. But nothing ships. The codebase exists in what one developer calls a "quantum state": not broken, not finished, not committed, not deployed.
This isn't laziness. It's a specific kind of avoidance disguised as diligence.
The real costs
Context switching inflicts a 23-minute recovery penalty every time an engineer shifts focus, according to productivity research. That's manageable in theory. In practice, teams juggling multiple projects never reach deep work.
The pattern compounds in APAC's high-growth environments. Singapore fintechs and Indian tech firms under pressure to scale fast often see MVPs delayed by months while engineers refactor code that hasn't offended anyone yet.
AI coding assistants promised to help. Early data suggests they're making it worse. Senior engineers report feeling faster while actually completing tasks slower, acting as editors for AI-generated output rather than architects. One researcher calls it "code at the speed of vibes."
What's actually happening
Shipping means exposure. Exposure means feedback. Feedback means being wrong. So teams swap risk for busyness: endless refinement, future-proofing for scenarios that may never arrive, abstractions that solve theoretical problems.
The brain's doing its job. The work isn't.
What changes it
Strict time-boxing helps. So does limiting engineers to one or two projects maximum. Some teams enforce "shutdown rituals" to complete tasks rather than context-switch them into oblivion.
The harder fix is cultural. CTOs need to distinguish between technical debt that blocks progress and perfectionism that blocks shipping. One has measurable impact. The other is fear in a hoodie.
The trade-off isn't between quality and speed. It's between shipping something that can be improved and shipping nothing that can't.
The question that matters
Before the next refactor: if this worked exactly as it is right now, would you show it to users?
If yes, ship it. Bad decisions can be fixed. Unmade decisions just rot.
History suggests the teams that ship imperfect code learn faster than teams that perfect unshipped code. The data backs it. The results prove it. The question is whether engineering leadership will act on it.