Be a Duck (Sometimes)

There’s a common metaphor about ducks. On the surface, they glide across the water effortlessly—serene, calm, in control. But below the surface, they’re paddling like hell.

In engineering teams, we often talk about not wanting to be ducks. If your team is constantly scrambling beneath the surface just to appear composed, it’s a recipe for burnout. It’s unsustainable. You can’t always be a duck.

But sometimes… you should be a duck.

Sometimes, that’s exactly the right move.

You’ve made a timeline commitment. Product and Marketing have built a whole launch around it. Emails are written. Posts are scheduled. Everything is lined up.

But the week before launch, your team uncovers an issue making it nearly impossible to actually rollout. You have two options:

• Push the launch and insist on fixing it the “right” way, with fully automated, permanent changes.
• Do some manual, behind-the-scenes work to get through the launch cleanly—and buy yourself time to do it right later.

There’s no single right answer. But if you’re always defaulting to the first, you’re not thinking like a partner. And if you’re always defaulting to the second, your team is going to burn out.

Here’s another one:

You’re in the middle of an incident. Customers are missing data. You’ve found the root cause, but the proper fix will take days to get out. You can:

• Be transparent and let customers know data is missing, but a fix is coming—and that once it ships, everything will be backfilled and future occurrences will be prevented.
• Start manually backfilling the missing data while telling customers the issue is resolved (or at least they're no longer impacted), buying time to finish the real fix without further affecting customers.

Again, neither is always right. But if you only ever optimize for the elegance of the solution—if you can’t occasionally paddle hard beneath the surface so your customers don’t feel the churn—you’re missing an important part of what engineering leadership really is.

And here’s the upside: when a team has to scramble a bit to make things right—manually backfilling data, patching things at odd hours, staying up to support a fragile launch—they tend to internalize the lesson. It’s a lot like service ownership. Once you’ve been on the hook for the painful part, you’re far more likely to make sure that particular pain doesn’t repeat. The next time, it’s accounted for early.

There’s a famous (and true) joke that a software engineer will gladly spend two hours writing a script to avoid doing a 20-minute manual task. I’ve done it. Probably you have too. But there’s a difference between avoiding manual work out of principle… and doing it deliberately, tactically, because it’s the right call in the moment.

Being a duck is about keeping your commitments. It’s about choosing calm over chaos—for your customers, your stakeholders, and your reputation. It doesn’t mean you ignore the real fix. It means you prioritize it in a way that gives people around you confidence instead of churn.

You can’t always be a duck. But sometimes? You should be.