There was a point in my career where I had a dozen open pull requests.
Not half-finished experiments.
Not “I’ll get back to this later” work.
Twelve branches.
Each one solved a real problem.
Each one was implemented, tested, and ready for the next step—code review, QA, or in some cases just validation.
They just… weren’t a priority.
One of them stands out.
It was one of those problems everyone agreed needed to be fixed.
The kind that shows up in conversations, gets a few nods, and then quietly gets pushed to “later” because it’s assumed to be expensive.
“Probably a week of work.”
“Maybe more.”
“Let’s not disrupt the sprint.”
One Friday afternoon, I had a few hours between tasks—too late to pick up anything substantial, too early to call it a day.
So I took a swing at it.
Four hours later, it was done. Tested. Ready for review.
Not a week. Not a sprint.
Four hours.
And then it joined the others.
Waiting.
So once a month, usually on the first, I’d go through and rebase them all.
Resolve conflicts.
Update dependencies.
Make sure nothing drifted too far from reality.
I started calling it:
Watering the bonsais.
What is a “bonsai branch”?
A bonsai branch is work that is:
- Fully (or nearly fully) implemented
- Solves a real, known problem
- But is blocked by prioritization, validation, or timing
It’s not dead code.
It’s not abandoned.
It’s maintained, deferred value.
The part most teams don’t see
From the outside, these branches look like:
“Engineering started something and didn’t finish.”
From the inside, it looks more like:
- The problem was identified
- The solution was designed
- The work was implemented and tested
- And then… it waited
Not because it wasn’t useful.
Because something else was more urgent.
The hidden cost
Bonsais aren’t free.
Every time you keep one alive, you’re paying for it:
- Rebase time
- Merge conflict resolution
- Context switching (“what did this fix again?”)
- Mental overhead of tracking what’s “almost done”
You’re maintaining a solution that isn’t delivering value yet.
And if you don’t maintain it?
It dies.
And when it dies, that work doesn’t just pause—it resets.
The hidden value
Here’s the part that matters:
A bonsai branch is already paid for.
The risk is mostly burned down.
The unknowns have been explored.
The implementation exists.
When you finally prioritize it, you’re not starting from zero.
You’re starting from:
almost done.
The tension
Good engineers tend to move faster than prioritization cycles.
They see a problem, they solve it, and they move on.
Organizations don’t always move that way.
They have:
- competing priorities
- validation cycles
- timing constraints
So you end up with this strange middle ground:
Work that is finished… but not allowed to be done.
For engineers
If you’ve got bonsais, be intentional about them.
- Keep them alive if they matter
- Document what they solve
- Don’t let them sprawl endlessly
And maybe most importantly:
Don’t confuse “not prioritized” with “not valuable.”
Those are not the same thing.
For product and business
You might be sitting on solutions you’ve already paid for.
Ask:
- What’s been built but not shipped?
- What’s been deferred but maintained?
- What could be delivered quickly because the work is already done?
Because sometimes the fastest way forward isn’t a new initiative.
It’s revisiting something that’s already been solved.
Closing
Some teams let these branches rot.
Others quietly maintain them—keeping them ready for the moment they’re needed.
Not everything grows in the open.
Some things are shaped, maintained, and patiently kept alive.
Waiting for the right time.
Sometimes the most valuable work in your system
is the work that’s just been… waiting.
