Standing before my team years ago, I found myself in an impossible position. I’d spent a year mastering microservices, the bleeding edge of software architecture at the time. Now, with a new client project on the horizon, I’d convinced leadership to let us use these cutting-edge techniques. What I hadn’t anticipated was the cognitive whiplash that would follow.

There I was, simultaneously the expert who’d sold this approach and the beginner who was discovering new complexities daily. Teaching my peers concepts that had taken me months to grasp, I watched their confusion mirror my own from just months earlier. Every morning, I’d wake up wondering if we should revert to the comfortable, proven methods everyone already understood.

This is the software engineer’s paradox in its purest form. After three decades in this industry, I’ve learned that it never really goes away.

The Learning Paradox: A Daily Contradiction

Ask any engaged software engineer if they’ll be better at their craft in three months, and you’ll get an enthusiastic “absolutely!” Press further. What about six months? Nine months? A year? The answer remains consistent: continuous improvement is not just expected, it’s demanded. The very idea of stagnation sends shivers down our collective spines.

According to research, developers with a growth mindset are 47% more likely to innovate and devise creative solutions compared to those with a fixed mindset. Yet this same growth mindset creates a peculiar blind spot when it comes to acknowledging the temporary nature of our “correct” solutions.

Think about that for a moment. How can we simultaneously believe that:

• Learning never stops
• The industry is constantly evolving
• Tools and practices are in perpetual flux

While also believing that:

• We currently possess enough knowledge to deem approaches definitively right or wrong
• Our current understanding represents some peak truth

Research indicates that systematic errors introduced by human cognitive biases are a significant source of challenges and failures in software projects. This cognitive dissonance isn’t just philosophical. It has a real impact on how we work.

The “Right Way” Trap: My Journey

In the early 2000s, working in large enterprise companies, I was the engineer who knew the “right way.” If management didn’t give me the time or latitude to implement things properly, I took personal offense. My father had instilled in me the importance of doing right by others, which translated into an almost religious dedication to technical correctness.

I’d complete projects to everyone’s satisfaction, but internally, I’d be running a constant monologue about being forced to do things “improperly.” The irony? My “right way” changed so rapidly that no two projects looked the same. The methods I’d defended as gospel one month would be outdated the next.

Cognitive dissonance theory explains that the discomfort we feel from holding contradictory beliefs can translate into positive outcomes when we learn to manage it effectively. However, first, we must acknowledge its existence.

The Agile Amplification: Hypocrisy in Action

The contradiction reaches peak absurdity when we layer in Agile methodologies. I’ve watched senior practitioners invoke Agile principles while simultaneously demanding:

• Large upfront design documents
• Ample planning time
• Buttoned-up requirements handed over pristine
• The latitude to implement their “right” technical design
• Frustration when priorities shift due to market changes

During my days of intense coding, I was a true believer in the #NoEstimates movement. I thought it was absurd to hold technologists to strict timelines. We needed space to get into flow and deliver value.

Now, after a decade of accountability for multi-year strategic planning, I find it equally absurd when engineers claim they can’t discuss scope and timeline in the same conversation. Imagine taking your car to a mechanic who says, “This could take 5 minutes and $10, or we might need to rebuild your entire car from scratch. We won’t know until we disassemble it. It’ll cost what it costs.”

We’d never accept this from any other profession. A potter knows how long it takes to throw a pot. A builder can estimate home construction. Yet in software, we hide behind the mystique of our work being “too novel” to estimate.

Research on optimizing agile methodologies reveals that traditional Agile methods often face scalability issues and struggle to adapt to rapid technological changes. Yet, we frequently treat them as gospel rather than guidelines.

The Emotional Toll: Leading Through Cognitive Dissonance

The real cost of this paradox isn’t technical. It’s human. As a leader, one of your most impactful roles is building effective teams. When you have talented individuals with disparate views on agility, correctness, and planning, it breeds friction that can tear teams apart.

I can now categorize my team members into distinct archetypes:

The Doers: They operate naturally in ambiguity, focusing on getting things done and improving iteratively. They embody the “1% better every day” mindset.

The Idealizers: Equally talented, but they invent such complexity and worry so much about not doing things “correctly” that they spend more time complaining than creating. They know how to work quickly and produce excellent results, but can’t help themselves from dragging others into conversations about how we’re not doing things “the right way.”

The most frustrating part? The Idealizers often struggle to articulate how to get from where they are to where they want to be. They can’t motivate others or sell their vision of “better,” yet they continue to complain about current practices.

Mindset theory suggests that a growth mindset serves as a protective factor against the development of learned helplessness. That’s a critical insight for technical leaders navigating this paradox.

The Path Forward: Embracing Productive Dissonance

After years of living with this paradox, here’s what I’ve learned about navigating it effectively:

1. Use Known Techniques with Modular Practices

My microservices experience taught me a valuable lesson: use proven techniques and technologies, but with good modular development practices that leave room for future learning and expansion. You can be confident in today’s decisions while building in flexibility for tomorrow’s insights.

2. Accept the Temporary Nature of “Correct”

Today’s best practice is tomorrow’s technical debt. And that’s okay. Research on adapting agile methodologies reveals that processes offer structural potential that is leveraged through social interaction, rather than presenting immutable rules. What matters is not the practice itself, but whether it serves your current context.

3. Focus on Continuous Improvement Over Perfection

The “1% better every day” mindset is far superior to demanding perfection as the next step. Most of the time, we can’t make gigantic leaps in habits and practices. Stop expecting it from others and yourself.

4. Recognize Different Working Styles

Some team members thrive in ambiguous situations; others require structure. Neither is wrong. The key is creating an environment where both can contribute effectively while minimizing friction.

5. Bridge the Gap Between Idealism and Pragmatism

If you can’t motivate those around you or sell your vision of “better,” you’re likely to find yourself pushed to the edges. Focus on actionable improvements rather than abstract ideals.

The Leadership Imperative

Research emphasizes that software engineers require problem-solving, critical thinking, and metacognitive skills in addition to their technical expertise, and must possess lifelong learning skills to adapt to the ever-changing nature of software evolution.

When we model cognitive flexibility, acknowledging our past limitations while confidently moving forward, we create environments where true innovation can flourish. We build teams that are both decisive and adaptable, confident and humble.

The best engineers I’ve worked with understand this paradox and navigate it gracefully. They’re confident enough to make decisions with incomplete information, humble enough to change course when needed, and wise enough to know the difference.

Conclusion: The Feature, Not the Bug

Continuous improvement inherently means you’re not doing things “the right way,” and you may never achieve it. However, you can achieve an acceptable level of progress today and improve further tomorrow. This isn’t a flaw in our thinking; it’s the engine that drives our industry forward.

“The more I learn, the more I realize how much I don’t know.” Einstein’s quote captures this paradox perfectly. In my journey from writing code at 15 to leading engineering organizations, I’ve learned that the only truly “correct” approach in software engineering is to remain perpetually open to being wrong.

The cognitive dissonance between our growth mindset and our desire for certainty isn’t comfortable, but comfort was never the point. If you’re not occasionally embarrassed by code you wrote six months ago, or positions you held last year, you’re not growing fast enough.

That’s not a bug in our thinking. It’s a feature. We just need to learn how to use it properly.

---

Watch my take on navigating the paradoxes of technical leadership on YouTube: The Software Engineer’s Paradox

#leadership #softwareengineering #growthmindset #technicalleadership #agiledevelopment #continuouslearning #engineeringculture #cognitivedissonance #softwaredevelopment