You probably have one already.

Not written down — but in your head.

As a senior engineer, you accumulate a quiet backlog of “this would be cool one day” ideas. A better internal tool. A tiny automation. A library you’d like to try. Something that would make your teammates’ lives just a bit easier.

The problem? That backlog usually dies with you.

This post is about writing it down — deliberately — and turning it into something your whole team can benefit from.

The Problem You’re Actually Solving

Let’s be clear: this isn’t about bored engineers or blocked time.

Most teams I’ve worked on are busy. Often too busy. That’s exactly why this stuff never happens.

The real issue is this:

Innovation, experimentation, and “nice-to-have” improvements don’t have a home.

They don’t belong in BAU backlogs. They don’t win prioritisation debates. And they definitely don’t survive roadmap planning.

So they live nowhere — except in senior engineers’ heads.

At some point, you realise that part of being senior is making more seniors. Sharing how you think. Sharing what you notice. Sharing what you’d try if you had the space.

That’s where a Learning Backlog comes in.

What I Mean By a “Learning Backlog”

At its simplest, it’s this:

A lightweight backlog (I deliberately don’t use the same complex system as I do for BAU)
Full of extremely low-priority tasks
That would be nice to get done one day
And are safe to ignore indefinitely

Think:

Improvements to internal tools or CLIs
Small automations
Coding templates, packages, internal libraries
Research spikes into new tech (AI, LLMs, Bun, Deno, etc.)

Nothing on this board is urgent. Nothing competes with squad work. Nothing is promised.

That’s the point.

What It Is Not (This Matters)

If you don’t draw these boundaries clearly, this will fail.

This backlog is not:

A dumping ground for tech debt
A shadow roadmap
An alternative to BAU work
A way to dodge engineering standards
A backdoor way to extract unpaid labour

If something needs to be done, it belongs elsewhere.

If this becomes required, it stops working.

When People Actually Work On This Stuff

In practice, I’ve seen Learning Backlog tasks picked up:

During onboarding (it’s an excellent first task)
By grads and interns — including a high-school work-experience student once
When someone is hard-blocked
In pairing sessions with a tech lead
At hackathons
Slowly, over time, with no pressure

Yes, sometimes people do this in their own time. No, it’s not encouraged. Yes, I’ve occasionally rewarded it with something symbolic (like a packet of Tim Tams).

The reward isn’t the biscuits. It’s learning something and shipping something useful.

Opinion: This Is Mostly About Innovation Culture

The tools are nice. The automations help. But the real win is cultural.

A Learning Backlog creates a visible, low-stakes place where curiosity turns into action.

It gives you:

A safe outlet for curiosity
A way to practise skills while helping your team
A chance to ship internally between external releases
Small wins that build confidence
Shared ownership of “making things better”

It’s a win for the individual, the team, and the company — without pretending it’s mandatory.

“Isn’t This Just a Permanent Hackathon?”

Yes. Pretty much.

And that’s fine.

The difference is scale and pressure:

Tasks are smaller
Many suit individuals, not teams
There’s no deadline
No demo day
No expectation of success

Hackathons are sprints. A Learning Backlog is a walking track you can step onto and off whenever you like.

The Manager’s Role (And The Line Not To Cross)

This only works if managers and tech leads are involved — carefully.

Good involvement looks like:

Actively encouraging it
Gatekeeping what goes on the board
Pairing occasionally
Modelling curiosity themselves

Bad involvement looks like:

Tracking participation
Turning it into performance criteria
Mining it for roadmap commitments
“Strongly suggesting” people use their own time

Once it smells like obligation, people disengage.

Pitfalls And When Not To Use This

This won’t survive:

Low psychological safety
Poor engineering hygiene
A culture that already abuses “optional” work
Teams that can’t say no

In dysfunctional orgs, this will turn into a tech-debt dumping ground. If that’s you, fix that first.

Naming Notes (If “Learning Backlog” Doesn’t Land)

Names matter — but not that much. Low stakes is the feature.

If “Learning Backlog” doesn’t fit your culture, similar options that keep the intent intact:

Engineering Playground
Side-Quest Board
Experiment Queue
Tinker List

Avoid names that sound heroic or productivity-coded. If the name sounds important, people will treat it like real work.

Final Thoughts

If you’re a senior engineer with a mental list of ideas, you’re already halfway there.

Write them down. Make them visible. Make them optional. Protect them fiercely from becoming “real work”.

If nothing ever ships, that’s fine. If someone learns something and helps a teammate, that’s a win.

That’s what a Learning Backlog is for. Good luck.

A Note For Commenters

This describes something that’s worked for me in a few different teams and contexts so far — it’s not a universal rule.

If you think this is a bad idea, or you’ve seen it fail in practice, I’d genuinely like to understand why. I’m particularly interested in the environments or constraints where this would backfire.

Good faith disagreement welcome :)