Surviving the Sinking Ship

There are failing projects… and then there are “brace for impact, grab your life jacket, the captain thinks the iceberg is a suggestion” projects.

You know the type.
Costs spiral. Deadlines multiply like rabbits. “Must-have features” get quietly pushed into a mythical “phase two” that never arrives. And yet, from the top deck, the message is always the same:

“Everything’s fine, full steam ahead!”

Meanwhile, you’re below deck, scooping out water with a teaspoon, wondering if your LinkedIn profile needs a refresh.

---

The Telltale Signs of a Doomed Project

How do you know the ship is sinking? Easy. Just look for these universal warning signs:

• PowerPoints get shinier as the project gets shakier.

• Leadership swaps out “working product” with phrases like “strategic alignment” and “future potential.”

• The project plan is now 400 slides long, and still no one knows what you’re actually building.

• Team morale is measured in how much sarcasm can be packed into the daily stand-up.

If you’ve ever thought, “Am I the only one who sees the flames pouring out of the engine room?” — congratulations, you’re on a doomed project.

---

Coping Strategies for the Doomed

So what do you do when you’re strapped to the deck of a slow-motion car crash?

1. Document Everything
   Not just emails. Etch it into stone tablets if you have to. You’ll want receipts when someone inevitably asks, “Why didn’t anyone warn us?”

2. Perfect Your Poker Face
   Practice nodding sagely in meetings while internally screaming. Bonus points for jotting nonsense in your notebook — no one will question “synergy roadmap,” but it makes a great doodle.

3. Redefine Your Goals
   Forget delivering the impossible. Instead, focus on achievable wins:

   • Did you stop yourself from flipping a table? ✅

   • Did you keep the junior developer from quitting today? ✅

   • Did you find a new meme for the team chat that perfectly sums up the chaos? ✅

4. Humour = Lifeboat
   If you can’t fix it, mock it. A well-timed joke in the trenches is worth more than a motivational speech from the captain.

---

The Emotional Rollercoaster

The hardest part isn’t the failure itself. It’s knowing it’s coming, waving your arms wildly, and watching the “powers that be” blissfully ignore every red flag.

It’s like being on the Hindenburg and whispering, “Is anyone else smelling smoke?”
while management beams and says, “Nonsense! This blimp is the future!”

---

Final Thought: Protect Thyself

When projects implode, leadership will be “shocked,” consultants will cash their cheques, and someone will quietly bury the lessons learned. But you? You’ll still have your sanity if you protect it.

Remember:

• You didn’t steer the ship.

• You didn’t order “full speed ahead.”

• And when it does go down in flames, at least you’ll have front-row seats to one of corporate life’s greatest comedies.

Because at the end of the day… sometimes the only motivation left is knowing you weren’t the one pressing the big red button.

Switching Off for Real: My Holiday Routine (Even When I’m at Home)

When I take time off work, I take it seriously. Whether I'm heading away or having a holiday at home, I disconnect completely—and unapologetically. Working in IT, the lines between “on” and “off” can easily blur, especially when you have access to everything from your phone or laptop. But over time, I’ve learned that proper rest requires firm boundaries. So I’ve built a routine that helps me truly switch off, and here’s how I do it.

1. My Out of Office Is Clear and Firm

I don’t send vague “I’ll get back to you when I return” messages. My out-of-office email reply makes it clear:
I am out of the office and cannot be reached.

I also provide the correct route for urgent support—usually pointing people to the help desk or main IT contact number. I do this for two reasons:

• I’m not being paid to monitor or respond to work while on holiday.

• There are capable teams in place to handle things without me.

Being clear sets expectations and removes the pressure to keep one foot in work mode.

2. I Turn Off Teams Notifications on My Phone

I don’t want work chats pinging me while I’m off, especially from apps that live on my personal phone. So I switch off Teams notifications entirely. If it’s urgent, people can go through the proper channels (which, spoiler: they rarely need to).

3. I Power Down My Work Laptop—and Hide It

When my holiday starts, I shut down my work laptop completely and physically put it away. Not just out of sight—but out of reach.
This sends a signal to myself: I am not working. I am not available. I’m off.

4. I Avoid My Home Office

During workdays, my home office is where I sit and focus. But during time off, I avoid that space completely. I’ve learned that just being in that chair or at that desk can trick my brain into “work mode.” So I reclaim the boundary by physically distancing myself.

If I do need to use a computer—maybe to watch something, browse, or sort personal files—I’ll grab my MacBook and head to another room. That machine has no connection to work, and using it elsewhere helps reinforce the feeling of being off-duty.

5. I Disconnect Because It’s Healthy—And It’s My Choice

I believe it's good practice to disconnect completely. Not half-on, not checking emails in the evening, not just “keeping an eye” on things. Fully off.

Because I’m not being paid to think about work while I’m on holiday. And frankly, thinking about it doesn’t help anyone—least of all me.

Being always-available is not a badge of honour; it’s a path to burnout. Stepping away lets me return clearer, calmer, and ready to contribute again. But more than that, taking time for myself is a boundary I’ve chosen—and I stand by it.

---

Final Thoughts

Whether you’re going abroad or taking a quiet break at home, you deserve time that is yours. The emails can wait. The messages can go to someone else. And the world won’t stop spinning if you don’t check in.

My routine may sound strict, but it gives me the space to recharge. And every time I stick to it, I’m reminded: rest isn’t something I need to earn—it’s something I’m entitled to.

Speed to Fix: The High Cost of Bug-Fix Bureaucracy

In software development, how quickly a bug is fixed can have as much impact as whether it gets fixed at all.

I’ve seen this firsthand: two starkly different approaches to bug fixing played out in parallel.

One was bloated, slow, and expensive. The other was fast, collaborative, and remarkably effective. Here's what I learned.

The Bureaucratic Bug Loop

Let’s start with the typical enterprise-style approach. It looks something like this:

1. A client-side tester finds a bug.
2. The bug is logged.
3. It gets reviewed in a triage meeting—attended by the supplier’s test team, scrum master, and often several developers and stakeholders.
4. There’s a discussion: Is it a bug or a change? Often, the answer depends on how much documentation exists—or how much the supplier team understands the client's expectations.
5. If accepted as a bug, it gets assigned to a developer, who may not fully understand the feature or business context.
6. A partial fix is made, passed to the supplier's testers.
7. The tester doesn't fully grasp the requirement, so the bug reoccurs.
8. It cycles back to the developer, gets reworked, and is returned again to testing.
9. Eventually, the supplier team decides it’s fixed and pushes it back to the client.
10. The client tests it and often fails it again.

Back to triage, more discussion, more meetings.And if it’s deemed a “change” instead of a bug? Add in project managers, business analysts, architects, and further rounds of planning, discussion, and documentation before a fix can even be scheduled.

This might be called “Agile.” But it’s a heavy, slow-moving, budget-draining machine.

The Collaborative Approach

Now contrast that with another way I’ve seen bugs resolved:

1. The client identifies a bug and logs it.
2. They speak directly to the developer, someone who understands the software inside out.
3. A fix is agreed upon and implemented quickly.
4. The client tests it and confirms it’s resolved.

That’s it. No committees. No triage queues. No endless email threads or JIRA reassignments. Just shared understanding, clear communication, and speed.

Speed

• Bureaucratic: Slow—can take weeks or more to resolve a single issue.

• Collaborative: Fast—can be fixed within hours when the right people talk directly.

Cost

• Bureaucratic: High—requires meetings, coordination, and time from multiple roles.

• Collaborative: Low—minimal overhead, fewer people involved.

Accuracy

• Bureaucratic: Lower—miscommunication and lack of context often lead to rework.

• Collaborative: Higher—client and developer clarify expectations directly.

Client Satisfaction

• Bureaucratic: Often, low delays and repeated bugs cause frustration.

• Collaborative: High, quick resolutions build trust and meet expectations.

Risk

• Bureaucratic: High delays and unclear ownership increase the risk of failure.

• Collaborative: Lower issues are caught and resolved early.

Control

• Bureaucratic: Diffused—decisions bounce between teams.

• Collaborative: Focused—clear, fast decision-making with those who understand the problem.

Why Does This Happen?

In large projects, teams are often bloated, fragmented, and overly process-driven. When suppliers don’t have domain expertise—or when developers are shielded from clients—bugs become political hot potatoes. The result? Delays, rising costs, and software that doesn’t meet real-world needs.

Sometimes, requirements weren’t fully captured in writing but were clearly understood by the client. When a tester or architect insists it's not a "bug" because it wasn't documented, progress stalls. The client ends up with software that technically meets the spec, but fails to meet expectations.

The Bottom Line

Agility isn’t about ceremonies and sprint planning—it’s about responsiveness.

On many large projects, a common trap is the relentless debate over whether an issue is a "bug" or a "change." Suppliers often lean on this distinction to shield themselves from additional work, but in doing so, they risk much more. When a supplier is contracted to deliver a working software solution, repeatedly rejecting implicit requirements can lead to delays, confusion, and ultimately a poor end product. These projects often expose a gap in domain knowledge on the supplier’s side, while the client holds the business expertise that truly matters. By failing to recognise this and instead hiding behind process, the supplier may appear uncooperative, erode trust, and harm their own reputation. In trying to protect themselves, they lose credibility when they could have simply collaborated more closely and delivered a better outcome for everyone involved.

When clients and developers work closely, solutions emerge faster, software aligns better with business goals, and costs stay down. When layers of roles dilute communication, bugs linger, frustration grows, and money leaks away.

If you're managing a project, ask yourself: How many people need to be involved before something gets fixed? If the answer is more than two, you may already be losing the speed-to-fix battle.

Is Multi-Factor Authentication (MFA) a Barrier to Access?

Multi-Factor Authentication (MFA) has become a standard security measure across many online services. From banking and e-commerce to social media and even public services, MFA is touted as the best way to protect user accounts from unauthorized access. 

But while it undoubtedly enhances security, does it also create unnecessary barriers for users? Is it always necessary, or are some services forcing it upon users purely for their own convenience, without considering the impact on accessibility and user experience?

When MFA Makes Sense

There are clear scenarios where MFA is beneficial, if not essential. Any service involving financial transactions, personal data, or sensitive information should implement some form of MFA. Online banking, payment processing, and cloud storage services are prime examples. In these cases, an extra layer of authentication—whether a text message, an authenticator app, or biometrics—protects users from fraud, identity theft, and account takeovers.

For these services, the inconvenience of MFA is outweighed by the need for security. A compromised banking account can lead to financial ruin, while an exposed cloud storage service could mean loss of private or business-critical data.

When MFA Becomes a Burden

However, there are many instances where MFA feels excessive or even user-hostile. Imagine signing up for a public forum, a government website to download a form, or a simple app where security isn't a primary concern. Yet, users are often forced to verify their email, receive a one-time passcode (OTP) on their phone, or even authenticate every time they log in. For some users, this creates friction that can turn them away from the service altogether.

Older adults and less tech-savvy users can struggle with MFA. They might not have a smartphone, may not know how to retrieve an OTP, or simply forget their authentication method. This frustration can push them towards alternative, often more expensive, in-person or phone-based support channels, defeating the purpose of a digital service.

Different Types of MFA & Their Challenges

MFA can take various forms, each with its own pros and cons:

• SMS-based OTPs – Convenient but vulnerable to SIM swapping and interception.

• Authenticator apps (Google Authenticator, Authy, Microsoft Authenticator) – More secure but require setup and reliance on a single device.

• Biometric authentication (Face ID, fingerprint scanners) – Secure and user-friendly but limited to modern devices.

• Hardware security keys (YubiKey, Titan Security Key) – Extremely secure but costly and impractical for average users.

For a tech-savvy individual, these options may not seem like a problem. But for someone who rarely uses technology, requiring MFA can feel like an impossible barrier.

Who Really Benefits?

While service providers claim that MFA is for the user's benefit, in many cases, it’s more about reducing their own liability and costs associated with fraud and account recovery. A locked-out user means fewer support calls for a compromised account, but it can also mean losing customers who simply give up on the service.

Companies should consider whether MFA is truly necessary for their service or if they are implementing it just to shift the burden onto users. If security is critical, they should at least offer user-friendly alternatives and ensure that their support systems are equipped to assist those who struggle with authentication.

The Balance Between Security and Accessibility

Security and convenience are often at odds. While MFA undeniably enhances protection, it should be implemented with the user in mind. If a service deals with money, sensitive personal information, or confidential business data, MFA is a must. However, for a simple public registration system with no real security risks, forcing users to go through extra steps every time they log in can feel unnecessary and exclusionary.

Instead of taking a one-size-fits-all approach, companies should:

• Allow users to opt into MFA where appropriate.

• Offer alternative verification methods tailored to different user needs.

• Provide clear, accessible guidance on using MFA effectively.

• Avoid making security measures so frustrating that they drive users away.

At the end of the day, security should not come at the expense of accessibility. Users are not the enemy—poorly implemented security measures are. If a service forces unnecessary barriers on users, it’s not protecting them—it’s just making their lives harder.