I’m producing roughly half my team’s output, and I’m starting to wonder whether the professionally sensible thing to do is produce less.

I don’t like that thought. I especially don’t like how reasonable it’s beginning to sound.

QA doesn’t have the capacity to keep up with testing. Getting work reviewed is an even bigger constraint. Average cycle time is around five weeks.

Five weeks is a long time for work to sit between being implemented and being delivered. It’s enough time to lose context, move into something else, and then have to reconstruct the reasoning behind a change when someone finally gets to it. Meanwhile, the queue keeps growing.

I can see the bottleneck. What I can’t see is a satisfying answer to what I’m supposed to do about it.

Writing more code doesn’t create more testing capacity. Finishing another change doesn’t give someone else more time to review it. If those stages are already full, increasing my output mostly means increasing the amount of work waiting for attention.

I understand that. I don’t expect unfinished, untested, or unreviewed work to count as shipped software just because I’ve finished my part.

But understanding the constraint doesn’t make sitting on my hands a reasonable use of my time.

There’s an obvious objection to saying I produce half the team’s output: output is an incomplete measure. It doesn’t capture every conversation, every difficult investigation, every review, or every problem somebody prevents. It doesn’t establish that I contribute half the team’s value, and I wouldn’t claim that it does.

It does, however, describe a capacity imbalance that we have to deal with.

If one person can generate a substantial share of the work entering a process, and the rest of that process takes five weeks to move it through, that deserves an explicit decision. We need to talk about what we can support, what we should prioritize, and where the capacity needs to change.

Instead, I find myself considering a much more personal adjustment: make less work.

That advice can sound sensible. Limit work in progress. Help finish what’s already started. Spend time making changes easier to test and review. Those are useful things to do, and I’m willing to treat them as part of the job.

What bothers me is how easily that conversation can drift into something else.

Be more visible. Build more support. Spend more time managing expectations. Make sure the right people understand what you’re doing.

Some of that is necessary coordination. People need context. Priorities need agreement. Nobody should be expected to absorb an endless stream of changes without a conversation.

But there’s a point where I start wondering how much of my effort is helping the work move, and how much is making my productivity socially manageable.

I never thought I’d seriously consider downscaling my output in favor of corporate politics. Yet here I am, trying to work out whether that would be a better career decision.

That’s an uncomfortable thing to admit because it sounds cynical. I don’t want to become someone who carefully calibrates their contribution to whatever creates the least friction. I want to do useful work, finish it properly, and move on to the next useful thing.

I also don’t want to keep generating a backlog that other people are already struggling to clear. QA shouldn’t have to absorb unlimited demand. My teammates shouldn’t have to conjure review time out of an already full week. Their capacity is real.

So is mine.

The question is what we do with that mismatch.

If the most valuable thing I can do is help test, review, simplify, document, or unblock existing work, let’s make that an explicit priority. If we’re starting more than we can finish, let’s decide what stops. If review is important enough to hold delivery for weeks, it needs time allocated to it.

Those decisions would give me something concrete to work toward. I could understand the tradeoff and see whether it improved delivery.

“Produce less” leaves too much unanswered. Produce less for how long? Spend that time on what? What changes would let us use the capacity again? How will we know whether slowing down helped?

Without those answers, restraint starts to feel like an adaptation to an organization that can’t use what I can contribute.

And that’s where the career calculation creeps in. Perhaps I should make fewer changes, spend more time cultivating agreement, and ensure that the work I do produce arrives at a pace everyone finds comfortable. Perhaps that would make me easier to work with. Perhaps it would even make me more successful.

I can see why someone would choose it.

I just didn’t expect to find myself wondering whether the way to succeed at this job was to become more careful about how much of it I do.