DEV Community: Ali Raza

Why We Switched From Jira to ClickUp (And What Actually Changed)

Ali Raza — Sat, 18 Apr 2026 18:41:20 +0000

There was no single disaster that made us switch.

No catastrophic lost sprint, no dramatic moment where Jira failed us in front of the founder. It was slower than that, a quiet accumulation of small frustrations that eventually became impossible to ignore.

A bug surfaces. Someone says, “I think we dealt with something like this before.” Nobody can find it. We piece together the fix from memory and move on. A new team member joins and asks about a feature the team built months ago. There’s nothing clean to show them, just a trail of closed tickets buried somewhere we couldn’t easily reach. A decision comes up in planning that feels familiar. We spend twenty minutes in a call discussing something we’d already decided. Because nobody could pull up the history.

That’s what Jira was costing us. Not in one blow. In slow accumulation.

The Tracking Was Fine. The Memory Wasn’t.

I want to be fair here. Jira did what it was supposed to do while we were in it. Current sprints were visible. Active tickets had structure. Day-to-day tracking worked.

But a project management tool isn’t just a to-do list for the current week. It’s supposed to be an institutional memory, a record of every decision, every bug, every feature the team has ever touched. That record is how you stop repeating yourselves. It’s how you bring someone new in without starting from scratch. It’s how you answer “didn’t we already try this?” with something more reliable than whoever happens to remember.

We couldn’t do that in Jira. Maybe we were using it wrong. Maybe the configuration we had just buried completed sprints in a place we never found. But for a small dev team without a dedicated Jira admin, the practical reality was this: anything older than the last couple of sprints was effectively gone.

*Setting Up ClickUp
*
I set it up myself. That’s worth mentioning because it says something real about the tool, a PM who isn’t a developer and doesn’t have a technical setup background could get it running without outside help.

It took some time to figure out the structure we wanted. What folders, what views, how to organize the workspace so the board stayed clean and readable. I made some early decisions that I later adjusted. Nothing dramatic. Just the normal process of learning a new tool and shaping it around how the team actually works.

What I didn’t expect was how quickly the history question got answered.

In ClickUp, you can scroll back to the very first issue ever created in the workspace. Not archived somewhere behind three clicks, not in a separate reporting view that requires a different permission level. Just there, in the same place as everything else.

The first time I went looking for something old and actually found it, quickly, without asking anyone. I didn’t feel excited. I felt relieved. The kind of relief that comes when something works the way it should have been working all along.

*What Actually Changed for the Team
*
Three things that were real problems before are noticeably better now.

When a bug surfaces that feels familiar, we can check. It takes a couple of minutes. Sometimes we find that we did deal with it before, and the solution is right there. That alone has saved us from re-investigating things we’d already solved.

When someone new joins the team, there’s something to show them. The history of the product is visible. They can scroll back and see how features evolved, what got built when, what decisions shaped the current state of things. Onboarding isn’t starting from zero anymore.

And decisions stop getting relitigated as often. When someone says “didn’t we already discuss this,” there’s somewhere to go and check instead of relying on whoever has the best memory in the room.

The team engages with the board more than they did with Jira. I think part of that is the interface, ClickUp is easier to update without thinking too hard about it. But part of it is that the tool feels like it’s working for them rather than requiring them to work around it.

*What Didn’t Change
*
The board still gets cluttered if we let it. That’s not a tool problem, that’s a discipline problem, and no software solves it. I still spend time before some sprints cleaning things up so the week starts clearly.

And the history only helps if you actually go back and use it. That took a behavioral shift, remembering that the record exists and reaching for it instead of defaulting to memory. We do it more now than we used to. But the tool didn’t force that. We chose it.

*The Honest Verdict
*
If you’re a small team running Jira because it’s the standard and you haven’t stopped to ask whether it’s actually working for you, it’s worth asking.

For us, the problem wasn’t dramatic. It was slow and quiet and expensive in ways we didn’t fully notice until we had something to compare it to. The switch was worth it. Not because ClickUp wins every feature comparison, but because it solved the specific thing that was costing us without requiring a full-time administrator to keep it functional.

Set it up yourself. See if your history is finally where you can find it.

That’s the whole reason we switched.

Five People Left. One Product to Ship. The Day After the Layoffs.

Ali Raza — Wed, 25 Mar 2026 14:33:29 +0000

I remember logging in the morning after the layoffs.

The team that was left: me on QA, a UI designer, a lead developer, and two frontend developers. Five people where there used to be a lot more.
The job in front of us was simple enough. Finish the bug fixes. Ship version 1. And Keep moving.

Nobody really talked about what had just happened. But everyone was thinking the same thing.

"Am I next?"

The energy in those first standups was different. Quieter. People were showing up but you could feel the weight behind it. Management eventually addressed it directly. If the product doesn't shut down entirely, everyone who's still here stays. Not a glamorous thing to say, but it was honest. And it helped.

Took a couple of weeks before things started feeling like work again instead of aftermath.

What I didn't expect was how it felt to lose the PM who had originally brought me in. The one who gave me the lead QA role in the first place.

That hit differently. Not just because of the extra workload. But because watching someone who believed in you get let go reminds you fast that this industry doesn't run on loyalty. It runs on circumstances.

I felt demotivated. A little afraid. Not for long, but it was there.
The first few weeks of actually running things were just a lot at once. Standups, backlog, QA, feedback cycles. All landing on the same day, sometimes the same hour. I wasn't smooth at it. I just told myself to stay proactive, deliver things on time, and keep the pressure as low as I could manage.

The founder and tech lead had my back. That mattered more than I probably said at the time.

And then we shipped it. Version 1, out to pilot customers, more or less as planned. After that we discontinued it and started building V2 from scratch with far more planning and sophistication. But that's a different story for another time.

Looking back, the thing that period taught me isn't really a process lesson. It's simpler than that.

When the team gets cut and you still have to show up the next morning, the only real move is to treat it like a challenge instead of a disaster. Take on less pressure than the situation is trying to hand you. And if your management is genuinely in your corner, lean on that. It makes more difference than most people will admit.

The five of us shipped a product. That's what happened.

I Didn’t Plan to Become a Project Manager. A Layoff Did.

Ali Raza — Mon, 23 Mar 2026 13:20:03 +0000

I clocked in like any other morning.

First thing I noticed was a few profiles gone dark in the workspace. Deactivated. Just like that. I knew layoffs were coming. The company had been struggling with delivery, and the signs were there. But knowing something is coming and actually seeing it happen are two different things. It hit different that morning.

I sat with it for a second, then got back to work. I was leading the QA team at the time, and I use “leading” loosely. We were a small, inexperienced crew. I was waiting for the PM to drop the day’s testing tasks in the chat.

The tasks never came. The PM was gone too.

A little while later, the co-founder (tech lead) messaged me.

He walked me through what happened, who was let go, what the team looked like now. Then he asked if I could run the standups for a week or so while they figured things out. Just temporarily.

Sure, I said. No problem.

Then, almost like an afterthought, he asked the real question.

What if you just take over? Like, as PM?

My first thought, honestly? What if it doesn’t turn out good? What then? That was it. Not excitement, not confidence. Just that. We were already down to a skeleton team. The last thing anyone needed was a QA guy fumbling through a role he’d never done before.

I wasn’t a project manager. I had no certification, no formal training, no real framework in my head beyond what I’d absorbed standing next to the team for months. I was a QA lead, and even that title was a stretch given how new I was to it.

But he didn’t give me the chance to spiral. He backed me up, talked me through it, told me he’d be around.

So I said yes.

Later that same day, the founder reached out and officially welcomed me as the new Project Manager.

I stared at the screen for a moment. Then I thought, okay. So now what?

That first week was a lot.

I announced it in the standup myself. Something like “I’ll be running these going forward, and I may be stepping into the PM role full time.” No fanfare. The team took it fine. I had always been around, always been in the loop on QA updates, so it wasn’t exactly a shock. Just a new label on a familiar face.

But behind the scenes it was a completely different story.

I was still doing QA. The whole QA team had been part of the layoffs, so that work didn’t disappear, it just landed entirely on me. On top of that I was learning on the fly how to run standups properly, starting to understand what a PM actually owns, how to run sprint planning, how to think about blockers differently than I did as a tester.

The co-founder (tech lead) guided a lot. I’m not going to pretend I figured it all out alone. He taught me how to read the board, how to plan a sprint, how to actually run a standup that’s worth everyone’s time. The founder, who is himself a certified Scrum Master, was deeply involved and patient.

Still. At some point every day, it was just me and the screen and a list of things that needed to get done.

That was about one year ago now.

I’m still at the same company, still running the same product, a business communication platform with a growing set of AI features. The team has grown, the product has grown, and somewhere in the middle of all of it, so have I.

If I’m being honest about what I actually learned, it comes down to a few things.

You don’t get ready and then step up. It’s the other way around. There was no moment where I felt fully prepared before saying yes. The preparation came after, through the stumbles, through the late nights juggling QA and PM work alone, through the sprints that went sideways, through learning to give feedback I didn’t know how to give yet. Waiting to feel ready would’ve meant never going.

The other thing is that someone believing in you before you believe in yourself is genuinely underrated. I didn’t have a PMP. I still don’t. I had a co-founder who said he thought I could do it, and he said it with enough conviction that I borrowed some of it until I built my own. Real confidence, for me, was borrowed first and earned second.

And then there’s the ambiguity thing, which nobody really prepares you for. There’s no playbook. No one hands you a document called “here’s how we do PM at this company.” There was a board, a team, a product that needed to ship, and a blank page where my role was supposed to be. You figure it out as you go, you make calls you’re not totally sure about, and you communicate with more confidence than you feel. That part, I think, is the actual job. The tools and frameworks you can pick up in a few weeks. The ambiguity tolerance takes longer.

I’m writing this mostly for the people sitting somewhere in the middle of their career, in a role that doesn’t fully reflect what they’re capable of. A QA lead, a coordinator, a junior dev who’s been quietly picking things up for months.

If someone asks you to step up and your first thought is what if I’m not good enough, that’s normal. That’s just what it feels like.

Say yes anyway. The rest comes.