The parable
Two men go to the river to fish. As they cast their lines, they see a baby struggling to stay afloat as it comes downriver toward them them. One man jumps in without hesitation to rescue the screaming child.
As soon as he makes it back to shore, they hear another desperate cry. The other man jumps in and saves this helpless child, but before he can make it back, another baby floats into view.
This continues for many long minutes. The two men rescue dozens of children, but they just keep coming—now faster than they can save them. Exhausted, one man takes a deep breath and walks away.
“Where are you going‽ We need to save them!” his companion calls after him.
“I’m going upstream to stop whoever’s throwing babies into the river,” he calls back.
Applying it to software engineering
Solve the things that are causing you the problem in the first place.
Do you spend a lot of time asking ticket authors for more clarity before you can work on a ticket? Make a template. Refine your backlog.
Do you spend a lot of time answering the same questions? Write a document and make it discoverable. (Bonus: I really like Diataxis as a mental framework for technical docs.)
Does your backlog grow faster than you can tackle it? Set up a system to remove stale tickets that linger for more than X days. Maybe your team has too many responsibilities and some of those need to be moved to another team (perhaps even creating an entirely new one). Or maybe your team is understaffed.
Going upstream is perhaps the most important thing you can do to create a sustainable workload, but like in the parable, there may be some things that are dropped while you’re solving the root cause. Ideally, you can get some temporary resources while you focus on this, but it’s important to remember that even if you can’t, solving the root problem is more important in the long run.