Why the tool never was the problem

For a while, we missed deadlines that shouldn't have been missed. Not because the work wasn't getting done, but because the ticket telling us it needed to get done was sitting in a system half the team wasn't looking at. Commercial ran on monday.com. Content ran on Jira. Their tickets came in, and with predictable regularity, they simply went unseen until it was already late.

So we moved. We switched content over to monday.com and synced our boards with commercial's, and just like that, the missed-deadline problem disappeared. Information flowed, priorities were clear, everyone who needed to see a ticket saw it.

Except, of course, that fixed exactly one relationship and quietly strained several others. Dev, SEO, design and management were all still on Jira, and had been all along. We'd solved visibility with commercial by giving up visibility with everyone else.

The tools, three attempts, no clean answer

Over time, our setup shifted more than once: Jira first (with a bit of Basecamp just for some flavour), then monday.com for commercial alignment, then back to Jira again, this time at management's request. In practice, both tools are genuinely good at what they do. What I learned, though, is that "good tool" and "right tool for this specific group of people" are not the same question.

Internally, for a content team specifically, monday.com was the better option, at least in my experience. It was visual, flexible, and easy for team leads to actually own their corner of it. Jira, on the other hand, was the stronger choice for cross-functional alignment; it was already the tool dev, SEO, and management were fluent in, so putting content there meant content was legible to the people outside content who needed to check on it.

To make it messier still, our own close working group, SEO, design, content, and web managers, didn't run sprints at all. We kept it simple: two boards, one for reviews, one for pages. Every ticket carried either a template or a full brief, plus SEO instructions, and moved through a consistent handoff: SEO first, then content, then design, then web managers. Dev only entered the picture if design flagged an actual site issue. Meanwhile, social media collaborated with us on monday.com, and the news team ran entirely on Basecamp, quietly sitting alongside the other two.

The tool isn't what makes something visible

Here's the actual lesson underneath all of that switching: no single tool is legible to everyone by default. Jira made sense to the dev, SEO, and management teams. monday.com made sense to commercial, social, and to my own team. Neither one, on its own, worked for the full group of stakeholders at once, and no amount of picking "the right platform" would ever change that, because the platform was never really the variable that mattered.

What actually created visibility was the structure underneath whichever tool we happened to be using: a consistent ticket format that didn't change depending on who created it, a clear staged handoff so everyone knew exactly where a piece of content was and whose desk it was on, and boards organized so team leads could genuinely own their piece of the process without losing sight of the bigger picture. That structure is the part that's actually translatable. The tool is just the window you happen to be looking through.

Where I got that right, and where I didn't

On monday.com, I set up separate boards for each of our mini teams, specifically so team leads could take real ownership of their own workload rather than everything routing through me. One general board handled the bulk of planning and connected directly to the commercial board; from there, tasks moved out to each team's individual board as they were assigned.

For my own team, that setup worked well. For management, SEO, and design, it didn't. Management in particular struggled to see clearly where anything actually was; the structure that gave my team leads ownership and clarity was, from the outside, a maze. I'd solved legibility for the people inside the system and, without quite meaning to, made it worse for those who needed to see it from the outside.

What I actually took from all the switching

If you'd asked me at any single point in that process which tool was right, I'd have given you a confident, tool-specific answer, and I'd have been wrong every time, because the tool was never really the thing that needed fixing.

What I took from the whole cycle, Jira to monday.com to Jira again, is that the real skill isn't choosing a platform. It's designing a system that's genuinely legible to every stakeholder who needs to read it, and accepting that "legible" means something different depending on who's looking. Get that right, and the tool you're using becomes almost beside the point.