After over 15 years in the software development industry, I’ve encountered a fascinating phenomenon that every seasoned professional will recognize: the world of contradictory expectations.
I call them “wicked challenges”, maybe because I’m a fan of liberating structure (go check this out).
These aren’t just occasional misunderstandings—they’re systematic paradoxes that define our industry’s status quo.
“Wicked challenges” resonate with me a lot because they’re not simple problems with straightforward solutions. They’re complex contradictions that require nuance, communication, and sometimes uncomfortable conversations to resolve.
The Expectation Paradoxes: When partners Want Mutually Exclusive Things
I have mapped some contradictions which we can explore in depth:
The Speed vs. Quality Paradox
“We need it fast, but perfect.”
Perhaps the most classic contradiction in software development.
The reality is that speed and perfection exist on opposite ends of a spectrum. Every engineer knows the project management triangle: good, fast, cheap—pick two.
When our partners request both speed and perfection, what they’re often really saying is:
“We need something good enough, quickly.”
The solution isn’t to promise the impossible but to have a conversation about minimum viable products (MVPs) and iterative improvement.
Unfortunately, every time this pops up, it becomes a high-stakes conversation with a lot of tunnel vision from every side.
How I love navigating this: Break the project into phases, with an initial delivery focused on core functionality built to high (but realistic) standards. Set expectations about what “done” means for each phase, and be transparent about the tradeoffs involved.
The Value vs. Cost Contradiction
“We want quality, but at low cost.”
Quality software requires experienced developers, thorough testing, proper architecture, and attention to detail—all of which cost money.
When partners push for both high quality and low cost, what I have found is that they’re most often unaware of the relationship between investment and outcome.
How I like to navigate this: Educate partners on the long-term costs of cutting corners. Show examples where initial savings led to expensive technical debt. Offer tiered options that clearly illustrate the quality differences at various price points.
The Control Paradox
“We want control, but hands-off management.”
Partners often want to dictate how software should be built while simultaneously not wanting to invest time in the management process.
This creates a vacuum where engineers lack both autonomy and direction.
I dislike this a lot. It’s wicked because non-tech people are starting to meddle in deep-tech domains.
AWS vs. GKE? Python vs. TypeScript? Claude vs. DeepSeek? The technical choices are hundreds and when partners become entrenched into those what I see is the following:
- Demotivated engineers because of a lack of autonomy
- Distrustful stakeholders because they don’t see any mastery
- Vague purpose & missed goals because of culturally demoting senior venture builders to “coding monkeys”
How I prefer to navigate this:
- Establish clear decision-making frameworks upfront.
- Define which decisions require partner input and which can be made autonomously by the development team.
- Create regular but efficient check-in points that respect everyone’s time while maintaining alignment.
The Innovation Without Risk Fallacy
“We want innovation, but no risks or experiments.”
Innovation, by definition, involves venturing into unknown territory.
Yet many partners expect breakthrough solutions without accepting the inherent uncertainty that comes with innovation.
How I navigate this (I admit that most of the time it’s complicated):
- Create small, contained experiments with clear success metrics.
- Start with low-risk areas to build trust.
- Document both successes and failures as learning opportunities, and gradually expand the scope of innovation as confidence grows.
The Agile Contradiction
“We want agile, but with fixed scope and timeline.”
This fundamental misunderstanding of agile principles creates enormous tension.
Agile methodologies embrace change and adaptation, which is inherently at odds with fixed constraints.
The agile manifesto came decades ago but most of the time people still do waterfall.
You have other observations? Join the conversation on LinkedIn.
How I sail through this: Educate partners on the true benefits of agile—responding to change, delivering continuous value, and reducing waste. If fixed constraints are non-negotiable, suggest a hybrid approach where some elements remain fixed while others allow for agile flexibility. It’s not the best solution as it feels like unproductive compromise 🤷
The Customization vs. Standardization Dilemma
“We want customization, but off-the-shelf pricing.”
Custom software requires custom development, which costs more than standardized solutions.
This disconnect between expectations and reality creates friction during both sales and delivery.
Of course we want lower cost, higher pricing and even bigger delivered value. And on the other hand our partners want lower prices and even bigger impact.
It’s a growing disconnect that doesn’t create a win-win scenario.
What I have found is that as long as “estimated price < delivered value” then things are OK.
How to navigate this: Clearly differentiate between configuration (adjusting existing systems) and customization (building new functionality). Price accordingly and be transparent about the cost implications of truly custom work.
The Trust But Verify Syndrome
“We trust you… but can you prove everything upfront?”
This wicked challenge reveals an underlying lack of trust masked by polite language.
True trust allows for reasonable autonomy and doesn’t require exhaustive upfront validation.
This is especially true in R&D where stress is increasing in correlation with time invested in research.
How can we flip the script:
- Build trust incrementally through small deliveries that demonstrate competence.
- Create transparency through regular demos and open communication.
- Acknowledge that some uncertainty is inevitable in software development and adopt “Thinking In Bets”
The Experience vs. Budget Disconnect
“We need expertise, but won’t pay for senior developers.”
Expertise comes at a premium in any industry.
When partners expect senior-level solutions at junior-level prices, they’re setting themselves up for disappointment.
How I try to move the needle: Explain the tangible benefits of experience—faster problem-solving, better architecture decisions, fewer mistakes. If partners still disagree: consider hybrid team structures where senior developers guide junior resources to balance cost and quality. It’s a tough battle to win.
The Innovation vs. Stability Tension
“We want cutting-edge technology, but also proven solutions.”
New technologies offer competitive advantages but come with implementation risks.
Proven solutions offer stability but may lack innovative features.
Partners often want both without recognizing the inherent tradeoff.
I personally prefer swinging: going to extremes to learn the boundaries.
This is why I suggest a core-and-edge approach, where proven technologies form the foundation while cutting-edge solutions are applied selectively in areas of maximum impact and acceptable risk. Sometimes I do Wardley Mapping
The Commitment Contradiction
“We want a long-term partnership, but with short-term contracts.”
Long-term partnerships enable deeper understanding, better alignment, and more strategic solutions.
Short-term contracts create uncertainty and incentivize quick wins over sustainable approaches.
I prefer doing one or the other, but not both, as it gives wicked signals.
How I’m trying to approach this: Offer incentives for longer commitments, such as priority scheduling or strategic planning sessions. Demonstrate the value of continuity through case studies of successful long-term partnerships.
The Scope Creep Classic
“Let’s keep it simple… but can you add these seven ‘small’ things?”
The accumulation of “small” additions eventually creates a large, complex project—often without corresponding adjustments to timeline or budget.
Succumbing to feature creep is really easy. Especially when partners want to drain out every possible technical improvement.
This moves the entire partnership into a feature factory, not a lean and agile product business.
How to navigate this: Implement a formal change management process that documents all additions, however small. Regularly review the accumulated impact of these changes on scope, timeline, and budget to maintain alignment. Talk about impact vs. delivery.
The Requirements Paradox
“We want detailed estimates, but won’t provide clear requirements.”
Accurate estimates require clear requirements. It’s that simple yet no one is going the extra mile to create top-notch specs.
Do you know why? Because it’s goddamn hard to do. Even I, for my own startups, I cannot write the perfect Product Requirement Document.
There are so many blackholes that it’s freaking impossible.
When partners expect precision without providing clarity, they’re asking engineers to predict the unpredictable.
Sometimes this is a tactic for leveraging contractors to overdeliver endlessly but the outcome is just “estimation inflation”. It becomes a wicked loop.
How can teams navigate this: Use ranged estimates with order of magnitude (this is a “couple of days work” vs “couple of weeks”) that reflect the level of requirement uncertainty. Communicate progress with a Hill Chart or Maze Chart.
The Decision-Making Delay
“We want to move fast… after one more round of internal alignment.”
Internal alignment processes often become the biggest bottleneck in software projects, creating stop-and-go dynamics that reduce overall efficiency.
We’ve been there: finishing a meeting with “next steps” which involves another meeting.
How many times have you experienced this? Join the conversation on LinkedIn.
I see people are resolving this by helping their partners streamline their decision-making processes.
Also in Camplight we introduce “consent” and “advice” process. This helps with identifying the minimum necessary approvals for different types of decisions, and creating escalation paths for when alignment stalls. Because nobody wants to be a bottleneck.
The Collaboration Contradiction
“We’re all about collaboration… but we’ll get back to you next month.”
True collaboration requires ongoing engagement from all parties.
When partners claim to value collaboration but are consistently unavailable, projects suffer from misalignment and delays.
I had projects that can took one week to deliver but are stretched to over 3 months.
With AI and vibe coding this will become even bigger pain in the eyes.
How to navigate this:
- Establish clear expectations about the time commitment required for successful collaboration.
- Schedule regular touchpoints in advance and make them brief but mandatory.
- Take full responsibility to be part of a great team and push away from mediocrity.
The Communication Paradox
“We want regular updates, but don’t have time to read/meet over them.”
Partners request communication but then don’t engage with it, creating a situation where important information goes unnoticed until it becomes a crisis.
This one I particularly dislike because it dismantles all benefits of async work.
My favorite resolutions:
- Create tiered communication protocols (quick daily in slack, good milestone overview in trello, great change log in PRs) with different levels of detail.
- Provide executive summaries for busy stakeholders (I love loom <3) while maintaining detailed documentation for reference.
Find the communication medium that works best for each partner. I still see there’s no silver bullet here.
The Cash Flow Contradiction
“We want you to deliver on time, but we’re going to pay invoices with delays.”
This one gets me on my nerves. Why would I push myself to the limit when the thing that’s important to me is delayed?
But it’s not about psychology and motivation.
On-time delivery requires proper resourcing, which depends on predictable cash flow.
Late payments create resource constraints that inevitably impact delivery timelines.
Navigating this is based on common agreements:
- Establish clear payment terms with incentives for on-time or up-front payment and consequences for delays.
- Consider milestone-based billing that aligns payment with delivery to create mutual accountability.
The Transparency One-Way Street
“We want full transparency, but don’t want to share our business context.”
Effective solutions require understanding the business problems they’re meant to solve.
When partners expect transparency from engineers without reciprocating, it creates an information asymmetry that compromises results.
Also it creates information silos that are very hard to break apart. This propagates in newcomers’ culture until everyone is a single bus factor and a knowledge hoarder. This leads to veeeeeeeery slow delivery and a tiresome status quo for high-achievers.
How to navigate this: Just. Write. Everything. In. A. Knowledge. Base.
This is it, I’ve said it.
This will easily demonstrate the concrete benefits of sharing business context through shareable comms where understanding leads to better solutions.
But if one has valid fears: create confidentiality agreements that address legitimate privacy concerns.
The bottom line is that in the era of AI/LLMs, no one will struggle because of too much information. Transparency wins over secrecy.
The Knowledge Transfer Imbalance
“We expect you to understand our business, but won’t invest time in knowledge transfer.”
Deep domain knowledge is essential for creating truly effective software solutions, yet many partners are unwilling to invest in transferring this knowledge to their development partners.
How can we mitigate this: Build structured knowledge transfer processes into project timelines and budgets. Create documentation templates that make knowledge sharing more efficient. Demonstrate how previous knowledge transfer investments have improved outcomes.
My path from contradiction to collaboration
These contradictions aren’t just amusing observations—they represent real challenges that can derail projects, damage relationships, and diminish outcomes.
Addressing them requires more than technical skill; it demands emotional intelligence, business acumen, and exceptional communication.
Prove me worng if you think otherwise; join the conversation on LinkedIn.
The most successful software partnerships occur when both sides acknowledge these inherent tensions and work together to find balanced solutions. This often means:
- Having honest conversations early about tradeoffs and constraints
- Educating stakeholders about software development realities without condescension
- Finding creative compromises that address underlying needs rather than surface demands
- Building trust incrementally through consistent delivery and transparent communication
- Establishing clear processes for handling changes, decisions, and expectations
The mindset: Turning Challenges into Opportunities
Interestingly, the teams and organizations that best navigate these contradictions often gain significant competitive advantages.
They develop reputations for reliability, transparency, and results that attract partners who value true partnership over impossible promises.
By acknowledging these paradoxes openly and addressing them proactively, we can transform these “wicked challenges” from sources of frustration into opportunities for differentiation and excellence.
What’s Your Experience?
Have you encountered these contradictions in your software development career?
How have you navigated them? Are there others you would add to this list?
I’d love to hear your stories and strategies in the comments. After all, sharing our collective wisdom is how we elevate our entire industry.
You can join the conversation on LinkedIn.
