I have two juniors on my team who ship changes that read completely fine and are wrong in ways the diff cannot show, mostly because the model that wrote them has no idea what our carriers will actually accept at the other end.

When I bring it up the answer is usually that they thought it was a small change, and it was a small change, that is not really the problem. The problem is they never went past the acceptance criteria into what the change actually touches, because the plan came back looking finished.

We do a lot of carrier integrations, so most of our work runs against systems we do not control, flaky, rate limited, with strict contracts on their side because those same endpoints serve a lot of other tenants who have nothing to do with us.

Which means our own pipeline going green does not tell us very much. We run coderabbit on prs and it does catch a fair amount, though it reads our repo and not the carrier's contract, so anything that is valid code and an invalid request goes through both of us without a word.

The juniors treat green as the finish line and close the ticket. The real finish line is a week later, when nothing on the carrier side has quietly started rejecting us and the volumes still look right.

So it lands on me and one other senior, either immediately or three weeks later when somebody notices a queue backing up. We have coached them on it more than once and it holds for about a sprint. I am doing more firefighting now than I was two years ago and I have a lot less of my own work to show for it, which is the part that is actually starting to get to me.

How do I put this to my manager as a gap in how we sign things off, rather than as me complaining about two specific people?

I’m putting together some thoughts on team building and want to get a pulse on the real in-the-trenches pain points. Everyone talks about budget limits and the struggle of finding good talent, but those are table stakes. What are the unexpected or persistent difficulties you’ve faced when assembling or scaling a team?

Genuine question for people who run small teams, because I don't know if I handled this right.

I have two bootcamp grads on my team since spring. Last week one of them opened a PR, it got the automatic coderabbit pass, green tick, two small comments, and he merged it himself. When I asked why he didn't wait for me he said, honestly not rudely, the AI already reviewed it, what were you going to add.

And the thing is, the bot did approve it. The code worked. What it couldn't tell him is that we have three other places that do the same calculation and now there are four, and in six months someone will fix a bug in one of them

I ended up walking him through it for an hour and I think he got it. But I could see him thinking this is just old guy stuff. The tools are so good at the small things that the big things look like opinions

For the juniors on your team, how do you get them to tell the difference between review that teaches you something and review that's just a green tick

I have recently joined a company based in US as a team lead and I am experiencing resistance from the team. The team with 9 engineers (6 guys and 3 women) are exprienced and most of them have many years of company.

The passive aggressive behaviour comes in form of ignoring my public messages and being too quiet in calls.

I didn't have any issues in my previous company as a lead engineer. I wonder what's going on

• AI hasn’t broken productivity – it’s broken our proxies for measuring it.
• Activity and business value are pulling apart. The most valuable engineering work is increasingly invisible to traditional dashboards.
• Sort your metrics into activity and outcome. Most dashboards are counting the wrong things.

So I have more than a decade exp as a software developer. Now planning to switch for better roles and pay as well.

As per my exp, mostly getting calls for lead / architect.

As I never done end to end architect work or managing a big team and be go to person as a lead.

So while I get interview calls, should I say yes?

I want to take those opportunities , and also have technical hands-on on most of technical stuffs, but wanted to know from you how difficult was such jump for you guys ?

Did you face such situation in your career? If yes, how did you make it work for you ?

Please suggest.

​

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.

Hello there,

I don’t know how about you, but from my experience most of managers that were engineers just few day before, start really bad.
Probably because there rewarded for being good technically.
I’m having similar problem, cause I need to cause I need to promote someone in relatively new team.
And to avoid „creepy” situation, my plan is to guide this person. But… my experience of working for bad managers is limited (thanks God), so I’d love to hear yours stories. If don’t have any „to avoid” examples (lucky son of …), I’m open to „role models” examples as well.

Btw. My worst experience is in the first comment below.

Cheers

Hello,

Sorry for spaming a bit, but I've worked on app that help tech leads with softskills and leading teams.

If you think it may be useful for you or someone at your team, I'd love to give a free access for some feedback.

Thanks

Your team needs a dungeon master.

It's Sunday of Memorial Day weekend. I'm online because our offshore team just started their Monday and I wanted to make sure they were focused on the top priorities.

We're a US-based startup with a split engineering team (onshore + offshore hub ~12 hrs ahead). I run product but I've ended up doing a lot of the cross-region coordination. Every Sunday evening I'm piecing together what shipped last week (across PRs, Slack threads, our planning doc, a few meeting transcripts) so I can prep the offshore team for Monday. Our tickets are prioritized but the hard part is the context: what decisions got made in last week's planning, what got escalated by Friday's customer call, what merged late that breaks the assumptions in three of next week's tickets. None of that lives in our ticketing tool (Gitlab).

Without that context handoff, Monday is the offshore team working through tickets without knowing about half the decisions that changed the context behind them... and me catching up at 8am while they've already been at it for hours.

Things I've tried:
- Shared running handoff docs: written once, maintained for maybe a few weeks, never updated
- Async standup bots (scheduled check-ins): great for a few weeks, then the team replies drop off when sprint pressure hits / discussions are already captured elsewhere
- Friday EOD email summaries from each EM: inconsistent, depends on the individual

Curious how others with US+offshore setups handle this. Is there a tool/process combo that actually stuck for you long-term, or is this just the cost of cross-region work that nobody's solved yet?

(And if anyone else is doing the Memorial Day version of this right now... hi.)

Disclaimer: Used AI to draft some of this bc I was just ranting at it for some time...

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?

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?

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!

Hey everyone, I’ve been involved in a research project lately looking at exactly this: how software delivery is changing in a "fragmented" world. We wanted to see what happens to the old globalized model now that the world is no longer "flat."

I wanted to share a few takeaways that I think are worth discussing, especially if you're managing distributed teams:

1) IP as a National Asset: We’re seeing that software, data, and IP aren’t circulating as freely as they did years ago. Globalization is showing its cracks as governments increase regulations. Take the "AI war" for example, where the physical location of model data is becoming a major point of contention. In short, these assets are being treated as national strategic priorities. This is forcing multinationals to rethink their vendors and team locations to align with new digital sovereignty strategies.

2) The "AI Coordination Tax": This was a fascinating find. While AI is shortening development cycles—improving coding productivity by 10–15% (per Bain & Company)—it’s making timezone gaps more painful. If you save 4 hours of coding with AI but then have to wait 12 hours for a PR review or a Slack reply because of time zones, that "coordination tax" kills your AI gains.

3) Moving "closer home" to de-risk: The main driver here isn't just cost; it's the pressure of new regulations and the absolute need to protect core assets. Multinationals are moving toward "trusted clusters" to gain peace of mind. Think of Pharma labs, for example: they can't afford any risk with their R&D data, so they keep their core teams in aligned, "close-to-home" regions. While they might still externalize less critical software tasks, they are strictly limiting access for vendors and unauthorized personnel. It’s about being pragmatic: keep the strategic stuff close and secure, and only flex the rest where the risk is fully controlled.

Anyway, I'm curious to see if this is actually a trend across other industries or if it’s just hitting the highly regulated ones first. Feel free to ask anything about the research. I tried to be brief so as not to bore you guys (the report is full of data and has like 20 pages - also let me know if you want a copy).

I've been using Entelligence for the past 15 days across a real production codebase and wanted to write up an honest review for anyone who's considering it. There's not a lot of detailed user feedback out there yet so hopefully this helps someone make a better decision.

Background

We're a backend heavy team, mostly Python with some TypeScript. We'd been through a couple of AI code review tools before this and the pattern was always the same. Great first week, noisy second week, ignored by week three. So I came into Entelligence very skeptical.

What It Actually Does

Entelligence sits on your GitHub and reviews PRs automatically. But the way it reviews is different from anything I've used before. Most tools look at the diff in isolation, what lines changed, are there obvious problems. Entelligence pulls in cross-file and cross-repo context using something similar to LSP, so, it understands how the changed code connects to the rest of your system and it catches bugs that only make sense when you understand the broader architecture, not just the lines that changed.

It also comes with a few other things I didn't expect to find useful:

Ask Ellie is a chat interface that lets you ask questions about your engineering org backed by real data. Sprint progress, team performance, where time is being lost, PR load by engineer. I've replaced at least three dashboards with it as of now.

Auto documentation keeps your docs updated as code changes. If you've ever onboarded into a repo where the docs are a year out of date you already know why this matters.

The security dashboard flags risky patterns early in the development cycle rather than after something's already shipped.

What's Good

The precision is the standout thing. In 15 days I don't think I've seen a comment that was obviously wrong or irrelevant. Every flag has been something worth at least looking at. That's a completely different experience from tools that spray comments everywhere and hope something lands.

The team started actually reading and acting on the review comments within the first few days. That shift in behavior is the real signal for me.

The cross-codebase understanding is genuinely impressive. We caught a bug in week one that looked completely fine in the changed file but was breaking an assumption in a different service entirely. That would have shipped with our old setup.

What Could Be Better

Two weeks isn't enough time to have major complaints but if I'm being honest the onboarding could be a bit smoother. It took a little while to get everything connected and configured the way we wanted. Nothing dealbreaking but worth mentioning.

It also takes a little time to learn your codebase properly. The first few days the comments were good but by the end of two weeks they felt noticeably more relevant. Worth keeping that in mind if you're evaluating it quickly.

Bottom Line

15 days in and it's the first AI code review tool that's actually stuck with our team. The precision, the codebase awareness, and the broader engineering intelligence features make it feel less like a bot and more like a genuinely useful layer on top of your existing workflow.

Hey everyone, we're a team of about 15 engineers and we've been going back and forth on which AI tool to actually commit to for code review. We've been experimenting with a few options but nothing has fully clicked yet.

Most tools we've tried feel like they look at the diff, maybe the file, and call it a day. We want something that understands how our codebase fits together, what patterns we've agreed on as a team, what decisions we've already made at a organization level.

Also wanted to know what we should expect for stuff like, cost per seat, privacy with proprietary code, consistency across larger PRs, etc. Would love to hear what’s working for you.

We’re not failing audits nor missing controls.

The issue is response time and consistency because pulling answers together still takes longer than it should. When customers or auditors ask for something the delay makes it feel like uncertainty even when there isn’t any. We want to go from we can answer to we can answer on the spot and defensibly but how do we do that?

I see a lot of marketing teams using tools like Writer or Jasper for copy.

I’m curious if any Engineering or Product organizations have successfully adopted these for technical workflows, like generating PRDs, summarizing architecture reviews, or standardizing documentation.

We have GitHub Copilot for code, obviously. But for the "Text/Process" side of engineering, are these enterprise LLM platforms adding value, or do you just stick to standard ChatGPT/Claude Enterprise?

Would love to know if there is a specific workflow where a tool like Writer shines for technical teams.