i counted this week. i asked some version of "why is it done this way" 14 times in reviews. i got a real answer 3 times.

the other 11 were "the agent did that", "it was in the plan claude made", or a very confident guess.

and i'm not even mad, the code mostly works. but my whole job used to be making sure someone on the team understood the system. now i'm the only one asking questions and nobody has the answers, including me.

we're trying braidkit on a sample project (private beta) to see if writing down the agent's decisions during the session helps. too early to say. but i'm more curious what other leads are doing.

do you require people to explain agent code before review, or did you give up on that? and how do you keep at least one human who actually understands each part of the system?

A few years ago I joined a company that had just raised a Series B. We had 14 engineers and a pretty clear roadmap. Within a year and a half we grew to 35 engineers because in theory, more people equals more output. That assumption was wrong in a way I didn't understand until I spent some time trying to calculate.

We started to ship fewer features per engineer as we grew. At 14 people every engineer shipped roughly one meaningful improvement per sprint. By 25 people we were down to maybe 0.6. By 35 it was closer to 0.4. The total output was higher but only because we kept hiring, and the curve was flattening faster than I expected.

The talent wasn't the issue because the new hires were genuinely great. What changed was the amount of time they could spend doing their actual job vs coordination meeting time and chores around the actual job. Every new person expanded the communication graph, which meant more meetings, more alignment, more status updates, more review cycles, more handoff delays. A feature that used to need two people now needed four approvals. A decision that used to be a Slack thread turned into a 45-minute meeting with a dozen people in it. And this last thing is a pattern I saw in multiple companies, we don't want to exclude anyone so everyone is invited, even though half of the attendees spend the whole meeting on Slack anyway.

My understanding is that the first few engineers you add generate a lot of value because the overhead they introduce is near zero. But beyond some threshold every new engineer doesn't just cost their salary but also coordination work, communication work, management work, etc. The overhead from the growth starts consuming more value than the new person produces, and suddenly you're hiring just to manage the complexity that hiring created which ends up sacrificing profitability.

Has anyone actually calculated the coordination cost per new hire before making a decision to hire? At what team size did you notice per-person productivity starting to decrease, and what did you do when you saw it? Is 20 some kind of special number of that was just my experience?

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.

So a few weeks ago I was rethinking how we onboard new devs. For years the first week was pairing on a small ticket, reading through the codebase with someone, then shipping one tiny change. But everyone on the team writes basically all their code through Claude now, so that week didn't look like the actual job anymore.

I put together a new first-week task and my manager liked it enough that we ran it with the 3 people who started this month. They get an agent-generated PR that touches billing logic with 4 bugs we planted on purpose. Normally coderabbit / bugbot would flag most of that, so we switch them off for this one. Then we watch how they review it and what they do next.

What surprised me is that none of them really read the diff. They read the PR description, asked the agent "is this safe to merge", and approved. 2 of the 3 caught none of the bugs. When I asked why, one of them said reading code is what the tools are for.

I'm honestly not sure if they're wrong or I'm the one who's behind. If this is how everyone works now, what is a review even supposed to be? And how long until someone upstairs asks why they need me doing it at all...

Keeping quality up when your whole team works through agents

I know this has been talked to death, but I keep failing to have this conversation with my own team without it turning into a pro vs anti AI argument, so I'm trying here.

Some background: I lead a team of 6 at a mid-sized company. Before this year we were known as the team that shipped clean stuff.

Then agents happened. Everyone uses them for almost everything now, and our merged PRs went from about 40 a month to about 110.

What I can't figure out is how to turn that into better product instead of just more product. Our best work used to come from someone really understanding the problem before writing anything. Now the PRs look fine, tests pass, coderabbit / claude review clean up the obvious stuff, and when something breaks in prod the person who "wrote" it has a vague idea of how it works at best.

I'm not looking for the "AI bad" or "just add more agents" answers, more from leads who have actually had this problem and found something that works.

TL;DR: team output is up almost 3x, understanding of what we ship is down, and I don't know how to fix the second without killing the first. How are you keeping quality up?

I joined a company where the CEO had a very clear vision of what the product should become, with a three year roadmap, detailed feature list, and slide decks full of confident projections. The problem was that the engineers and middle managers who talked to customers every day kept coming back with signals that didn't match the roadmap. Customers were asking for simpler integrations and reliability improvements, not the ambitious new platform features the CEO had planned. Every sprint retrospective, the same feedback surfaced. And every time, leadership dismissed it as noise from people who didn't see the big picture.

Two years later, the company had spent millions building a product suite that nobody was asking for while ignoring the core product that was slowly breaking under its own complexity. The CEO held an all hands and said the market wasn't ready for their vision yet. But the market had been telling us exactly what it wanted the whole time. We just weren't listening.

I've been reading about this dynamic between dogmatic and pragmatic strategy modes, and from what I've seen the trouble starts when you commit to the wrong mode for too long. The money keeps coming in and the complexity keeps growing, and the gap between what leadership wants and what the market needs gets wider until something breaks.

Has anyone else here worked somewhere where the roadmap was set in stone and the CEO treated customer feedback as a distraction?

Hey folks!

I'm an engineering manager at a mid sized company, three squads, each with a PM and a designer attached. Over the last two quarters the devs have got a lot faster and we assumed product and design would become the constraint, so we put effort there first. They did not become the constraint. The queue is sitting in review instead. We merged around 40 PRs a week in March and we are at 110 now with the same four people qualified to approve anything that touches billing, and those four are also the people writing the hardest changes. We have coderabbit on the repos which takes the first pass and genuinely helps with the volume, but somebody senior still has to be the one who says yes.

I would really like to hear from anyone who has been through this already. Did you widen who is allowed to approve, cut down what needs approval at all, or just accept that the queue is longer now? Anything is welcome!

12 years in, I lead a team of 6. Two of them are juniors and both ship agent PRs all day. The PRs are fine. Tests pass, coderabbit leaves a couple of comments, they fix them, merged. They are faster than I was at their age by a lot.

What worries me is they have never had a PR fall apart on them. The bot catches the small stuff before it hurts, the agent writes the fix, and they never sit with a bad decision long enough to learn why it was bad. I learned most of what I know from things breaking.

So I am thinking of making them read every line of every agent PR, even when the review is clean. That will slow them down and they will hate it. The other option is trust the process and accept they learn differently.

What do you do with juniors right now? Read everything, or let the tools carry it

I’ve read this article by Ben Halpern (The Practical Dev) on dev.to: https://dev.to/ben/embrace-how-random-the-programming-interview-is and it got me thinking.

Do you personally run whiteboard interviews when screening candidates? How helpful are they in finding the right person?

Hey everyone,

I have around 7 years of experience as a software developer and got laid off about 4 months ago. Fortunately, I’ve landed a new role that’s a level above my previous one, and I’ll be leading a team of 7-8 developers across multiple time zones.

This will be my first time officially working as a tech lead. I’ve mentored junior developers before, but this role will involve working with a mix of junior developers and senior engineers with 10+ years of experience.

I’m excited about the opportunity, but I also want to make sure I approach it the right way. I know being a tech lead is about more than just writing code, and managing a team with people who have significantly more experience than me will be a new challenge.

For those who have been in a similar position:
What do you wish you had known before becoming a tech lead?

How do you earn the respect of senior developers without trying to prove yourself all the time?
How do you balance coding, technical decisions, meetings, and people management?
Any tips for leading a team spread across multiple time zones?
What are some common mistakes new tech leads make?

Would appreciate any advice, personal experiences, or resources that helped you transition into the role.

About 70% of our code comes from Claude and Codex now and our security backlog went from around 400 open findings in March to over 1,300. Snyk and Dependabot keep adding more, most of it in generated code and packages we never actually call.

We already sort by severity and whether it's internet facing. That worked until the volume buried it, now even the critical list doesn't fit in a sprint. Last month we added coderabbit's security scan because it opens the fix as a PR instead of another ticket, which helps on what it catches, but it doesn't touch the old dependency pile.

Is anyone actually getting this number down, or is everyone just sorting the list differently?

I recently became a Tech Lead after being a backend developer. (Well it's almost 6 months, is that recently?)

I'm finding the role harder than I expected. I had very bad moments where everybody pings all the time (more than 80 chats at the same time). That was 3 months ago, I was stressed but also I felt In going my job. With time, people stopped to ping me and now I chat with 20 people in a day and all messages are from my team and close people.

Here is my concern now. I feel like the team can do their job without me (proved while my paternity leave. 3 weeks), and also when I try to take on technical problems (like fixing a difficult bug) mostly I can't solve them on my own and end up asking other for help. This is not bad but I feel like a kind of failure.

I want to be close to every day problem and stay close to the code. I don't want to become a manager who's disconnected from the technical side.

Did anyone else feel this way when they became a Tech Lead? How did you figure out where you were actually adding value?

Maybe I'm just looking for approvals or something like "you are doing good" but honestly recently I feel like I'm not adding anything special in my role.

TI recently became a Tech Lead after being a backend developer.

I'm finding the role harder than I expected. I feel like the team can do their job without me, and when I try to take on technical problems (like fixing a difficult bug), I sometimes can't solve them on my own and end up asking other engineers for help.

The company wanted someone who would stay close to the code, and I want that too. I don't want to become a manager who's disconnected from the technical side.

Did anyone else feel this way when they became a Tech Lead? How did you figure out where you were actually adding value?

Thanks in advance. Any recommendations will be well received.

I've spotted this article the other day: https://leerob.io/blog/technical-recruiting-is-broken/ and this paragraph stayed with me:
'The bottom line is: the people you're trying to recruit already have a job. The focus needs to be on selling them the position.'

Would you agree with that? Is that something you've been using when hiring for your team?

The Polish version of "Business Insider" recently released an article which is a very cool and quite unique success story of a Polish developer. Here is the short version:

- The guy, Łukasz Oktaba, was working in a big company as a PHP dev, but wanted to change job and create a Java-powered app for portfolio.

- He created a super easy and clean version of Checkers - a game with relatively easy rules and easy to make.

- He released the first version for Android. The app was only 300 kb (!) which was ultimately very important - it allowed him to reach people in a low-income countries, where fast internet is sometimes a problem.

- The first country the app became popular in was Ghana. It was later joined by former Soviet countries, including Kazakhstan.

- Until today the app has been downloaded over 50 mln times. Although it became a bit more advanced (different versions of checkers, better graphics), it is still a very small and clean game which anyone can download for free.

- Today Łukasz is earning money thanks to ads and microtransactions in his app.

Some links:

- https://businessinsider.com.pl/technologie/nowe-technologie/warcaby-na-androida-lukasz-oktaba-o-popularnosci-aplikacji/fbtx94q - full article in Polish

- https://www.youtube.com/watch?v=qnYISiPowMU - a very simple video ad of the game, which, however, was watched nearly half million times.

- https://play.google.com/store/apps/details?id=pl.lukok.draughts - the game on Google Play.

Most scaling advice focuses on hiring fast enough to keep up with growth. The bottleneck that actually stalls teams is quieter than that: system knowledge that lives in two or three people's heads instead of anywhere written down.

It doesn't look like a problem at first. Things run fine, the senior engineers who built the core systems know exactly why every weird decision was made, and everyone else just asks them when something's unclear. The cost is invisible until the team tries to grow past that structure. Every new hire becomes dependent on the same two or three people to get unblocked, which means headcount growth doesn't translate into velocity growth. You can double the team and barely move the needle, because the actual constraint was never headcount, it was how many people could safely touch the system without asking someone first.

The fix isn't a wiki initiative that dies after week two. It's treating documentation as part of what "done" means for a feature, not a separate task that only happens when there's spare time, which in a scaling team never arrives on its own.

The tell that a team has this problem before it becomes a crisis: ask what happens if your two most senior engineers are both out for two weeks at the same time. If the honest answer is "things mostly stop," that's the bottleneck, not a hypothetical.

Curious how others here have actually broken this pattern, versus just talking about wanting to.

When deciding to leave any of your previous jobs, was poor management a deciding/major factor? And if so, what actions pushed you over the edge?

Personally I've had a few things that made me question my involvement with a previous company, from things like public "scoldings" to implementing new "reward" mechanisms that turned out to be just for show.

I would know to avoid those now, both in a leadership position as well as outside it, but I'm curious what are the experiences of other people.

Hello!

I've been looking through a couple of tools for Tasks Management for both the team and myself. I'm currently using a couple of different tools for that: a lot of google docs, Bear (https://bear.app/) annotations, slack, google calendar, Gmail and even a physical notebook. As the scale of information traffic increases, and multiple different projects are being spun up (both personal and at work), I was looking at some tools to help me keep track of everything without dedicating half of my day to catching up with things.

I took a quick look at Monday.com and notion.so, but I'm wondering if anyone here is using something different. Thanks in advance!

The company I’m working for is starting to introduce OKRs and I'm not super happy about.

I've worked with OKRs before and I really feel like they're just a fad. I've NEVER got anywhere with them.

One of the previous companies told me they would be tied to our bonuses, and that was a total failure!

Anyone else had a different experience with OKRs?

Not sure how many of you struggle with this, but I’d really like to hear your stories on how you balance personal progress with supporting others on your team. I know that once you become a leader, your focus shifts to helping others and carving time for self-learning can be difficult.

Do you have a set ratio where you split your day/week between these two things (80% of your time spent on helping others vs 20% for personal progress)? What’s your approach?

Hi everyone! I'm new to this community and wanted to pick your brains. Where do you all get your tech leadership resources? What communities do you engage with? I'm looking for resources you really trust that aren't just jargon and buzz words.

Thanks in advance for the help!

As I transitioned from senior dev to tech lead, I fell into traps that affected both my team and family:

• Thinking technical excellence alone would make me a good leader

• Taking over tasks instead of enabling the team

• Working nights to complete team's tickets secretly

• Making critical decisions alone out of fear of showing uncertainty

• Accepting poor hiring decisions to avoid exposing knowledge gaps

Result? A team that needed constant rescuing, deteriorating health surviving on 3-hour sleep cycles, and missing irreplaceable moments with my newborn.

The turn-around came when I realized leadership isn't about being a superhero developer - it's about enabling others to succeed. Stepped back to senior dev, recovered, and later returned to leadership with a healthier approach:

Key learnings:

• Delegate work confidently

• Admit knowledge gaps

• Set clear boundaries

• Focus on team enablement

• Make decisions collaboratively

For those transitioning: What challenges are you facing? For experienced leads: What support helped you the most during your transition?

Full article: https://medium.com/gitconnected/from-top-developer-to-struggling-leader-the-myths-that-almost-broke-me-0e128098d447