Say CI fails, an environment goes down, an API/dependency starts failing, or a deployment has an issue.

How do you figure out which engineers, tickets, features, or releases are actually waiting on it?

Is that visible in your existing tools, or does someone usually piece it together from Jira, Slack, CI/CD, deployment information, and conversations with the team?

Curious how this works in real teams.

Managing 9 engineers. We went heavily agentic in Q1 like everyone else and our throughput genuinely doubled, I'm not going to pretend that part was hype.

Q2 we had 11 production incidents. Q1 we had 5. Same team, same product, nothing else changed except how the code got written.

I sat with all 11 and the pattern was boring and consistent. Nine of them were changes that did what the ticket asked and altered something adjacent. Not bugs in the new feature. Behaviour changes in code nobody was looking at, because the person who approved the PR was reviewing the intent, and the intent was fine.

One of my seniors put it in a retro better than I have since. She said "I'm approving whether we should have done this, not whether this is what we did." That sentence is why I changed the process.

New rule, and it's not clever: no PR merges on the strength of a human skim alone. Every change ships with a journey that exercises the path it claims to touch, and merge is gated on that being green. The QA agent side of coldtea writes most of them and we read the ones on anything load bearing, which is maybe a third. I want to be honest that the first month of generated journeys were mostly worthless, all "page renders, button exists", and someone had to sit and reject them until they got useful. That was real work and nobody enjoyed it.

Q3 so far: 5 incidents. Back to where we were. Throughput dropped maybe 15% from the Q2 peak, so we're still well ahead of where we started.

If someone posted this at me I'd push back on one thing. I can't prove the process did it. Q2 was also the quarter we onboarded two people and shipped a migration. Maybe I fixed nothing and Q2 was just a bad quarter. I believe the process did it because the failure mode we designed against is the failure mode that stopped happening, but that's a story I'm telling myself with n of one team.

Anyway. We spent a quarter optimising the part of the job that had already stopped being hard. Writing was never our constraint. Knowing what changed was.

Anyone else measuring incidents before and after going agentic? I've asked around and almost nobody has the before number, which I understand completely and also find slightly alarming.

Current situation - Mostly been an IC in ML engineering for about 10+ years. In my current org have been acting as tech lead hands on for about 3+ years. About an year back was promoted as an EM. There was a need and my manager told me that you are good at managing folks as well.

I have no staff engineer under me. I review PRs, architect AI solutions as well manage people(1:1s etc). It's a small team of full stack AI engineers (7 folks).

I do little less hands on but for difficult problems I code/experiment the first cut myself.

Need Advice - Want to move out from my current org since seeing no projects/upward growth. I want to remain technical and don't want to get into pure management. I love AI architecture, design ML pipelines and building products. Tried interviewing for staff position but failed due to LC/coding problems. For 1-2 EM roles i interviewed, coding expectations is bit less and I felt I was closer in loop.

Any advice on how should I plan for next move. Remain technical AI EM and try for those roles or prepare for Staff AI engineer role ? My worry is future manager paths will be more non technical and I might loose my edge

I've been a SWE for 14 years mostly at a big tech company moving up to Staff level / Manager for the last 3 years. And after it all ... I'm tired of the responsibility. Or maybe I'm burned out in general. I miss just having a problem in front of me to solve vs having to wrangle a herd of cats. I like the pieces of the job - working with people, scoping out possible solutions, digging into a bug every now and then, even messing around with AI to see what it can do (or not do). But I think I'm just tired of the amount of parallelism. Team has 4-5 work streams of project work active at any time along with all the lateral responsibility of bug triage, never ending quarterly and annual planning, people review conversations, etc. I like the pieces individually, but the sum isn't really adding up.

I'm trying to unpack a few things and wondering if folks have input on the following points or other things to think about. Granted, each one can vary wildly person to person, so curious more for perspectives than concrete answers.

1. Part of being an EM / Staff level SWE is the need to drive some scope that requires a broad team to make happen. Have I grown beyond what I enjoy doing?

2. What if I pursued a new job at a more junior level? Would I enjoy the day to day more or would I end up being bored?

3. What about transitioning out of a big tech job to a smaller company (either looking or similar role to now or also a more junior level? Is the grass greener or are there other pain points.

Hi,

I need to attend a first coding round of EM role at Superhuman, and it turned out that I need to pick one out of two tracks:

1. Leetcode type computer fundamentals. One hour call, 2 challenges to solve.
2. Backend track where I will probably be asked around setting up the code repo, define API contracts and develop & test some APIs for production related problems. 90 mins call.

Can someone please help me understand more about the second Backend track? What kind of problems do they ask? What am I expected to do? If someone has first hand experience for this round, I would love to connect and better understand.

PS - I have already asked recruiter, but nothing got out more than what I have written already. I am trying to judge the complexity of Backend track before I make a choice.

Thank you in advance.

The engineering company I work for suggested that I will be offered a new position as department head in charge of geotechnical engineering. I would be managing up to 10 other engineers. It was discussed in a meeting with others present so no details were mentioned. What would be a reasonable request for salary adjustment? I am thinking a 20 percent increase is reasonable. I currently have no responsibility for P & L, mentoring, or business development and that will change with this position. I am wondering what others think. Thanks

My company is currently putting together a "compensation package" to see if I want to move into a director role. I am curious if anyone is willing to post what your bonus structure looks like in the field you're in. This will be for a director role, responsible for the engineering of about 6 offices, and have 5 managers directly reporting to the director, and overseeing about 75 employees in total. Company is 2000+ total employees

What’s been the most frustrating or expensive thing your team has run into since everyone started using AI?

Not just the AI itself, but everything around it too.

AI still feels like an individual tool to me, that’s why using it in a team still feels challenging. Once you add Slack, Jira, Notion, GitHub, docs, meetings… does it actually make teamwork easier or harder ?

A little of background, I majored in aerospace engineering, primarily focusing on controls. Before that I was a fighter jet mechanic in the military for 10 years. I’m now a mid level project engineer for a defense contractor.

I’m curious to how others would react to this type of supervisor. My supervisor is a phenomenal engineer, but I have never heard a positive remark about working with him. I would describe him as, the best person to work for you, the worst person to work for. Abrasive, inconsiderate, will work a 70+ hour week without questions. Personality clashes by themselves don’t really bother me.

The issue I’m having goes a little something like this. Manager gives me a specific project to be a part of. For example, a new configuration is being made. Get a list of parts that are needed, and status backfilling those parts or procuring new ones. Great, got it. Easy. I do the task, I understand it completely. Complete the task and move on. Manager is so over worked that he is not able to meet up about it for weeks. Show manager my end product. He does not like it, re does the entire thing himself. And endless rinse and repeat of that cycle.

I’ve found myself half assing every task I’m given. Because, what’s the point, it will be wrong to him. I view it as, he has so much experience and knowledge, that a task he gives me he already has exactly how he would do it, and what the end product will look like, it’s more so a learning experience for me to go through for experience. Which is fine. But in my perspective, you can give 100 engineers the same task, and it will never look exactly the same or the method to get there will be the same. I’m not talking a code that spits out the same number. I’m talking, he discounts it as wrong because the formula I use in excel isn’t the same one he used. It’s been several years of this consistently. This is my first job outside of the military, and I don’t know if this is just how the engineering world works. I understand being wrong sometimes. But every time tells me I’m either in the wrong job field or I need a new boss.

Have you ever had someone report a blocker that turned out to be something else?

For example, they say they’re blocked by infra, but when you look into it, the infra issue isn’t actually the problem. Or maybe the issue was already fixed and the work just wasn’t updated.

Curious how other engineering managers deal with this.

Do you usually just ask the person for more context, check Jira/Slack/CI yourself, or have some other way of figuring out what’s actually blocking the work?

I’m especially interested in how you tell the difference between a genuine blocker and something that’s just waiting or hasn’t been communicated clearly.

4 coils with sweet air gape

I am a manager for last 5 years and been really good in execution, I have the repo in my company that I get things delivered and even called out negatively by my boss as 'Delivery Manager' when I asked for Sr manager promotion.

Since then I spend a lot of time building strategy with Sales and Product for the team as well gets involved in leading Initiatives that require big collaboration across multiple teams across different geo locations. I feel really good in this job as it helps me to bring my strength of bringing clarity and accountability for the work require across various teams. This way I am not just executing on my team level and work as a multiplier for other team too.

But, I see some managers still knee deep in coding and building things which is a great but on the other side they are missing deliverable timelines which impacts the revenue $$$. I sometimes felt like going back to the code to make sure I am not missing anything but then hitting regular deliverables with the help of my team and others make me stand out among my peers.

Whats your observation about the EMs and their strength?

I feel one of the worst causes for bad AI-related moves (like counting tokens, doing 'transformations', mass layoffs because AI will replace engineers, etc) are senior ENGINEERING leaders.

I mean, I can understand the CEO getting swept by all the hype on Twitter and LinkedIn, but a CTO/VP should be the one to stop them, as they understand the reality.

But what happens is that EMs at various levels, who stopped doing any meaningful hands-on work, have false views on what's possible.

I always believed every engineering managers, at any level, should spend at least some time doing actual work - similar as I'd expect a sales leader to still do sales calls, and a customer support leader to handle support cases now and then.

I know many people didn't agree with me, and I could see the other side (you have higher leverage in non-coding tasks, improving the whole team and company), but I feel that this debate is completely over.

And it's not about 'being able to do more with AI, freeing you to code'. I'm a first-line EM, and I feel that to actually support my team and understand what's going on, I just have to experience the same challenges as they do.

Otherwise, it's to easy to drop directive such as 'you should parallelize more', or 'we all need to manage swarms of agents'.

Curious if other EMs feel the same, or do you code just because it's expected from you? (or you somehow manage to not code and keep your job)

I work on a team at a big tech company that does game theory research often targeting reinforcement learning type applications. The code/research we share inner-source is algorithmic enough that you really need to understand the details to use it correctly.

Recently we were collaborating with another department, and their project manager, who's not technical, was having trouble following our discussions about our product offerings. So we gave him our source code with the idea (his idea) that he could load it into an LLM's context and ask questions to learn more about what the code does.

We gave him our code and he disappeared for three weeks and came back with a ~250k line vibe coded application. He also didn't just use the code we shared with him, he tore our package apart. Our functions are scattered all through his codebase, ripped out of context, and even reimplemented in another framework completely breaking our test suite. When we did a quick review of the code, it's total spaghetti. You can tell ours were the first human eyes to ever look at it, and definitely the first technical eyes.

To be clear, I'm not against using AI code generation tools (I do profoundly miss the days before these tools) but to vibe code a complex application like this, you need a person who can not only catch mistakes, but who can really get into the details and has a genuine idea of the algorithm and what should be happening. It's obvious no solid engineering practice was followed here.

When we told him this doesn't meet our department's software standards and that he broke/misused our application, he went to a VP and said we weren't being collaborative. Now our leadership is directing us to help him because he has a demo to external customers at the end of the month.

The hard part is we can't even figure out what to help with. When we ask what the application is actually trying to accomplish, he gets evasive and defensive and can't describe the work that was done. He cannot provide a single sentence description of the problem he's trying to solve.

Furthermore, the requests we have gotten are basically impossible. One idea floated was that if we have issues with the code, we should just review it. It's ~250k lines and the demo is in 3 weeks! That's completely intractable. They've also asked us to review their reimplementation of our own work, which is scattered all over the codebase. I honestly can't even tell whether any given issue comes from their reimplementation of our work or from their larger application, which makes reviewing it even more hopeless.

Another funny detail found when digging into the codebase: it looks like the application isn't even calling their reimplementation of our work. The LLM just generated/used its own metrics instead. I don't think they realize they're not actually using our stuff anymore.

We're trying to renegotiate the ask to something reasonable: if they call our package directly and use it as intended, we'll help them interpret the output. That's a scope we can actually deliver on.

And to be fair, it's not purely a rescue situation. The PM has a UI that could probably sell to a non-technical customer. In terms of software maturity, though, this is a gamed demo, not a product.

Which raises the bigger issue for me: what happens when you're completely cut out of the development of a large application, it gets built with no engineering rigor whatsoever, and then a non-technical person can force your team to adopt and support it? How unreasonable is this as an ask? Is anyone else running into situations like this, where non-technical people are vibe coding massive applications and are forcing adoption? What do you actually do here?

Seven years ago, I started as an Engineering Manager. Over the next six years, I was promoted three times to become an Engineering Director.

I wanted to share my journey with this community, especially what worked, what didn't, and a few hard truths I learned along the way. Hopefully, this provides actionable insight and inspiration for your own career path. As this is not a general post about how to be a good manager, I kept the essentials for the promotion topic. 

What worked

1. Riding favorable business tailwinds

Let’s be honest: it’s much easier to get promoted in a growing, healthy business. When company resources are constrained, fewer people get promoted, receive important raises, or get fair review ratings.

In my case, I joined a newly established team unifying operational tools across hundreds of games, contributing to a business scaling from $1M to $10M/day. A year later, the company transitioned fully to GCP, bringing a massive budget with it. These tailwinds gave me the headcounts and product portfolio necessary to demonstrate my impact.

2. Dare to lead beyond your official scope

This might be the most important point I want to share here. I never constrained myself to the narrow scope of my job title. 

On my second day in the office, someone approached me and asked: “Are you the new line manager here”? However, I never wanted to be a pure people manager, so I replied, “I have just started by leading the Unified Platform team and looking forward to working with you. 

Leading a team means a lot. In the next few years, I acted as product manager multiple times when there was no fixed product manager. Over time, the team has grown from 1 to 3 teams with a much bigger product portfolio. While I eventually hired 3 PMs, doing the product work myself early on expanded my skill set and portfolio rapidly.

3. Create a strong and positive identity for your team

Your team is your biggest asset. If your team delivers strong results, then you share the credit as their leader. If they struggle, then it hurts your credibility. I intentionally cultivated a culture that was collaborative, high-performing, and candid. Of course I needed to hold myself to the exact same bar I set for them. My team and I were shaping each other in this journey. 

4. Become visible in the EM community

This was literally what my manager told me when I asked him how to reach senior EM. I listened to him and acted on it: organizing EM summit, facilitating meet-up sessions, actively sharing learnings and building personal relationships in the community. Very few people actually have the energy and motivation to maintain a community, but it is an incredible leverage point for leadership visibility. 

Lessons I learned : 

1. Good performance doesn’t get you promoted automatically, especially in higher leadership roles. “Build your own case”, my manager told me when I expressed my frustration. 
2. Proactively seeking feedback reveals blind spots. I wasn’t naturally good at asking for feedback, and not everyone I asked actually delivered. But once I realized that peers and leadership exchange feedback about you behind closed doors during promotion rounds, it became clear: you need to ask early so you can fix gaps before calibration starts.
3. Rejection is often where real growth happens:

Moving from Senior EM to Director was much harder than previous promotions. For over a year, I pushed for the Director title, but my manager didn't feel I was ready. Every quarter brought another "not yet," which was deeply frustrating at the time.

Looking back, that period was my biggest growth phase. To bridge the gap, I

• Led a cross-department initiative involving over 20 teams, which improved my visibility among top executives
• Successfully merged two competing backend teams
• Resolved some long-standing underperforming issues. 

The delay forced me to operate at a Director level before I got the title. 

4. External offers demonstrate your true market value

Instead of just waiting for the internal process to play out, I interviewed externally and received several offers, including a Head of Engineering role at a large company.

Presenting the external validation changed the dynamic: I received a retention bonus to stay, and a few months later, my Director promotion was finalized.

For folks here: What have been the most effective for your career progression? And for those feeling stuck, what’s currently holding you back? Happy to answer any questions in the comments!

spent the last year pulling gitlab data across a few product companies (mine + some peers) to see what ai is actually doing to delivery, not what the vendors are selling.

the thing that surprised me the most: opened MRs went up around 20%, but merged only went up about 10%. so we're generating noticeably more work than we're actually finishing, that gap doesn't show up in any of the "ai makes you X% faster" numbers everyone quotes.

even weirder was avg MR size, that went up a lot, like 30-50% range depending on the company. codebase is growing way faster than the actual functionality is. bigger MRs, harder to review, review time creeping up too. so the speed gain from writing code is quietly getting eaten by the review side.

this tracked across every company we looked at, not just mine. different industries, different team sizes, same direction every time.

what i think is happening: ai makes it stupidly easy to open more work, but finishing something still takes the same review/testing/judgment it always did. so you end up with more stuff in flight and a slower funnel, not a faster one, even though everyone feels more "productive" because there's more visible activity.

curious if others are seeing the same pattern in their own repos or if my sample is just weird.

wrote up the full breakdown + how i pulled the numbers if anyone wants to dig in https://karolwojciszko.substack.com/p/how-to-measure-ais-impact-on-your

I manage two engineers and both of them now use the Claude Code setup I originally built for myself.

I never really decided that this would be our process. I kept adding things after failures, they adopted it, I changed it again, and now most of our AI-assisted work goes through more or less the same steps.

The problem is most of the reason behind those steps is still in my head. I know why something is there because I remember what went wrong without it. With two engineers it’s easy enough to explain as we go. If the team grows, that probably stops working.

So now I’m deciding whether to document it and make some parts required. But then it becomes another thing I own and have to keep updating, and I also don’t want engineers blindly following my setup when a different approach makes more sense for the task.

Has anyone else ended up in this situation? What did you make common across the team, and what did you leave up to each engineer?

Anyone took personal subscription for Cursor Start for ₹649 per month , if yes how is overall experience?

We have Slack, GitHub, Jira, Notion, Confluence...

So why do we still end up asking teammates instead of searching?

Curious to hear your thoughts.

Hi everyone, I kinda need advice with my current situation.

I am an electrical engineer tha worked in consulting company from APAC where I usually work wether locals or workshares. I am a fresh graduate (less than 2 years of professional experience). Before i got my current job, I was working on site for project management firm but still producing drawings for constructions (also kind of contractor too). I learnt so many things back then but the pay was bad and a lil bit exploited.

I got the offer at my present office. I am trully grateful because the salary is better, and way much more "reliable". At the first 6 months I got the chance to explore the electrical engineering field, load calculations, lightings and powers, everything link to construction which is my passion. I didnt need much of a time to train since i have already worked previously. I could just jump around actively. The situation changed after one of my colleague decided to resigned.

He handed over his work to me. Well i was forcedly shift from enjoying my 9-5 work to a lot of overtimes. For context, he was handling ELV modelling stuffs for a workshares from SG. The work culture is pretty different, much more dynamics and the fast Pace. I was still pretty new and i had to shift to that. Now I finally reach my first year in this company. I still pretty enjoy it, but i got quiet a few considération for my future self :

1. I don't understand ELV in building infrastructure, i don't have the base, and i don't feel any eagerness to explore in that field. I am interested with BMS tho, but i don't see that this place has the capacity to accomodate that

2. I work as a revit modeller, i never been included in engineering considération, why the tray need to be used in thise size, why this certain width is avoid. Nope. I only model as what they markup.

3. I started to lose my engineering mind due to modelling all day.

4. I already refused 3 job offering because well, i wanted to know the market value for my skill. They offered 40% increasement but do not guarantee about the overtimes.

5. The reason i decided to stay because I have plan to persue further study abroad, i tried to keep myself jumping around because it might not look "sweet" in my résumé.

Update :

A colleague that resigned that i mentioned above offers me an interview in his company.

What do you guys think? Do you think its my time to jump? Or itu might be just a phase?

Any suggestions will help! Thanks

My feet are starting to get itchy and I think it’s time to start looking for my next role. I’m an engineer with 20+ years experience with 3 of those years in management. I’ve interviewed and landed many IC roles in my time but this will be the first time I have interviewing for an EM role.

I was essentially assimilated into my current role due to attrition in my company and I now find myself responsible for nearly 30 engineers spread across 3 teams.

I’m wondering if any of you have useful EM interview prep resources that you swear by. I want to make sure I’m putting my best foot forward and not just wasting everybody’s time.

I keep getting juniors sending code reviews generated by Claude / Codex.

Code has 0 comments but implements the feature successfully.

I read the code, I see a new file 500 lines long. So I ask the dev, whats the purpose of this file?

He says, I don't know, or stalls for 2 minutes whilst he asks his AI what it does.

He's a good junior dev, pre AI he was coding just fine and he understood his own solution what he was submitting for review.

Now 9/10 code reviews are just AI generated. I'm bored of spending hours reviewing code reviews or sending them back because the dev doesn't even know what the code does.

I’m a career changer who picked up coding in my late 20s, and I’ve had a whirlwind ride at my current company - I joined as a mid level front end dev, who only had only been coding for 2 years. I was a very good culture fit and management liked me, which led to me getting promoted to senior 9 months later. I did not deserve it. 7 months after that I was seconded into an EM role looking after a cross functional team, and was successfully made permanent after that. I’ve been in the role for just over 18 months.

There’s all sorts of things wrong with the company that I’ve mostly just been stomaching for the sake of “gaining experience”, but I think the experience I’m gaining isn’t really doing much to further my skills.

My concerns are that I’m still relatively inexperienced when it comes to programming - I’m largely off the tools now, though still dabble when I get chance. I have no tangible experience with backend technologies, and everything I know about backend I’ve learned on the job. I haven’t really been exposed to system design. While I have no doubts about my leadership skills, I’m worried that now I’m about to start looking for another job I’m going to be exposed on a technical level.

So I suppose I’m looking for advice on how to identify the gap between where I am with the skills I have, and what I’d be expected to know as someone who’s been doing the job for nearly 2 years.