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 :)