Elliot Morris

I admit it! I maintain a shadow backlog. That is to say, I habitually spend time working on tasks that have not been prioritized by my team, but I have unilaterally decided are important enough to devote some fraction of my working week towards. I know, I should be ashamed. It’s a miracle I’ve not been chased out of the profession by now.

Luckily, I am in at a level of seniority where this is somewhat expected of me, even if that goes unstated for the most part. However, I have been doing this for the bulk of my career, and I’m here to tell you that you should too.

What I am not here to tell you is that you should prioritize your own gratification over the success of your team. Exploitative corporate structures aside, your team consists of your colleagues, and you owe it to them not to be a burden. (I know, this thinking can in its own way be another mechanism of control by the owning class, but not everything can be a class war my guy.)

I spend 10-20% of my time on my shadow backlog, and often drop it for months at a time when mainline work is more pressing. Sometimes companies formalize this as 10/20% time or Innovation Days. Whilst I appreciate the intent of these, I’m not a fan as it’s the flexibility that illegibility provides that makes shadow backlogs work for me, and frankly I don’t think employees need permission to be doing this.

That being said, take this all with a grain of salt. Shadow backlogs are not allowed. If you can’t do this without it adversely affecting the elements of your work that are actually important to your organization, you should not do it. However, if you find yourself just sitting there for extended periods of time, unable to muster any motivation, as I know a lot of us do, then keep reading.

Off the top of my head, here are some examples of things currently in my shadow backlog:

• Add mock injector functions such that particular service errors can be tested. There is some work coming up that will require this, and the mocking framework in our tests is haphazard and incomplete, I’d rather have the groundwork laid to avoid having to bundle the test complexity into the upcoming ticket, especially if more junior colleagues end up taking it.
• Finish up some gnarly work in our interop code generator around value types. The work this relates to got paused over the holidays, and having this done before we reboot will make the overall story simpler.
• Continue work on a side-bet of mine, involving an integration of our core framework into a DCC tool.
• Write a bunch of conceptual documentation for a client repository that I am the sole knowledge-holder for.

You know, before writing these out I expected that I would find I am disagreeing with many of the organizations prioritization decisions, but it’s not really that is it? It’s more that the cost/value calculation of just doing these, rather than communicating and planning and prioritizing, leans towards them being appropriate for shadow backlogging. I’m sure the specific texture of everyone’s shadow backlog will be different, but what I am sure will remain constant is that you, like me, will have more context than anyone else in these particular domains.

In particular, what I mean by that is :

• I have more context in technical minutia around areas of which I am familiar.
• I have more context over my own motivations and capabilities at any given moment.

The second one is the really important one.

Perhaps you’re a machine and can take any task given to you and churn through it. Fantastic, I’m proud of you, and you don’t need a shadow backlog for the same reasons I do. For the rest of us however, we are not machines, and are never going to be machines no matter what delivery framework we are placed inside.

A shadow backlog can serve as an escape hatch. There are times, rather frequent times for me, where I physically cannot motivate my hands and fingers to move such to progress a specific task. This sounds pathetic, perhaps I am broken. I don’t think so however, as I observe this behavior commonly in others, although people are ashamed to admit it. The arrogance of complaining that it’s hard to move your fingers to type code because it doesn’t currently speak to you? Bah! Don’t you know there are people in jobs who don’t have that luxury, who actually have to do labour? You pathetic, useless worm.

Maybe that’s true, but you know what, I don’t care. Shadow backlogs are a way of coping that works for me, and if you’re an employer who understands that humans are human, they work for you too. I don’t have to deal with the existential terror of finding myself physically unable to move forward on the one thing that is currently important, and the company gets a worker who is doing something rather than nothing.

The bonus win for everyone is that the things in shadow backlogs tend to be more valuable than the things that actually get prioritized for the reasons everyone knows but no one talks about.

As a closing thought, I’ll ask, are shadow backlogs an antipattern? I think probably yes. I have worked on teams where I didn’t need one. Communication was tight, values were aligned, the things we wanted to do and the things we needed to do were the same. However, we all know how rare and difficult this is, so I don’t begrudge this pattern as an effective coping mechanism.