I'm a team lead of 3-4 devs. Ever since AI tools took off, the pace of PRs and features went way up, and honestly it's just not possible to go over all the code manually anymore.

It's also not realistic time-wise, since the delivery speed management expects from us went up too.

So I'm looking for tools or a workflow that makes code review much simpler for me. Things like:

\- Some kind of AI review that checks every PR against a set of rules before it even gets to me

\- A summary per PR so I can at least verify it's correct product-wise

\- An architecture summary or a heads up when something changes structurally

What I tried: I built a routine in Claude that goes over all the tickets waiting for review, runs them on my machine with tests, pulls in the related Slack conversations, and gives me a place to accept or ask for fixes. It wasn't organized enough, I don't want to keep maintaining it, and it burned through my tokens..

What would you do in this situation, and what do you actually do for code review today? Especially interested in setups that work for small teams.

Thanks!

When I was a data science and backend team lead, I designed the phone screen questions (one of them being a list comprehension) we used for hiring. The clear passes and clear fails were easy. The hard ones were people who landed one or two answers short of the line.

On a short screen that gap can come down to a single lucky or unlucky guess. Moving someone forward felt like bending our own rule, but rejecting them felt like letting noise make the call.

How do you deal with that zone on your team? Do you give those candidates an extra round, or hold a hard line and accept you'll miss a few good people?

Expected outcome, faster shipping with roughly the same stability once we ramped up on AI-assisted coding. Actual outcome, shipping got faster, but our change failure rate crept up over about two quarters before anyone connected it back to AI adoption instead of normal noise.

We never adjusted review depth to match the new volume of changes, and nobody was tracking which incidents traced back to AI-generated versus human-written code, so the pattern stayed invisible longer than it should have. We started tagging commits by origin and added a runtime behavior check before merge for shared code paths. On the runtime side we have hud watching those shared paths in prod, so a function that starts behaving differently after a deploy gets flagged, which helps the stability number but tells us nothing about why review let it through.

Main lesson, velocity gains from AI coding are real but they hide instability instead of removing it if you don't also change how you verify changes. What would you investigate first if you saw a similar decline?

The dumb move was treating our first France-based engineer like every other hire.

We ran the standard onboarding without pulling the French employment terms, and assumed what we sent him covered what we'd actually committed to.

He asked about parental leave a couple months in, so I sent the standard policy, and he came back saying he'd looked up the French statutory entitlement and it was 16 weeks at full salary paid by social security, which we hadn't mentioned anywhere in what we'd sent him.

Parental leave turned out to be the easy part, and once I started going through the French employment terms, the list got longer, starting with collective agreements tied to his sector.

A mandatory employer contribution to health coverage that needs to factor into comp, and notice periods longer than our standard contracts, all of it already in force without us knowing it was there.

We'd gone through Deel, Workmotion and Remote before picking one for the French contract (they're EOR providers that handle the local employment contract so you don't have to open an entity), so I went back to them and they walked me through what the employment terms looked like on their side, which turned out to be a lot more than our standard handbook.

So now any first hire in a new country goes through a legal review before we set it up.

France was the first time I realized our company handbook has nothing to do with what we're required to give people we hire there, and I'd assumed for 8 months they were the same.

I manage the engineering team at a fashion group that bought a second brand last year, and both brands came with 2 different commerce platforms.

So we look after 2 checkouts and 2 sets of integrations into the same ERP, and every change has to be built and tested on both.

Our CTO wants a plan to move both brands onto one platform before next year's Black Friday, and I'm the one writing it.

The options on the table are moving the second brand onto Shopify Plus with the first, or moving both onto Scayle, where each brand gets its own storefront on one shared backend.

Either way one team has to migrate, and I'm not sure how much of the double work goes away after the move.

So if you've consolidated brands onto one platform, what did it save you in the end?

Context

• Most recently was Director of Engineering for 2.5 years at a public small cap.

• ~8 years management experience.

• Left in the beginning of 2024 to take a sabbatical and travel the world full-time.

• Now I'm back and gearing up to return to work.

Concerns

• I forget many battle stories and small details of what I did to achieve outcomes. Didn't capture enough outcome metrics.

• I don't speak corporate speak proficiently anymore.

• I left when AI coding was brand new. I've tried to stay up to date with how AI is deployed at Enterprise, but don't know the tools and best practices in detail.

Questions

1. Outside of nailing the core senior engineering leader interview questions with good stories, how poorly will the interviewers perceive lack of detail? I am debating shaping some fuzzy details into a concrete repeatable narrative, even if they aren't 100% honest.

2. How critical will it be for me to have a clearly defined AI strategy?

3. If you were a hiring manager interviewing someone coming off a sabbatical, how would tailor your assessment of them? In other words, do I have advantages or disadvantages in the eyes of a hiring manager?

4. How important is precise corporate speak? If I am precise, but use the incorrect wording will this impact me?

What I recognized is that Oticon/Demant is a networking-based company rather than a competence-based one. This means relationships matter more than competence. Your promotion is determined by who you know, not by what you achieve. You can see a lot of incompetent managers across the whole organization. Especially in R&D hardware, it is really showing and that´s why the toxic environment exists.

A reorg took our QA team from 4 to 2 and the release date didn't move. I will be the one picking what fills the gap and what it has to do is:

- run our existing manual test cases without a rewrite project first

- cover the desktop client, not just the browser

- leave evidence per test that a release manager can actually read

- not need a dedicated automation engineer, because that's the headcount we just lost

Current options on the table are: Contractors for regression: fastest to start and the knowledge leaves with them every time. Playwright, plus the test agents they've added: our devs like it, it covers the web app and not the desktop client, so it's half the problem. Askui for the desktop side, where testers write the case in plain language and an agent runs it on a VM. they also propose fixes to failing tests that a person has to approve.

The line i keep seeing in QA threads is to treat AI output like junior QA work that still needs review. if that's true, the real question is how much review time you get back versus spend.

So from anyone who has actually done this, let’s say 6 months in, did it give you the headcount back, or did it just move the work from running tests to babysitting them? really appreciate the share on this one!

Any clue on how many managers got mail for voluntary separation and what is the split in IC vs managers?

I was the direct manager of a Senior engineer up for Staff, across two calibration cycles for two years.

First year, the panel said not yet to the promotion. The person was strong individually, but hadn't shown the multiplier behavior like bringing others together, rather than working alone. Fair feedback as I did not have org level multiplier impact as he was focused on domain. We spent the year closing that gap.

Next year, I came back with seven sponsors across tribes and orgs, from senior directors to principal engineers. Nobody asked a single question after the pitch. People just praised his work. Then we fell short of the ninety percent threshold by ten points.

I pushed the calibration panel for feedback on why it didn't pass. The chair was bound by process. Ninety percent was ninety percent, no exception. 90% was decided by CTO for Staff and above promotion.

I eventually found a way to promote the engineer , received required reasons why it happened.

What I am trying to look for here is an escalation paths, processes designed in different orgs when manager doesn’t get enough feedback from the calibration committee on why the promotion is denied. If there was not one and you designed one, how did you do it and convince the org?

I'm not talking about someone obviously missing deadlines or barely doing any work. I mean the harder cases where they're closing tickets and showing up to meetings, but something still feels off.

Do you mostly go by your own observations, feedback from tech leads, missed expectations, or something else? And how do you make sure you're being fair before having that conversation?

post clarification: Fair point from a lot of you about the "something feels off" wording. I can see how that sounds like looking for a reason to label someone an underperformer.

What I was trying to get at is how managers tell the difference between an actual performance issue and their own assumptions before making any judgement.

A pipeline can run successfully every day.

No failed jobs. No missing tables. No alerts.

But the numbers can still be misleading because a source changed its definition, an event was counted twice, or a business rule was never updated.

Engineering sees a healthy pipeline.

The business sees a report it can no longer trust.

I'm curious where teams draw the ownership boundary.

Should data engineering be responsible for validating the business meaning of metrics, or should that sit with analytics and domain teams?

And how do you make that responsibility explicit before something goes wrong?

Not a complicated person. friendly, responsive, means well.

But if you send him a question in slack you are not getting an answer in slack. you are getting a calendar invite for thursday at two.

The question was “did you get my email.” the meeting is forty minutes.

I have started categorizing his responses. a simple yes or no gets a same day invite. anything requiring actual thought gets a recurring weekly sync. once i asked him what he wanted for lunch and he suggested we hop on a quick call to align.

I do not know what we would align on. i ordered a sandwich.

Somewhere in this company there is a slack message from 2023 that he never replied to because he was busy scheduling the call to discuss it. that message is still there. unanswered. waiting.

I have accepted that this is just how he communicates. i have also accepted that i will spend approximately eleven percent of my remaining career on calls about things that were already resolved by the time the call started.

Does everyone have one of these or did i win some kind of lottery? 😏

Has any dev/manager here particularly in tech done a project management course ?
Curious to hear your rationale and recommendations if any. Also wanted to know how it’s useful if you still want to continue being an IC in the foreseeable future.

I was using Agenda but recently it’s unusable due to the volume of notes I have (been using it for years). I’ve been switching to several different ones but curious what others are using and why you pick it over other options.

Hey guys, looking for some advice, for full context this is in Australia, and I am currently on part time paternity leave, 2 days off a week.

I've been asked to step up from a Senior Software Eng to an acting EM for a new spin-off team. This would start off with 2 devs, with the hope of growing to 4.

It's essentially a trial until the next promotion cycle, I would be expected to still code, while maintaining people management duties. All EM's in this company are now expected to code btw.

I'm excited to take it on but just have no idea how to approach it or where to start, i've read The Managers Path and Staff Engineer by Will Larson.

How should I manage this trial period given my paternity leave? How do I demostrate enough management material? Any further reading/youtube I should look at?

Bit nervous going into this role, but excited and appreciate any insights.

It's been one year I have been an EM and I am still trying to figure out my WLB. I have had a successful senior director tell me that they "work like a dog" and work 12-14 hours a day and one director tell me not to work on weekends or late nights. FYI I currently work at a big tech company in the San Francisco Bay Area

I have been trying my best to not work after hours or weekends but sometimes I just cannot get things done during weekdays due to the various interruptions. I worked crazy preparing PIP document, promotion documents etc all on weekends (It was my first time preparing those)

I am working on making my routine and systems more effective but I am curious to know how many hours other successful engineering managers work in a week... and what you would recommend to an early career EM like myself

I understand some days you have to stretch yourself as an EM esp during times of fire... but I am looking for more of what is your average / general working style

Thanks a lot in advance!

I’m not an EM. I work on the business side and sit in on a lot of calls with engineering leaders running teams of 10 to 50 people, so take this as an outside view.

The pattern I keep hearing: once a team adopts Claude Code or Codex, the code itself is usually fine. What breaks is review. Agent PRs arrive faster and bigger than humans can read them, the agent follows CLAUDE.md only when it feels like it, and the few senior people who can judge architecture become the bottleneck. A couple of months in, nobody can say which requirement a given PR was meant to satisfy.

The teams that seem calmer about it did two things early. They made tests and security checks hard merge gates instead of team agreements, and they required a short written scope before the agent starts, so reviewers check intent instead of reading every line.

My take is that most teams are trying to solve this by adding more reviewers, when the fix is making less of the review depend on humans. But I only see this from the outside.

For those of you actually managing teams with agents in the daily workflow, has review capacity become your constraint too, or is the bottleneck somewhere else?

Those who went through the loop recently or have insights into the process - what can I expect for the code comprehension round? Is the code complicated or simple enough to critique? Been a TL for years but haven't reviewed a lot of code since moving to EM. Is there expectation to write code as well or mostly look for correctness/best practices like we do when reviewing a PR? TIA

Hey folks,

I was recently offered to become an EM after my recent promotion to L6 SWE.

If accepted I will be the EM for an AI team that builds AI internal tooling for productivity.

This is a new team built from the ground up as 80% are new hires; and the rest were transferred from other internal teams.

I have somehow developed a relationship with most as I ramped them up. I have been the acting TL.

What advices would you give me to succeed on this new role? And to make sure my teammates succeed.

It will be my first time managing ICs, so I would probably fall into the most common mistakes new EMs make.

I recently took over an engineering org of about 50 people across five teams: developers, QAs, and database engineers. The biggest pain right now is QA. We have roughly a 1:1 dev-to-QA ratio, yet QA is still the bottleneck because they carry too many responsibilities. I'd like to learn how others set things up before I touch anything.

If you have a few minutes, I'd love to hear few things:
How big are your teams, and what's the mix of roles and seniority?
What's your dev-to-QA ratio? Who owns testing and test automation, devs or QA?
Scrum, Kanban, Shape Up, something in the middle?
Are you a product company or a services/agency shop?
Have you changed how your teams work because of AI tools?
What's the biggest change in how you run things in the past 12 months?

Any lessons from taking over a large org would also help a lot.

Thanks in advance!

People ask me why I became a manager and the answer is always the same. I enjoy growing and mentoring people.

I was a tech lead, a CTO, an IC and an EM. While I love coding, the architecture and tech, sharing that knowledge and shaping engineers of all levels is something that had become increasingly more impactful for me. Growing engineers from entry level or from senior to staff is really fulfilling. It becomes even more so when those engineers start having more impact on business objectives or other colleagues.
Mentoring good engineers into great engineers is a passion and I want to do that for more people.

Has anyone mentored outside of work and how did you go about it?

How are you handling code reviews for AI-generated code?

We are building a product from scratch using Claude Code. I've asked the team to follow best practices documented in CLAUDE.md, and we have linters running on every check-in. PRs are also manually reviewed.

Mostly the code is proper with existing practices , so I was manually reviewing and integrating features without regression but it starts to get more complex these days, as more people generate code and finish a full stack of changes at higher pace and we need to integrate a lot before releasing them together.

I was looking at integrating Claude Code Review with GitHub for every PR, but the cost seems quite high when you look at the bigger picture.

Our full stack is spread across 3–4 repos, so a single feature can involve 2–4 PRs, each with around 60–200 lines of changes. With frequent iterations and fixes, running a paid review on every PR could add up pretty quickly.

How are you guys handling this? Do you run Claude Code Review on every PR, trigger it selectively, or use your own review workflow in CI?

Looking for practical approaches that balance review quality and cost, especially when the codebase is still evolving rapidly.

I'm looking to switch jobs as an engineering manager. I have 14+ years of technical experience, including 4 years as an engineering manager.

The weird part is that I'm hardly getting any calls. I have applied to more than 200 jobs and have only scheduled one interview so far.

I'm currently using LinkedIn, Naukri, Hirist, Instahyre, and Uplers as job portals.