The Instrumentation Problem
We have engineered a culture where the world’s most capable problem-solvers are systematically deskilled. This isn’t happening through malice—it’s happening through optimization gone wrong.
“Are we building a generation of engineers who can only execute specified tasks, or problem-solvers who can architect complete solutions?”
The Factory Mentality
When you examine modern software engineering practices, you see a conveyor belt approach that would make Henry Ford proud, but would horrify anyone who understands that technology’s greatest value comes from solving problems engineers themselves identify.
The symptoms are everywhere:
- Product managers feeding requirements like they’re operating a lathe
- Daily standups reporting progress on pre-defined tasks
- Quarterly OKRs set by management with no user interaction
- Sprint planning ceremonies that optimize for predictability over discovery
The Challenge Imperative
The antidote is simple: begin the work before you understand it completely. Not recklessly—generously.
This isn’t about rebellion. It’s about understanding that:
- The best requirements come from sitting with users, not reviewing specifications
- Technical decisions compound over time, making early discovery mission-critical
- The engineer’s role expands, not narrows, as systems complexity grows
Implementation Path
Week 1: Pick three users you’ve never met. Sit with them for an hour each. Just watch and ask questions.
Week 2: Build a minimal solution to the most painful problem you discover. Ship it directly to them.
Week 3: Refine based 100% on their feedback. No manager input. No stakeholder review.
The result isn’t just better code—it’s engineers who understand why their code matters.
Because the next generation of problems won’t be solved by executing requirements better. It will be solved by engineers who can identify problems worth solving in the first place.