Bungle in the Jungle

The purpose of making tickets is to get the PM to stop asking for tickets

I've been feeling a pull toward a new failure mode: an unspoken arrangement with another member of my team to pass minor tickets back and forth so that the PM will stop asking us to make tickets and epics and projects for every bit of work and tie everything to the roadmap. By doing this, we free up time to do "real work", which may or may not be nicely ticket-ified. This is essentially internal-adversary behavior: deploying chaff because I don't like air traffic control.

My initial thought is that this is bad - we SHOULD have an up to date board. But everybody is stretched too thin to coordinate making the board. And by the time I have a few hours, I have to decide whether to spend my time on 1) fixing our main package CI which has been broken for two weeks, 2) polishing grant applications to improve the odds we avoid a budget gap, or 3) putting a few hours into the "organizing the board" tank, which is likely a 40-ish hour high-context effort. It doesn't help that the beginning of that effort will be UNDOING our previous attempts to go super saiyan and just board-ify our roadmap in a few hours of dedicated lead time, which has left fragmentary epics and projects (does "fixing main package CI" fall under the "major stack maintenance", "maintenance 2026", or "misc stack maintenance" epic? Better pick right since we'll only be checking one of those during iteration planning!)

There are also several mechanical issues that impose themselves on our board workflow. There's a GitHub connection that auto-adds ALL issues and PRs from our repos to the board. This is good when a user writes in and we can't avoid seeing it - generally this leads to strong accountability and a dev is assigned to respond to users within 24 hours. But this is bad when it imports ~500 pre-existing issues and it's assumed that I will just "find some time" to sort them into (already incoherent, see above) epics. Also, with daylight savings, our EU/NA team members don't have overlap with our AUS team members, so identifying PRs as ready for review and assigning them to trans-pacific reviewers requires clever use of columns and ticket assignees. Unfortunately if I've done high-context work between the standups I've often forgotten important context (urgency/finality/alternatives) when I hand it off to the reviewer, which sometimes leads to wasted work and frustration.

I wonder what incentives would look like that would make our board relevant. The three key players are the PM, tech lead, and science lead:

So maybe the key thing is that, while the PM is ALREADY motivated to keep the board up to date, the TL and SL could be incentivized by stronger funder engagement. In other words, if the people that our team was accountable to were constantly pestering us with questions, the TL and SL would quickly become interested in the PM having a clear view of everything so they could intercept those requests.

But maybe this means the board isn't worth the cost? Like, it'd be weird to say "while we've told our funders to leave us to our work so we can release stuff faster, let's turn that all over and tell them to pester us constantly for the sake of the zenhub board". Our funders aren't stupid, they picked their tradeoff and expect us to deliver.

So the PR workflow and issue management workflow is quite valuable (especially for a distributed team), but maybe we should just agree that some things don't get tracked on the board. If nobody's asking, why kill ourselves to determine which of three indistinguishable epics "CI has been failing for two weeks" belongs under.

CI is failing, just put it in "urgent" and fix it.