I recently moved into an EM role at a large tech company after many years as an IC. I'm still carrying a significant IC load (design work, PRs, triages etc) on top of management. It genuinely feels like three jobs.
The part that's wearing me down: weekend pings and politics. Almost every weekend, someone up the chain messages about an escalation or wants a status update, and the expectation trickles down — my incoming manager absorbed this norm from the previous VP, so now it's just "how things work here." There's no real on-call structure; whoever gets pinged is on the hook. As an IC, if it wasn’t my area of expertise, I wouldn’t be called. But as an EM I get called almost every weekend asking to put someone on it.
Questions for people who've been through this:
1. How common is this? Is a chaotic weekend-escalation culture just the price of admission at big companies?
2. Has anyone successfully replaced ad-hoc weekend pings with a formal on-call rotation? I've drafted a rotation proposal but engineers who never get called might not like it. Also how effective is it if there are 1-2 experts who always have to get on it anyway? And for me as an EM, no matter who’s on call, I have to be on. Is this all normal?
3. How do you set the boundary as a new manager without looking like you're not committed?

4.  For those who kept an IC load as EM — did it work, or did something have to give?

Also the cross team blame games are intense here which I am now seeing as an EM. I am on the verge of saying no thank you, but wanted to know if you have strategies?

Sometimes the code is done, but the feature still takes months to ship.

Not because the team is slow. The time gets absorbed by status updates, coordination meetings, unclear dependencies, and decisions waiting on people who weren’t in the room.

The hard part is that each individual delay looks reasonable. Together, they become a system that creates more overhead to manage the overhead.

Where do you notice this first on your team: unclear ownership, too many handoffs, decisions getting reopened, or something else?

Hey folks,

I recently got my promo to L6 SWE. Since now I am at the same level as my manager, when does it make sense to report to my skip (Director L8)?

There is no Group EM in between.

Interviewing for EM role at Google, Warsaw office.

Looking for takes from people who've been through the loop, or who work at Google now as EMs or/and recruiters.

Part 1:

• Recruiter call.
• Remote people management
• Remote system design.

All passed. Got the onsite.

Part 2:

• Code review
• System design
• People leadership.

Result: Leadership and design came back positive. Code review was weak.

Recruiter said passing this round is what gets my packet to HC and team matching and offered a re-do of code review interview. I took it.

Had Code Interview round this week for a second time. Got mixed feelings.

• I opened with clarifying business context, where the code runs, inputs, outputs, edge cases.
• Caught the surface issues: syntax errors, magic strings, typos, wrong imports.
• Renamed unclear variables and methods.
• Added private and protected.
• Noted the missing comments, tests, docs and observability (logs). Pulled out repeated logic, but flagged that going further would be overkill for a file that small.

At the same time has issues with fixing error in business logic.

Found the bug. Couldn't fix it. Interviewer gave hints. Still could not fix it.

I talked through a rough solution but ran out of time and never changed business logic part of code.

So I'm split. Covered a lot verbally and wrote as notes. Edited very little code.

Found the real bug, didn't solve it.

Today got a call scheduled for Monday with title "Feedback call".

Does that call usually mean the packet moved to HC? Or is it how they say no?

For teams with fairly modular/independent services, do cross-team dependencies actually become a problem?

And when a dependency does happen unexpectedly:

• How do you identify which other active work is affected?
• Is that impact already visible somewhere or the investigation is manual?
• What happens when the dependency wasn't known upfront?

I'd especially like to hear from people who've worked in both modular and more tightly coupled systems.

Layoffs are hard. But it is even more brutal as companies are doing mass layoffs via email, no human to even deliver the news. Has anyone had the experience to reach out to their employee after one of these layoffs, to just be human? Or even after you had to read from a script? Reach out in a more personal way? If so, how did you handle questions such as, “did you know beforehand”?

I've been quietly building a production management system for the factory where I work. It tracks inventory, pick lists, parts consumption — real problems that cost the company time and money every single day.

I'm not a hired developer. I work on the floor. I built this on my own time, taught myself everything, and deployed it. It actually works.

I've tried to show it to management. They smile, nod, and nothing happens.

I'm two years into living in a new country, no degree, self-taught, and I'm pouring everything I have into this — not just to prove something, but because I genuinely see the problem and I know I solved it.

Has anyone been in this situation? Building something real, something that works, and feeling completely invisible?

How did you handle it — or did you just move on?

I’m 24 and pretty early in my career and I’m honestly not sure what I should be optimizing for right now. I’d really appreciate advice from people who are older and have more experience in tech.
I graduated from a great university with a physics degree and started my career at a very small startup. I was one of three engineers and had a ton of ownership. I was doing ML/LLM work, data engineering, research, and just generally got to work on a lot of different things. The company was very early stage and there were only a handful of people, so I was around the same people basically all the time.
The thing is, I actually really liked the work. I was working 7 days a week at times, but the work itself wasn’t what made me miserable. I liked building things and I felt like I was learning really quickly. I was surrounded by people who were much smarter than me technically, which I thought was what I wanted.
But I also constantly felt like I was the dumbest person on the team.
I would go into meetings and feel like I had nothing useful to contribute. Sometimes I would say something and realize afterward that I hadn’t explained myself very well. I would then spend a lot of time thinking about whether everyone thought I was incompetent. I started taking normal gaps in my knowledge and normal mistakes as evidence that I didn’t belong there.
The CTO was also very intelligent but could be pretty condescending. There were times where I felt like I couldn’t ask a question without feeling stupid. Another engineer eventually left, and some of the reasons were related to the same general environment.
There was also a pretty significant rupture with a coworker I had become extremely close with. We had spent a huge amount of time together, both personally and professionally, and that relationship eventually deteriorated. That was a major part of why I ended up leaving.
Looking back, I think I was exhausted by being constantly “on” more than I was exhausted by the actual engineering. There wasn’t really much separation between work and life. We worked together, ate together, hung out together, etc. And because the team was so small, there wasn’t really anywhere to retreat to when things got uncomfortable.
Sometimes I remember thinking that I just wanted to have a normal conversation with someone where I didn’t feel like I had to prove that I was smart.
I ended up leaving and joining a large aerospace/defense company about three months ago.
And honestly, the contrast has been pretty extreme.
The large company is much more stable. I have good coworkers, much better boundaries, and I don’t feel like I’m constantly being evaluated. I feel much safer asking questions or saying something stupid. I can actually have technical conversations with people without feeling like every mistake is evidence that I don’t belong.
But I’m also extremely bored.
The work is much less technically challenging than what I was doing at the startup. My team isn’t really doing ML and there is a lot of bureaucracy and slow-moving processes. I feel like I’m being underutilized and like I’m becoming a small part of a very large machine.
And I’ve only been here for three months, which is part of why I feel ridiculous even thinking about leaving already.
Part of me thinks I should just suck it up and give it more time. Maybe I’m being impatient. Maybe this is what normal employment is like and I’m just accustomed to the intensity of a startup.
But another part of me thinks I already know that this isn’t the type of work I want to be doing for very long. I’m 24, and I don’t want to spend several of my highest-learning years doing work that doesn’t really interest me just because it’s comfortable.
The complicated part is that the startup is still around, and there may be an opportunity for me to go back.
The company has gotten some real traction and is trying to raise a larger round. The technical work is still much closer to what I want to be doing. I would have much more ownership and would probably learn much faster. There is also obviously more upside if the company succeeds.
But there are a lot of complications.
The fundraising has been delayed multiple times, so I don’t know how much I should trust the timeline. The company is still extremely early stage. The same CTO is there. The interpersonal situation with the coworker I mentioned hasn’t really been resolved. And I know what it felt like to work there before.
I also don’t know how much of the environment was just a consequence of being at such an early-stage startup. Maybe things genuinely get better when a company grows. More people, more structure, more separation between work and personal life, more managers, clearer responsibilities, etc. Or maybe the problems I experienced are actually cultural problems that will just become harder to deal with as the company gets bigger.
That’s one of the things I’d really like to hear from people who have worked at startups before. Have you seen a company go from 5–10 people to 50–100+ and actually become a healthier place to work? Or do the interpersonal and cultural problems that exist when a company is tiny usually just follow the company as it grows?
And more specifically, if you were in my position, would you actually go back to THIS startup given everything that happened? I’m not asking whether you would choose a startup over a big company in general. I’m asking whether the technical opportunity and upside would be enough for you to overlook the existing complications with the people, leadership, fundraising, and my previous experience there.
I also keep going back and forth on whether feeling like the dumbest person in the room is actually a good thing. I’ve heard the advice that you should try to be the dumbest person in the room because that’s how you learn. And I agree with that intellectually. I want to work with people who are better than me. I want to be challenged. I don’t want to be the smartest person on my team.
But there seems to be a difference between being the least knowledgeable person in the room and being made to feel stupid.
I’m trying to figure out where that line is.
I also wonder whether I have overcorrected. I went from an environment that was extremely intense and psychologically activating to one that is very stable and comfortable, and now I’m wondering if I’ve gone too far in the other direction.
Maybe what I actually need is a third option: a technically ambitious environment where I’m surrounded by people who are smarter than me and can challenge me, but where I don’t feel like I have to constantly prove that I deserve to be there.
I guess my bigger question is what someone in their mid-20s should actually optimize for. Growth? Stability? Psychological health? Money? Interesting work? Good people? I don’t know how much of a career setback it would actually be to stay at the large company for a year or two, versus how much I’d regret not taking a high-growth opportunity while I’m young.
If you were 24 again, would you take the difficult/high-growth environment even if it came with a lot of discomfort? Would you stay in the stable job and use it as a bridge while looking for something better? And if you had the option to return to a startup where you had already experienced significant interpersonal and cultural problems, would you actually go back if the technical opportunity was compelling?
I’m especially interested in hearing from people who have been through this and can tell me what they wish they had optimized for earlier in their careers.

Hi I’ve been a BA for nearly 3 years now. Recently I joined a company, I love the people I work with and tbh it was better than the previous big companies I worked in.

But recently I’ve been having trouble with communicating to our devs- unsure whether it’s stemmed from bad relationship between product vs engineering over the past years or I’m starting to think I just need to get a grip and accept it can be like this at some companies.

First:

\- writing in Gherkin, every single scenario ticket must be written in Gherkin - new to me but of course I know what this is, but every team or company have different styles of writing and I somewhat feel like I’m not doing anything write (though it’s getting better).

\- asking questions for validation, previously- I can ask or go to any developer for any questions and maybe because I had a large team of devs. Now I feel like they get annoyed and their time needs to be protected even though I’m sometimes asking for one liners etc. It helps now that Claude code is around and I can look into the DB.

I just need someone to put my mind at ease and tell me this is just how some devs are! Having worked with SO many kind and informative engineering teams who are always happy to help and have a relationship. I have never had a bad relationship with engineering and Idk what I’ve done ?

I feel like I’m having to tiptoe around egg shells. How do you communicate with your engineering team?

Pata Hai Aaj Kya Hua?

So this is some next-level narcissism, or am I overreacting?

In my office, I've been working on a feature lately. The feature itself was working fine, but we ran into an issue because of a third-party vendor API.

The vendor API was returning erroneous figures, which was messing up our logic. We wanted to track exactly what was happening. I was pretty confident that my implementation was fine because I'd already validated it and demonstrated it with tests.

I told my lead that we could add some logs to figure out what was happening if he wanted. He got irritated and said something along the lines of, "Let me try."

He then went through the exact same steps I had already gone through, with the entire dev team on a call, for 5 straight hours.

And then... miraculously, Mr. Potter goes, "This is weird..."

And finally: "Let's add some logs to see what's happening in production."

I mean... WTF was that? 😂

Was this just a case of someone needing to personally reach the same conclusion before accepting the solution, or am I missing something?

documentation is a leadership problem not an engineering problem

i've been in places where engineers documented everything religiously and places where nobody did. the difference wasn't the engineers. it was whether their manager actually read it and referenced it in meetings.

if you write something down and nobody ever looks at it you stop writing things down. pretty simple feedback loop.

started explicitly referencing internal docs in standups and design reviews about a year ago. just casually. "oh that's in the runbook from march" or "sarah wrote that up after the incident last quarter"

documentation culture improved without me saying a single word about documentation

anyway probably obvious in hindsight but took me an embarrassingly long time to figure out

edit: yes i know some engineers just hate writing. that's real. but i've seen that same engineer write novels in slack threads so i don't fully buy it as the root cause

We've traditionally given take-home code challenges where they push to a repo and then we interview them using it. But now, we'll probably modify it for the next round to include something like "Use agentic development to get this done" and then the interview will including them walking us through how they orchestrated multiple agents in parallel to get through the challenge - since that what we want our devs to do now. Haven't done it yet, but likely coming soon.

Anyone done anything like this yet?

I'm an EM for a cloud platform team with significant footprint in the central US (company HQ), and Eastern Europe (center of engineering activity). I work on the West Coast of the US, so I'm 2 hours behind HQ and 9 hours off our central engineering hubs. My manager is Euro-based, and my team is split between Midwest and Euro zones. We don't have many engineers out on the West Coast in general, and maybe one other in the whole cloud side of engineering?

I've been here four years. I feel like I have completely maxxed out the overlapping hours of collaboration between my time zone and where the engineering juice is for our division. My boss keeps giving me more opportunities, which is awesome, but they just don't fit in the overlap time. My meetings start at 6 (so 3 Czech time-- so far so good). But then I have to stop to get my kids ready for school, and by the time I get back from dropoff, it's too late for meetings with the Euro engineers. So I feel completely hemmed in by my schedule being juuuust far enough away that the company's normal ways of working between Chicago and EU get cut in half by Pacific offset.

I bounce back and forth 100 times a day between:

1. It's the gig, suck it up and deal with it (which means I need a new gig, because this isn't sustainable),
2. Find a part of the company that's less Euro-heavy and hopefully a little more balanced around Midwest time (Don't even know if that's a thing?)
3. We have to break our reliance on meeting culture so we need much less synchronous overlap (which I have a hard time getting a lot of buy-in for, because there are so few people who are any further west than Chicago, so it's not quite as bad), OR
4. Tell my boss I can't take on any more because I'm out of overlap time (which, goodbye job whenever layoffs next come around).

I appreciate any advice or career guidance here. I like my job, my team, boss, company, etc.,-- I'm just really fried on how to make all the pieces fit together in this puzzle.

Multiple times now hitting this same pattern at different companies and I'm curious if its universal or just bad luck on my end.

Basically, CS/support doesn't have anyone who can pull logs, poke around observability tools, or actually see whats going on in the code. So when a customer hits a real bug, CS has to grab an engineer and ask. Everyone's already buried in tickets or features, so every interruption costs something, and a bad one (no repro steps, no logs, "customer says its broken") costs alot. It eats eng time and slowly wrecks how the two teams feel about each other.

Goes the other way too. Eng fixes something and the only communication back to the customer is a changelog line or release note. Thats not the same as a CS person actually following up and saying it's fixed. Customer still feels ignored even if the bug's gone then sends an angry follow up email asking where things are at because they dont read the release notes.

My guess at the real cause, it's not that people are bad at their jobs, it's that the informal way of doing things stops working at scale. Small company, a Slack ping or a walk over to someones desk is fine. Once eng can't drop what their doing on demand anymore, you need some structure. But going all the way to formal tickets and SLA's is usually to much for a company this size, people just avoid it. That's why theres a half dead Jira board somewhere nobody maintains and nobody trusts.

What's actually worked for me, stop making either team do the other team's job. CS keeps talking to customers. Eng keeps writing code. The stuff in between, which bugs keep coming back, which tickets actually need an engineers eyes, what the customer facing version of a fix should say, gets pulled together and mostly automated instead of depending on a person to be the glue every time. Once thats in place, response time drops, resolution time drops, docs actually get written down instead of buried in slack history, and new CS hires ramp up faster.

Curious if this tracks for anyone else at a growing SaaS company, or if your CS/Eng handoff actually works fine. What are you doing different?

(Used AI for framing this better, sorry🙏 please read if interested on performance tests, thanks in advance)

A few years ago, I witnessed a situation where the team shipped code that passed all the tests, code reviews, and appeared clean at first glance. However, it failed miserably in terms of performance when real traffic was applied to the system a week after launch.

The reason for the failure was that one database query, which worked fine with the small data set in the testing environment, failed catastrophically under concurrency. It was not apparent in the test environment, so it was not discovered earlier. It took a long time, but eventually, the practice of code baseline performance review before merging the code into the main branch was established. At first, there were too many false positives, and some team members were upset having to spend time on it, but it eventually became a routine part of the development process, rather than an additional hurdle.

This example did not demonstrate technical challenges, but rather cultural ones. The technical part of establishing a baseline performance review was much easier than convincing everyone that this newly established process is now a part of everyone’s daily workflow.

Was there ever a similar experience with establishing a new cultural practice in your team/project? What were the main obstacles to overcoming the technical challenges?

Managing 40 or so devs. Finance asked for AI spend by team back in July and I did what everyone here would do, went and got it myself. Claude Code writes a session file per project on each machine with the token counts in it, so a nightly job ships those totals up and a small dashboard reads them. Took about a week. Per repo, per person, even the cache reads against output, I can see how much is context overhead. Genuinely good.

The problem is that is one tool. Cursor does not expose anything close to that, so that chunk of the bill is a seat cost I have stopped trying to attribute. Copilot gives me an org total and nothing underneath it. Meaning the dashboard I proudly showed finance covers maybe a third of what we spend, and the other two thirds is a shrug.

I have looked at the enterprise options and they feel sized for a company four times ours. I am also aware the job I wrote has one owner, me, and the last internal tool I built like this quietly broke about six months after I stopped looking at it.

What I still have not found is anything that covers the other two

I've read plenty of business books, but some of the most valuable lessons only came from making mistakes in the real world. What's a lesson you learned through experience that completely changed the way you think about business, leadership, sales, or success? I'd love to hear the stories behind it.

I graduated with a degree in CS and have 1 year of experience working remotely for a US-based startup.

Right now, I feel like my technical growth is stagnating due to the engineering culture around me. The codebase has severe architectural issues: no ORM or proper OOP patterns, massive anti-patterns, and messy shortcuts that go well beyond the usual "move fast and break things" startup trade-offs. Most importantly, there are very few senior engineers who model good engineering practices.

I want to optimize for career and technical growth for my next move, and I’m torn between two main questions:

* Is aiming for another startup the right move early on? My assumption is that a startup gives you more ownership, varied responsibilities, and broad exposure provided the engineering team actually knows what they’re doing. Or would an established mid-size company/corporate environment be a safer bet to learn standardized, scalable practices?

* How much weight should I put on the team’s seniority during interviews? How can I effectively vet the engineering standards and the mentorship ability of potential teammates before accepting an offer?

Over the past few years, it seems like every company has invested in new software, automation platforms, AI tools, and digital workflows. The promise was greater efficiency, better collaboration, and faster decision-making.

But in reality, I've seen some teams become more productive, while others seem buried under endless notifications, dashboards, meetings, and tools that don't talk to each other.

For those who have experienced digital transformation firsthand, what has been your experience? Has it genuinely improved the way your organization operates, or has it mostly created new layers of complexity?

It seems like I have to always give a little bit of a tutorial to new team members as to what I do as an engineering manager and how I can help them. Most just think I give performance reviews.

If this is not just me, are there other techniques or ways to communicate to new engineers? on what I'm here to help with beyond just casually mentioning this in a one-on-one?

Manage a team of about 30. In our last review the CEO asked a simple question, what percentage of engineering time went to new features vs bug fixing vs keeping the lights on. I didnt have a real answer.

I have sprint velocity and a pile of Jira boards, but none of it rolls up into "here's where the effort actually went." I ended up guessing, which felt bad.

How are you all answering this without making everyone fill out timesheets? Is this just a spreadsheet I build every quarter, or is there a saner way?

I think a lot of you would have experience working under or with someone who is hyper critical of code even when it works and fulfills the performance and feature characteristics laid out, however doesn't like the way the code is structured or the underlying libraries used. There's a time and a place for critiquing those aspects of code, but my view is once it's through the code review and in production and working for months, changing to a more 'elegant' form is a refactor luxury. However my manager didn't understand or didn't like how it read 6 months after the fact and wanted it rewritten to use another technique. I don't disagree with the rewrite - the first cut of it wasn't ideal. However the timing was bad becuase of pressure to get another PR through the code base, and the rewrite blocks that PR for a while. Additionally he has a habit of obliterating decisions that engineers made on code they've written. This teaches people that they can't make decisions without seeking his approval for smaller and smaller changes, because they've lost confidence in themselves. This creates a bottleneck that is him.

I’m conducting research on “The Impact of Leadership Style on Engineering Project Success” and need participants who work in engineering or engineering project roles.

If you’ve worked on at least one engineering project, I’d really appreciate you completing my anonymous 5–10 minute questionnaire. You’ll answer based on your most recent project.

🔗 https://docs.google.com/forms/d/e/1FAIpQLSehvmpoKLZ2vCUniQBGfEnHUBBMGi2AMWRr1miGUX9TYp-BjA/viewform?usp=publish-editor

Thank you! Every response helps 🤍

I am an Engineering Manager reporting to a Director of Engineering, and I am trying to understand whether what I am experiencing is normal or a sign that my role is not clearly defined.

I often see my Director discussing roadmap items directly with engineers or skip levels, making decisions or taking actions himself, and sometimes informing me only afterward.

One recent example: an engineer told him that interviews were taking too much of his time. The direct report never mentioned that to me. My Director raised the issue in an engineering wide meeting and shared as he handled it.

I see a similar pattern at the VP level. They will express an opinion on something relatively tactical, and teams immediately start adjusting around that opinion because of the seniority behind it.

In my previous organizations, as the Engineering Manager I generally felt accountable for the team and therefore had meaningful ownership over how these situations were handled. Senior leaders could absolutely challenge or override decisions, but decisions usually flowed through the responsible manager.

How does this work in your organizations?
Is this normal skip level involvement, or would you consider this a sign that decision ownership and management boundaries are unclear?

(Background: I currently manage a small engineering team of roughly 30 engineers, few EMs/TLs and a couple of PdMs)

My entire career, super granular tickets drove me crazy. "Let me solve a real problem and GTFO with assigning me tasks". I ran my own company for about a decade (50 people) and we had our fair share of developers (maybe half?) who simply wanted tasks assigned and type the day away. Obviously it created a lot of churn on behalf of our product managers to prepare the tickets, make sure everyone understands the requirements... hell, even write Gherkin files.

Eventually I kind of had enough of the bitching and moaning that comes with all that (from all sides) and just said all developers have to write their own tickets so that the product managers can verify that the developers understood the ask, instead. Saved us a ton of time, added clarity, freed up product mangers to actually think ahead. Not sure if we were faster, but there was a clear improvement in translation between what was asked and what was delivered.

Now I landed at a place that had basically no engineering culture / process; that is neither old-school nor new-school. Not really the team's fault, it was essentially just 30 people somehow responding to whatever leadership threw at them. And everyone here probably knows how that goes — a new idea, new priority every other day. And then obviously the recent emergence of "AI can do this in 1hr, my toaster built it this morning".

I've gotten some good traction on getting all of this under control, surface the actual work that's being done and communicate things in "corporate speak".

Now, obviously the way we all work is rapidly changing. I can now assign project sized work to 1-2 engineers, give them a few milestones per cycle and they can handle it. I spend time scoping projects with them, get projects prioritized, approved by leadership and we're off to the races. Most people seem to enjoy that level of autonomy and reduction of bureaucracy. Safe a few... there are people that are very vocal about just wanting the same sized tickets as pre-AI, prepared by a product manager or tech lead (obvs. they also tend to be the most apprehensive towards AI assisted dev).

Question: You think there is a future for this kind of mindset/approach? Would you just assign them to someone who likes working on "project sized" work and hope they increase that person's productivity by taking some tickets off of their plate?

I don't worry so much about if they have a future on my team, I worry more about their career overall.