Refactoring 'Shoulds' into 'Preferences' for Tech Success

In today’s software-driven world, tech professionals often set impossibly high standards for themselves and their teams. Whether it’s handling a global outage, leading a team through a challenging product launch, or working with stressful stakeholder expectations, rigid thinking patterns can amplify stress, diminishing both performance and well-being.

I want to introduce a simple but powerful cognitive technique: transforming your ‘demands’ into preferences. This small shift can make a big difference to how you approach challenges in your tech career.

The Problematic ‘Bug’ in Demands

As tech professionals, we often find ourselves at our desks thinking in absolutes:

• “I have to solve this problem today.”
• “I should have spotted that vulnerability earlier.”
• “My team has to meet every deadline without exception.”
• “My code needs to be as efficient as more experienced developers’.”

Sound familiar? These absolute demands aren’t just making you feel rotten – they’re actually getting in the way of your best work. It’s like trying to debug an issue with a massive memory leak in your own mental processes.

A Simple Shift: Keep your Preferences, Drop your Demands

The core of this approach is simple: transform rigid demands into flexible preferences while acknowledging reality. Here’s the formula:

1. Spot the demand: Listen for those “musts,” “shoulds,” and “have to’s”
2. Swap it for a preference: “I’d really like…” or “I’d prefer…”
3. Add the flexibility part: “…but I don’t absolutely have to have this.”
4. Acknowledge reality: “…and I can accept that things aren’t the way I want right now.”

Common Examples I’ve Seen with Tech Teams

For DevOps Engineers:

Demand: “I must prevent any and all system downtime.”
Preference: “I’d obviously prefer to maintain perfect uptime, but that’s not always realistic, and I can accept that downtime is something every tech professional deals with regardless of their skill level.”

For Scrum Masters:

Demand: “My team should ship every feature we commit to.”
Preference: “I’d really like my team to meet our sprint goals, but we don’t absolutely have to tick every box, and while I don’t like it, I know it happens at times.”

For UX Designers:

Demand: “Everyone in the team must support our design approach.”
Preference: “I want everyone in the team to value our design approach, but they don’t have to value it the same way I do, and I can accept that sometimes they won’t.”

For Tech Leads/Engineering Managers:

Demand: “I should know how to solve every technical problem my team encounters.”
Preference: “I’d really like to have answers for all technical problems my team faces, but I don’t absolutely have to know everything. I can accept that admitting knowledge gaps and learning alongside my team is part of being authentic.”

For Frontend Developers:

Demand: “Users should never encounter any UI glitches in different browsers.”
Preference: “I’d rather users have a consistent experience across all browsers, but given the complexity of browser compatibility, some minor inconsistencies might crop up, and that’s something we can address iteratively.”

The Technical Advantage of Flexible Thinking

Interestingly, this mental framework mirrors principles we already value in software development:

• Agile methodology encourages adapting to changing requirements rather than rigidly sticking to initial plans
• Defensive programming anticipates potential issues—it’s essentially error-proofing for your brain
• Iterative development acknowledges that perfection rarely happens in the first version
• Robust error handling allows systems to acknowledge problems without complete failure

These approaches work in code because they reflect reality: conditions change, unexpected inputs occur, and perfect execution is rarely possible in complex systems—whether digital or mental.

Here’s how this approach helps tech professionals:

• Managing tough times: Helps you handle production issues without catastrophising
• Overcoming perfectionism: Allows you to ship code that’s good enough rather than waiting for perfection
• Breaking rigid expectations: Reframes your “all-or-nothing” thinking about technical solutions
• Defeating impostor syndrome: Conquers the “I’m not technical enough” monster
• Building better team dynamics: Uses flexible thinking to improve communication and navigate challenging work relationships

Implementation Tips

To practice this framework in your tech role:

1. Identify your common demands. What “must” or “should” statements frequently appear in your thinking?
2. Create preference alternatives. Rewrite these statements using the framework above; keep your wants, drop your demands!
3. Deploy in real-time. When you notice demand-based thinking during a stressful situation, pause and mentally shift to your preference.
4. Compare your results. Keep track of how this shift affects your problem-solving and stress levels.

Paying It Forward

The tech industry’s fast pace and high standards won’t change, but how we mentally process these challenges can. By transforming rigid demands into flexible preferences, we maintain our high standards and ambitions while creating the psychological flexibility needed to thrive in complex technical environments.

This isn’t about lowering your standards or becoming complacent. Quite the opposite – it’s about creating the mental space to do your best work without the counterproductive weight of perfectionism or rigidity.

What demands might you transform into preferences today?