r/TechLeader

There's one dev on my team everyone jokes about. Every agent PR that touches billing, she asks for the "why" before she approves, and she's blocked more PRs this year than the rest of the team combined. People called her the bottleneck in retro. I kind of agreed.

Two weeks ago she held a refactor of our invoicing job. Tests were green and the summary looked great. coderabbit / bugbot had flagged that the agent changed when a retry fires, and the author marked it as intended and moved on. She didn't. Nobody had asked for that change, and if it had shipped, around 4,000 customers would have been charged twice at month end.

Nobody calls her the bottleneck anymore. What I don't know is how to make that behavior normal instead of it depending on one person, without slowing every PR down to her pace.

Has anyone managed to build that into a team, or is it always just one person?

I’ve been doing the EM role for a long time and I’ve experienced a lot of situations, related to impostor syndrome, being too busy etc..

I never thought about any limiting beliefs until I was asked about by my coach.

I couldn’t give an answer and I’m still struggling about it. What’s your take on that?

I'm starting to think about stepping down as lead.

My team doesn't really have anyone steering anymore. My manager and his manager are all in on agents, and the agents are basically running the team now, not us.

Last week I went through our sprint board properly for the first time in a while. Of the 34 tickets we closed, 31 were opened, written and merged through agents. Specs drafted by Claude, PRs by Codex, first review by coderabbit / bugbot. The humans mostly clicked approve.

Everyone thinks we're moving faster than any team in the company, and on paper we are. Meanwhile nobody can tell me why half of those changes exist, and the one incident we had took 2 days to fix because nobody had read the code it came from.

My manager built a whole internal dashboard over the weekend in one prompt and sent it to the team with "look what I made, not bad huh".

I've tried to slow things down twice. I don't think I can talk them out of it. Sometimes you just have to let them find out.

[removed]

[removed]

[removed]

Been thinking about what “author must prove it works” actually means for background jobs. CI green and linter happy doesn’t answer the retry question.

Here’s the scenario I keep coming back to: a job commits a database row, then crashes before it sends the acknowledgment back to the queue. The broker replays it. Without a deduplication check, that can create a duplicate effect. A successful first-run test never surfaces this, the happy path looks clean.

Some of the discussions here describe reviewers reconstructing the failure path themselves rather than requiring the author to show it upfront. That shifts ownership the wrong way.

What does your team actually require? Does the author have to show an executed failure/retry check and confirm it catches the old broken behavior, or is that left to the reviewer to reconstruct?

(Disclosure: I’m building FetchSandbox, a verification tool, so I lean toward execution evidence. Just keeping that visible.)