I’ve gathered some thoughts. Engineering requires precision because the results must be flawless, and the industry operates on the principle that any issues are resolved as they arise, making communication a secondary concern. Additionally, weekly iterations often lead to minor setbacks that you need to accept and adapt to without getting frustrated about making changes.
Engineers are trained to get it right.
But here’s the paradox: this mindset of precision—essential for deliverables—has repercussions for how we develop solutions.
I watch the pattern unfold constantly. Someone presents a problem. We listen. Then everyone disappears to work alone, afraid to share half-formed thinking.
The irony? By refusing to iterate internally—by not sharing incomplete work, not prototyping quickly, not collaborating early—we deliver exactly what we feared: solutions that are overthought, overcomplicated, and sometimes don’t fully address the problem because we never reduced complexity or tested assumptions with others.
We spent all the time perfecting an answer in isolation instead of discovering the right question together.
There’s a massive difference between iteration and delivery, and confusing the two kills both speed and quality.
Adrienne Tan writes about this in her article on Perfect vs Possible. She says perfectionism is counterintuitive to good product management—and I’d argue the same dynamic is crippling engineering consulting.
Our industry won’t accept buggy solutions. Nor should it. But we’ve confused that external standard with how we should work internally.
Here’s the mindset shift:
Separate internal collaboration from external delivery.
Internally: prototype rapidly, share incomplete thinking, ask stupid questions, challenge assumptions, iterate messily. This is where you discover what you’re actually solving.
Between these stages is where education happens. This is where we teach engineers that new tools and solutions aren’t threats—they’re opportunities to evolve faster. That weekly iterations will bring changes, and that’s exactly the point.
Yes, feedback means revisions. But these small course corrections prevent the catastrophic failures that come from pursuing perfection in isolation.
Externally: be rigorous, check everything, review with fresh eyes, deliver with confidence. This is where precision matters.
Don’t fall in love with your solution before you’ve tested it with your team.
The moment you disappear to perfect your approach alone, you’ve limited what’s possible. Your solution cannot become its best version without input from others.
Treat internal communication as discovery, not judgment.
When you share work-in-progress, you’re not asking for approval. You’re extracting information, testing assumptions, finding gaps you couldn’t see alone.
This is as much a teaching challenge as a process one. Engineers need permission to distinguish between internal collaboration and external delivery.
Tan shares a reflection from Simonetta Batteiger: “One of the main pillars of resilience is optimism—not blind positivity, but the ability to be realistic about where you are, to accept it, and then to create from there.”
That’s the shift. Grounded optimism.
Be realistic about where you are in the process. If you’re still figuring out the problem, share incomplete thinking. If you’re ready to deliver, then review everything and get it right.
The industry will never accept half-finished solutions. So stop delivering them by spending all your time polishing in isolation instead of discovering the right problem through collaboration.
Be rigorous where it counts. Iterate everywhere else.