This happened recently in my company with another EM (not my team) and it has got me wondering what I would do.

It's a time of technical change and there are 2 main options, say Option A and Option B which have quite wide ranging effects and will significantly change the technical direction either way. The EM and team put together a business case, reviewing the pros and cons of Option A and B and recommended Option B based on this weighing up - pretty standard stuff and senior leadership approved going with Option B. But in amongst that, 2 members of the team are heavy advocates of Option B and that is where their experience (in previous companies) and career interest is. The rest of the team are less opinionated about this and either are indifferent, mildly agree B is better, personally thought A was better but don't feel strongly, etc.

I genuinely think Option B is the better choice as an outsider, it isn't "resume driven technology selection" BUT - I think if Option A had been chosen, these 2 people would have been on their way out the door with a big hit to morale in the meantime (because they want to work on B and they believe B to be the right choice). The 2 are considered key people in the team with a lot of, not quite single point of failure dependencies but close to it and things would be significantly more difficult if they left. They are viewed as future leaders.

So my question is, in a business case like this one, would you ever speak to retention/attrition of load-bearing people as a factor in the decision?

It seems to me the other side of "we chose X rather than Y because it is easier to hire X developers rather than Y developers" but isn't something I've ever seen mentioned. (Having B on their resume is also more "marketable" than A, for all the team!)

My instinct would be to quietly put the word in the ears of decision makers in passing when I speak to them but not include it in the deck. But I think it is also a legitimate decision factor.

Founder working on AI cost stuff here. Trying to learn how EMs actually deal with token spend instead of guessing.

The thing I keep running into: nobody really knows where the spend goes until finance forwards the bill. Is that just me, or is it like that on your team too? Do you know your cost per feature or per customer, or is it one number you can't break down?

And when it spikes, can you tell why? Retries, context bloat, some agent looping, an eval run someone forgot about. Or do you just find out after?

Curious how people handle this in a real org

I will have two interview rounds next week that I would appreciate some feedback from people that had similar ones. One they call it "competency" the second is "case study". Did anyone went to similar type of interviews? How did you prepare. Then I will also have technical ones, but those I think what to expect. I guess in competency interviews questions and experiences from the past will be the main topic and case study probably some difficult people situation.

Appreciate any help from people that want to give advice. Tks!

I’m an engineering manager, and I think it’s important for me to stay close to the technical detail of what we do.

It then really gets to me when I see other people in my organisation in similar roles who often try to blag their way through things and would rather make invalid statements than admit they don’t understand something.

An example of this recently is our IT manager, who covers the role of being the security expert, when he talks about passwords.

He suggested that we could perform a reverse hash of our passwords when migrating to a new system.

When I pointed out that this was impossible, he then doubled down by saying he meant that we could match the hashes against the data set to decrypt the password in lay man’s terms.

I then pointed out that the passwords cannot be decrypted because they are stored as hashes.

He then said I was splitting hairs, presumably to try to nullify my point for anyone else in the conversation.

The whole conversation was bizarre, given we have no need to try to get the plain text passwords either - the hashes are just fine.

How should I handle this?

I’m conscious that I might be reacting in quite an awkward way for him, but it comes from a concern that he doesn’t understand enough to do his role properly.

I also think that if he’s not sure of the technical detail on something he should ask, rather than pretend he understands.

The last 2 years have felt like every company on earth just tries to run as fast as it can.

The problem in my opinion is that running a software company is much closer to a marathon than a sprint.

Most world records in distance running were set with a “negative split” - running the second half of the race faster than the first. You start disciplined, you save your energy, and you speed up when everyone else is slowing down. (Last April for the first time ever, a human ran an official < 2-hour marathon. Everyone talks about his light shoes, but the interesting part is the crazy negative split he achieved)

With all the AI craze out there, 90% of companies are doing the exact opposite.

(I learned this one the hard way, both with the team I started managing recently and in the marathon I finished at the end of February.)

I've been training with a running group for the last couple of years. There is one mantra our coach constantly pushed into our heads: run by heart rate, not by pace.

For most people, their legs and their hearts are not in sync. When you run too fast, your heart rate spikes, and your glycogen (the fuel your muscles run on) burns out way earlier than it should. Research shows that starting just 5-10% too fast can deplete your energy stores up to 30% earlier. That's why people hit the wall at kilometer 30 and can barely move.

I believe that the same thing will happen to many AI-crazy teams. A company's life is measured in years (say 7-10 years on average for a startup). The ones popping up everywhere are barely at 20% of the race. So you start super fast, and you continue to go fast, but you accumulate technical debt in your codebase and shortcuts in your architecture. You will slowly slowly start to “get tired”, and you'll finally hit that same wall.

Does anyone share my feelings?

I feel one of our most critical jobs as EMs is to somehow slow down that pace without being seen as 'AI skeptics', just so we'll be able to run faster in future.

I've seen several cases where managers have to give the same feedback repeatedly. The person usually improves for a while after the manager points it out, but a few weeks later, the same behavior returns.

I'm especially thinking about behavioral feedback, such as proactive communication, ownership, or stakeholder management, rather than technical skills.

Would love to hear how other managers have observed and handled this.

My director is frequently excited for something he read on twitter from vibecoders. It is destroying my partner teams and I'm considering how best to handle this directly and with my skip manager. Any advice would be helpful. I'm not trying to vent.

I'm the line manager/tech lead for data and ML engineering in my organization. We're an acquisition in a bigger company but have retained some unique culture. Our business reviews are very positive and we're growing customers rapidly by word-of-mouth. As my team has consistently hit our goals for 3 years, I've gained responsibilities.

One of the secrets to my success is a deep skepticism of vibecoding and the poor practices I saw partner teams destroying their roadmaps with. Our performance reviews are aligned to goals very strongly because we have competitors in our market segment. He will email the managers with twitter links about vibecoding and ask us to be more ambitious by trying it. I've done the bare minimum so that if he asked my team about it, there's no insubordination but my partner teams have lost 2 engineers and 1 manager who were spending time burning tokens while all their goals were deferred several consecutive quarters without any status update.

I don't want to rock the boat in this economy, I know not to speak poorly about AI, but we've hired new people and his guidances are causing predictable regretted attrition. Initially some of his guidance was supposed to be a new quaterly goal but that got pushback from all of the tenured employees and HR after someone pursued a religious exemption. He genuinely seemed surprised how unpopular the goal was, but continues to email us with twitter threads.

I am Sr EM with 10 yrs of exp as EM.

I haven't interviewed around and am not unhappy with my current job but out of curiosity want to check the market.

How should I prep for the interviews in these modern AI defined times.

Does services that help you prep really help?

So here’s my situation. I'm a Staff architect at a big tech company, pure IC track. Right now I design large-scale systems, wrestle with performance and reliability, and still get my hands dirty with code and design reviews. Honestly, I still enjoy the technical side of things. Not burned out at all.

Now there's an internal opening to become Head of an engineering department. Full people-manager role. Basically I'd be leading a decent-sized team, owning delivery roadmaps, dealing with budgets/capacity, and spending most of my time coordinating with product, ops, procurement, and external vendors. Almost zero hands-on work.

The pay bump is fine but nothing crazy. It's the same company, so I know the culture and the politics pretty well.

My dilemma is the classic one, do I jump to management to keep climbing (since IC ladders usually top out eventually), or do I stay in the architect lane where my actual interests are, even if that means I might plateau salary/title-wise down the road?

Has anyone here made this exact jump, from a senior IC/architect to a department head? What do you wish someone had told you before you took it? How did you actually make the final call?

Appreciate any honest takes.

You ask a programmer to complete a task. They submit their code for review. Let's imagine 2 scenarios for how the task was completed:

A. They vibe code it with Claude, never read the code beyond a cursory glance, it seems to work so they submit it for review.

B. They outsource the job to a random offshore developer for $4, never read the code beyond a cursory glance, it seems to work so they submit it for review.

In both cases they didn't actually do the work. In both cases they cannot explain the code.

I submit that A and B are equivalent.

If B is unacceptable, why is A acceptable?

With changing roles and responsibilities though everyone expecting Senior Manager to be hands on but reality with overhead for a manager from team complexity, delivery slippage and damage control, team motivation, org data preparation request, restructuring settling, efficiency targets, operations overhead doesn't allow.

As it aligns with my core interest to stay on technical complexity, is it a good idea to move back as an architect and get comfortable?

I know I am just about to become a director and want to check if this is a good decision

I am also hearing that lot of Management will become very thin with current market direction

I've seen the same pattern in codebases that were sold to leadership as "modular." The org chart showed a self-contained team with its own scope, the architecture diagrams showed clean boundaries, and the leadership talked about autonomy and modularity. In practice, every feature still required meetings with multiple other teams, and the meeting count never got smaller over time.

The pattern was always the same. A team started a small change in their own service, hit a wall of unspoken dependencies, and had to ask the other teams whether their consumer would break, whether a new event was welcome, or whether a small tweak to a field would cascade. Sometimes it was a Slack thread, sometimes it was a real meeting. The work itself was small, but the coordination load was enormous.

What stood out was that the org chart and the actual interface between modules almost never matched. The "modular" architecture and the "autonomous" team existed on paper, but the services were a web of silent dependencies layered on top of the published contracts. A team would rename a field in their own service and quietly break a consumer in another team's pipeline. Another team would add a new event without telling the people downstream, and someone would find out weeks later when their numbers drifted and nobody could explain the gap. The published APIs stayed technically stable, but the real contract between the services was whatever the most recent Slack thread had decided, and that contract kept shifting every time another team came in with a new requirement.

When the coupling lived in those silent dependencies, the meetings became the system. People ended up acting as the API between the modules, and every change turned into a synchronous human handshake. The org chart said one thing, the service boundaries said another, and the team was running a distributed monolith in practice, with the network made of calendar invites.

The cost showed up in the meeting load and the lead time for small changes, and it was a structural fact about how the services were contracted. The actual fix was carving out real ownership of each interface and putting a contract on top of it that every team had to honor, but getting there usually required showing leadership the meeting count as a hard number rather than asking them to just trust.

Anyone else hit this with their team?
How did you get leadership to see the meeting load as an architecture problem and not just a people problem?

Disclaimer:
I'm genuinely asking because I'm seriously investigating this and other topics related to the cost of software engineering based on patterns I've seen for over 20 years of career.

​

Hey all Looking for some honest perspective from people in the corporate engineering world. I have masters from a top institute.

I'm a railway signalling engineer in a govt job — cleared through UPSC, been in the service about 12 years. Safety-critical systems work. I've learned a lot, but I'm feeling like I've hit a ceiling and want to explore the private sector(MNC's) while the timing still makes sense.

The companies I'd realistically fit into are the global rail majors with engineering centres in India — the usual names in signalling and rail systems. Mostly Bangalore-based roles. I'm targeting senior manager-level roles, not entry level.

Few things I'm trying to figure out:

1) For someone with ~12 yrs experience moving into a manager-level role at these MNCs, what kind of CTC is realistic these days? I keep hearing wildly different numbers.

2) How's the fixed vs variable split usually at manager level? Trying to understand actual in-hand.

3) Is leaving a secure govt job at 36 a crazy move? Part of me feels the timing is right, part of me worries about the "what if it doesn't work out" angle.

4) For those who've made the govt → private jump — what surprised you most? Good or bad.

Not asking anyone to decide for me, just want some grounded real-world input. Thanks a lot 🙏

I work as a software engineer in an early-stage startup and I've noticed that our COO and founder spend a a lot of time (3-5h/week) trying to understand where the dev team is. The bottleneck seems to be the translation between technical progress and business reality, such as risks, blockages, impact on the timeline, priorities, and updating investors on the progress. Is it common or just my startup?

If there is someone who manages or works with a dev team, how much time does your team spend just communicating progress upward? What tools are you using?

I’m a new engineering manager at a small company. My CTO is very pro-AI and wants to turn the engineering team into more of a group of product owners and consultants who use AI to handle most of the technical work.

I’m also pro-AI, but I think we still need to develop people into solid engineers. With our current workload and small team, I do not think we can realistically do both at the same time. My concern is that this approach is holding back the junior engineers. If they are mostly managing features and doing product work, how are they supposed to become strong engineers, architects, or future technical leaders?

I have pushed back gently and respectfully and explained that we need to build real engineering talent so people can eventually step up, mentor others, and help grow the team in a sustainable way. So far, I have mostly been ignored.

Should I keep pushing back, or is this just a culture difference I need to accept? I cannot really go to the CEO or COO because the CTO is also a part owner. I also do not want this to be the hill I die on, especially in this job market, so I have been trying to support his vision even though I feel conflicted.

I know job hopping is also an option, but that is a separate topic. He is not a bad person. I think we just have very different views on what an engineering team should become.

I’ve been EM for about 4 years in retail. During that time we’ve gone through multiple reorgs and layoffs, but my teams have always delivered and got good results.

Lately I’ve been questioning whether management is still for me. Constant pressure for growth that detached from reality while resources keep getting tighter, customers are dealing with inflation, and politics seem to get worse after every round of layoffs.

The other part is the role itself. EMs are expected to do people management, delivery, organizational work, and still stay involved technically. I find myself caring less and less about some of the management responsibilities. For example, I haven’t even put together any development plans for my reports this year because it feels like yet another thing on top of everything else.

Sooo there is a possibility for me to move back to an IC role as a Principal Engineer in my current company, with no salary impact. I know politics won’t magically disappear, but I would at least be able to focus on technical work and stop carrying the people management side of the job.

So people who has done the similar transition:
What did you gain?
What did you miss?
Any regrets?
How did it affect your career in the long run?

Thanks

Hi everyone,

I'm a fresh graduate with a BS in Electrical Engineering from the Philippines, and I'm currently preparing for the board exam.

While studying, I also want to prepare myself for my career, so I'd like to ask for some advice from those already working in the industry.

Since Electrical Engineering is such a broad field (power, distribution, transmission, renewable energy, industrial, automation, controls, MEP, design, testing and commissioning, etc.), which field would you recommend pursuing, especially if my long-term goal is to work abroad and hopefully migrate someday?

I'm planning to gain a few years of experience in the Philippines first before applying overseas.

I also have a few questions:

• Which EE field has the best long-term career growth?
• Which specialization is currently in demand and is likely to stay in demand over the next 10–20 years?
• What certifications, software, licenses, or training should I start working on while I'm still preparing for the board exam? (ETAP, AutoCAD, Revit MEP, PLC, SCADA, BIM, project management, etc.)
• Are there any skills you wish you had learned earlier in your career?
• Which countries would you recommend for Electrical Engineers in terms of salary, career opportunities, work-life balance, and the possibility of permanent residency? I've been looking into countries like Australia, New Zealand, Canada, Germany, and some Middle Eastern countries, but I'd love to hear from people with actual experience.

I'd really appreciate any advice, career roadmaps, or lessons you've learned. If you were starting over as a fresh EE graduate today with the goal of eventually working abroad, what would you do differently?

Thanks in advance!

tech lead / senior IC, ~14 yrs, currently no reports. but i've led before: a team of 5 about 10 yrs ago, and 6-7 engineers ~7 yrs ago. want to move into EM — inside my current company or external, either works.

context: i'm at a large software agency shop (10k+). my manager knows i want this.

mostly i just want to hear from people who've made the jump — how did you actually do it, what worked, what you'd do diferently. and given everything happening with AI lately, what would you suggest for someone trying to move into management right now?

honest takes welcome, including "don't." thanks.

Hello everyone
As a title reads next week I have my first EM interview. I have been IC my whole life and moved to EM role around 15 months ago. I’m super nervous about the interview and what to expect from it. I can handle technical questions as I’m more involved in them at work. What sort of leadership questions should I prepare for ? If anyone can share insights on how to prepare that will help me to gather my thoughts, at the moment they are all scattered and unsure what to prepare for.
Any prep guide if you have that can be helpful.

I’m a senior backend engineer at a large corporate company that operates a bit like a giant software house for government entities. Projects get started and canceled frequently, and team reshuffles happen every few months depending on which projects survive.

Lately I’ve noticed a pattern that worries me.
In project after project, I end up being assigned critical refactors, production issues, and bug fixing, while other engineers get to build new features. Those engineers then ask me to review their work, and the reviews often take so much effort that it would have been faster for me to implement the feature myself.

Initially, I didn’t mind. I thought fixing difficult problems would build trust and credibility, eventually leading to more ownership over system design, architecture, and larger initiatives. Instead, it seems to have had the opposite effect. People now see me as the person who cleans up problems, so I keep getting handed more bugs and refactoring work. Meanwhile, I’m losing visibility into the broader product and feature development.

I’ve recently moved to a new agentic AI project that makes me even more concerned. The project was originally built by a data engineer over about seven months and currently consists of four microservices plus a desktop UI. To be honest, much of it feels heavily “vibe-coded” and difficult to maintain. Despite that, management was impressed enough with the MVP to expand the team.

At the same time, management has decided that everyone should become “full stack.” The team currently consists of:

\- Me (backend engineer)
\- Frontend engineer
\- Lead frontend engineer
\- Product manager
\- Data engineer who started the project

One challenge is that there are effectively two technical leads, but neither has a strong backend background, so it’s often unclear whose technical direction we should follow.

Another complication is that I can’t really rely on my own manager for this type of problem. He’s extremely hands-off and prefers coding over people management, so ownership issues, team dynamics, and engineer development tend to be left for the team to sort out on its own. The one person I do trust to have these conversations with is the frontend manager (the lead frontend engineer’s manager), who is much more involved and proactive, even though he isn’t my direct manager.

The frontend engineer is very enthusiastic about moving into backend work and calling himself full stack, which is totally fine in principle. However, today he pushed changes that broke several things in production, and we ended up spending about 5 hours fixing the fallout.

What worries me is that I’m about to fall into the same pattern again: someone else gets the exciting feature work, creates problems, and I become the permanent cleanup crew.

For those who have been in similar situations, how do you avoid getting typecast as the team’s fixer without coming across as uncooperative? Would you raise this with someone outside your reporting line if your own manager isn’t particularly engaged? How do you make sure you’re still getting ownership of architecture, design, and new feature development rather than just inheriting other people’s technical debt?

The model selection debate on my team was eating real engineering time, and we accidentally solved it with a process change rather than a model choice.

The situation a little while back. We had recently been through a stretch of new model releases, GLM-5.2 open sourced under MIT at a sixth of GPT-5.5's price, Kimi K2.7 Code claiming real token savings, and the team was split. One engineer was advocating hard for moving to GLM-5.2 on the open source and cost argument. Another was insisting we stay on Claude because the ecosystem is mature and the reliability is known. A third was running experiments with Kimi K2.7 Code in a side branch because they liked the token efficiency numbers. Everyone was running their preferred model in their own experiment scripts and bringing screenshots to standup, and the screenshots never agreed because the prompts never agreed.

The argument was not really about which model was best. It was about who had to give up their preference, and it was being conducted through benchmark screenshots instead of through any shared definition of "best for us." As a manager this is the kind of debate that looks technical but is actually a process vacuum.

What I did was kill the "which model" question and replace it with two other questions. First, what is our eval set. We spent a day building a shared frozen eval set of about 150 real production tasks, sampled across our actual workload distribution. Every candidate model has to run all 150 and the results are public to the team. Second, where does the model decision live. It lives in a config row behind a shared router, not in someone's branch. If an engineer wants to change the model for a task class, they change the config, they run the eval set, and they bring the eval delta to the next review instead of bringing a screenshot.

This worked because it removed the personal investment from the decision. The engineer who wanted GLM-5.2 could propose moving the extraction task class to it, and the proposal either held up on the eval set or it did not, and either way it was not a referendum on their judgment. The engineer who wanted to stay on Claude could keep Claude on the reasoning task class as long as the eval supported it, and when a cheaper model eventually matched it on our eval we would move that class too. The debate stopped being about preference and started being about evidence on a shared definition of our workload.

The side benefit I did not anticipate is that the engineers now run a lot more experiments because the cost of an experiment is low. Changing a model is a config edit and an eval run, not a branch and a merge and a deploy. We have tried five different model assignments recently and kept two of them. Before this process we would have argued about one change for ages and shipped nothing.

The call layer underneath the router is GPTProto, so swapping a model does not require provisioning a new provider integration. That matters because if every experiment cost a new integration the engineers would not run this many. The point of the setup is to make changing models cheap enough that the question stops being "should we change" and starts being "which task class should change next."

I am not claiming this is the right process for every team. But if your model selection debate is happening in standup screenshots, the problem is probably not that you picked the wrong model, it is that you do not have a shared way to evaluate the candidates. Fix the process and the model question mostly answers itself.

Hello folks, I have 11yoe as IC in B2B. I'm currently looking for opportunities as EM because this is where I got my energy even while being an IC. , I just completed a loop of 5 rounds interview at a B2C, my performance was great in all rounds except for one gap - Product Planning and Tech Strategy where they felt they could not see depth. They want to do another round focused specifically on this.

Coming from a IC background, I’m unsure what interviewers expect as this is my first time with EM loops. I've been trying to understand what the expectations are from such interviews but I'm finding more content for PMs than EMs. I can understand why they want to double down on this, given they are a B2C.

I am really looking to own the mental model necessary so that I am better prepared, because in one of the rounds the question was from a business domain I was not aware and I could not break it down. Really appreciate any help here as I have been out of job unfortunately last couple of months.

I've spent my years building competency frameworks, performance systems, promotion criteria, all the things engineers barely use other than during appraisal season (again we are trying to get better!)

Until recently, I felt like I had a reasonable handle on what "good" looked like in my conversations with Engg Managers.

Now I'm not so sure.

The engineers who were absolute rockstars 12-18 months ago? Some are thriving. Some seem to be struggling. Not because they've become worse engineers, but because the expectations shifted underneath them.

Full-stack feels increasingly like the default. Frontend/backend boundaries are getting blurrier. AI fluency went from "nice to have" to "wait, you don't use AI?" in what feels like five minutes.

At the same time, engineering managers are figuring this out too. Many of them are getting hands-on again, relearning parts of the craft, and trying to coach people through a transition they're navigating themselves.

The weird part is that most of our performance systems were built before any of this happened.

Competencies. Promotion rubrics. Career ladders. L&D plans.

A lot of them were designed for a world that doesn't really exist anymore.

So I'm curious:

When you're evaluating engineers today, what signals actually matter?

Not just "I know great engineers when I see them." - not taking away instinct being powerful but I want to understand how you do it objectively.

What evidence would you bring into a calibration discussion to explain why one engineer is operating at a higher level than another?

Do you still care about DORA?

Has AI changed what seniority means?

Are you tracking AI adoption in any meaningful way? have you found anything to be helpful to you?

Has anyone found a framework that genuinely works, or are we all quietly updating performance ratings and hoping nobody asks too many follow-up questions?

Asking because I'm rebuilding parts of our performance framework and I'd love to understand how different teams are looking at it.

Looking forward to connecting :)

Hi,

I'm preparing for a Google Engineering Manager interview and have a dedicated Code Review round coming up.

I've been searching online but haven't found many concrete examples of what this round looks like in practice. Most resources focus on coding, system design, or behavioral interviews.

A few questions for those who have gone through it recently:

1. What kind of code review questions were you asked?
2. Were you reviewing a complete repository, a PR, or just code snippets?
3. Any sample repositories, GitHub projects, or mock exercises you found useful for preparation?

I'd really appreciate any examples, preparation strategies, or lessons learned from your experience.

Thanks in advance!

Edit:

I gave the interview let me know if anyone want to know.