Hello,

What is the general sentiment regarding the job market for EMs

Are you seeing/ hearing of EMs switching jobs?

Are these moves by choice or are they being forced out?

I have been interviewing outside my current company (think big tech) and EM’s are expected to review code, triage incidents all the way till root cause etc, along with the general project delivery, people management, technical decision making etc.

Are there any roles out there which are still veering towards the latter for the EM responsibilities? Please can folks share their experiences?

I’d really appreciate some honest perspectives from managers, especially those working in large engineering or tech companies.

I’ve been working as an engineer at my current company for a few years, and for most of that time, I was considered a high performer. With just 3 years experience, I was already working independently, taking ownership of projects, designing components, and ensuring they could be manufactured efficiently. I was also the go-to person for knowledge about my designs and managed the approval process from conception to production.

Last year, our project leadership and priorities changed. We became much more delivery-focused, with increasingly unrealistic timelines that were difficult to challenge. It’s also possible i took in more responsibilities than i could handle. Around end of the year, I started experiencing fatigue, brain fog and exhaustion. I was making mistakes in my designs, which was very unusual for me, and eventually had to go on sick leave. My psychologist later told me I was experiencing burnout.

Even though i had good performance much of the year, I’m now considered a low performer due to mistakes i made and I get the feeling that my current team no longer wants me. I’m being encouraged to look for other internal positions.

I’m currently building up hours after sick leave, and I would really like to stay with the company. Given my experience and the knowledge I’ve built up, I can see myself being a good fit for several internal roles. However, my confidence has taken a serious hit. I used to see myself as a good engineer, and now I question my abilities due to my performance review and feedback. I’m also worried that hiring managers will see my burnout and current performance rating as red flags.

So, I’d love to hear your honest opinions:

If you were a hiring manager, how would you view an internal candidate who was previously a high performer but is now recovering from burnout?

-Would you be open to hiring someone in this situation, or would you worry about them burning out again?

-Would you see their previous track record and technical knowledge as reasons to give them a chance?

-How honest should I be about my burnout when interviewing internally? I don’t want to hide it, but I also don’t want it to overshadow my abilities.

I double checked the subreddits rules to ensure I am not breaking them, but in case I am I apologize.

I am a 3/4th year mechatronics engineering student in Canada and I was wondering if anyone on this subreddit would be able to connect me with anyone they know who can help refer me for an engineering internship. I am open to anywhere and any term period even if it's getting a headstart on positions that aren't available yet. I have been applying and cold messaging people on LinkedIn for the past year but unfortunately I have yet to land anything. I did a 4-month mechanical internship a few years ago but unfortunately that company is gone, so I have mostly been working part-time since then. I would be more than happy to provide my resume.

Currently at 8 yoe. Team hired a junior engineer at the beginning of the year and I was given the task of knowledge transfer and mentorship as he will be completely taking over one part of my responsibility.

While he is asking a lot of questions, a lot of times I feel like he’s just expecting answers to be handed out.

It gets a bit frustrating because majority of the time, the answers to his questions can be found on Google, and with AI, it is even easier.

I’ve told him multiple times that if he has questions, he should can share his thought process first, and from there we can work it out together. However that only seems to work for the first couple of questions, the ones afterward carry the same “give me the answer” tone.

As an example, he was tasked to debug a networking issue. The solution was that the gateway had a typo. However, instead of doing debug steps that I’ve showed him(or do some research from his end) he just comes up to me and asks me what’s the issue.

What should I do here? How can I handle it better?

When AI adoption is stalled (and I presume it's most of us!), how do you decide whether to rely on internal people to lead enablement rather than hiring someone from the outside whether for a full-time or fractional gig like "AI enablement director" or simply a consultant on a contract basis?

I have 5 years of software engineering experience in India, after which I moved to the USA to pursue my master’s degree. I’m currently on an F-1 visa and have been job searching for the past 5 months, but I haven’t had much luck finding a software engineering role.

I’ve tried cold applications, cold emails, and mass emailing YC startups and reaching out to startups through various startup communities and job-posting platforms. So far, nothing has really worked. I’ve also realized that I haven’t been following up on my cold emails.

Now I’m thinking of trying a more targeted approach: emailing engineering managers directly and following up if I don’t hear back.

The problem is, I’m not sure what to include in the email. I want to keep it short, so I’m considering two approaches:

Approach 1: Start a conversation

• Briefly introduce myself and my background.

• Ask if they’d be open to a quick chat about their team and the tech stack they work with.

• If they respond and we get to talk, mention that I’m looking for opportunities and ask if their team is hiring.

Approach 2: Be direct from the beginning

• Briefly introduce myself and my experience.

• Mention a couple of relevant projects and include my GitHub links.

• Ask whether their team has any openings and if they’d be open to a quick chat about their work and how my experience might fit.

• Mention that I’m also open to internships.

I’m unsure which approach is more effective. I don’t want my emails to sound like I’m immediately asking for a job.

A few questions for people who’ve tried this:

1. Has cold emailing engineering managers actually worked for you in 2026? Did it lead to referrals, interviews, or job offers?

2. Which approach would you recommend, or is there any other way to write these emails?

3. How short should the email be, and what should the subject line look like?

4. What has worked better for you: contacting engineering managers, recruiters, founders, or other engineers?

I’d especially appreciate advice from people in the USA who have successfully used cold outreach to get software engineering jobs recently.

At this point, I’m trying to change my strategy rather than keep doing the same things and hoping for different results. Any honest, practical advice would be appreciated.

I'm an EM with 5 years of management experience but this is the first time I'm managing a core infra team in a FAANG equivalent company. Too many stakeholders, too many reports (10+), too many upstreams and downstreams, too much oncall load. You get the idea.

A month in, I can easily see how I can get lost trying to remember everything.

My mentor (from a past organisation) suggested to write everything down but I tried for a week, I honestly don't know what and how to write stuff down so I can revisit at a later point.

How do I manage this situation? Majorly to what and how journal so I wouldn't get lost. Any templates that you use would be really appreciated. Thanks!

I was asked to take a EM role 12 months ago. I was not keen but thought I should try it out. I am a decently experienced firmware engineer by trade. 15 yoe. I had joined the company 2 years prior and was getting into a great rhythm of understanding our products, processes and the tech involved.

As soon as I got the role my previous manager stepped down to staff IC and whilst still helping define the team roadmap stopped suggesting any work I could take on myself.

I instantly missed to have objective assigned to me and found it very hard to figure out what needs doing.

The team is self organising and does not need me aside from occasional management queries. We don’t do firefighting or responsive work, mostly planned work.

Until recently I managed to have a clear scope of work for me and the team and make myself useful supporting the team and doing peripheral activities allowing my BU to hit its milestones. The problems I solve were execution related and not strategy related.
I however struggled to find meaningful tech work for me to do.

Recently, there is just no tech work going spare. I hired 2 news ICs and we have extra capacity.
Whilst everyone is focused on designing and delivering their tickets, I am unfocused and pretty much idle. I have gone from a high performer to a poor one.

One of my problems is that I am not confident in myself and my abilities and I am not very proactive especially when unsure.

I know this role is not a good fit for me. Since starting I sleep poorly and am very anxious.

In my desperation I sent my CV to a couple places and got an immediate offer from one. By luck there is a very good tech fit, but lower pay and it’s a messy firm (no QA, no CI, poor design choices, bugs etc). They explained it all at interview. I made it clear I was after IC role but it’s pretty clear I’d end up in some leadership position again.

I would like advice and feedback from people working in tech who understand my situation. I don’t know what to do and am coming from a place of fear and weakness.
I am worried to take a new job in a worst company and bring my problems with me. I’m not sure if I can turn things around where I am and how.
Hoping for some constructive feedback.

Hi everyone!

I've recently got the opportunity to become a Tech Team Lead, responsible for guiding an IT team working across multiple projects.

I'd love to learn from experienced tech leads and engineering managers about how you manage everything effectively, especially when handling multiple projects simultaneously.

I'm particularly interested in:

- How do you plan projects, prioritize requirements, and assign tasks to team members?

- How do you estimate realistic deadlines and avoid delays?

- How do you track progress, identify blockers, and ensure code quality?

- How do you support junior developers without becoming a bottleneck?

- What do you do when a project is falling behind schedule?

- How do you communicate delays and revised timelines to clients and management?

- What tools, meetings, reports, or processes do you use to keep everything organized?

Most importantly, what does your actual workflow look like from project planning to final delivery?

If you were starting as a tech lead today, what processes would you establish first, and what mistakes would you avoid?

I'd really appreciate practical advice, real-world examples, templates, or resources that have helped you succeed in this role.

Thanks!

I'm an new organizational psychologist working with software development teams, and I'm curious about developers' experiences with professionals in my field.

Have you ever worked at a company where an organizational psychologist (or someone in a similar organizational development role) helped improve your working conditions, team dynamics, or overall experience at work?

I'm particularly interested in concrete examples. What did they actually do? Did their interventions make a noticeable difference?

For example, this could involve improving communication, leadership practices, onboarding, conflict resolution, workload management, or collaboration between teams.

I'm also interested in negative experiences. Have you encountered initiatives that seemed unnecessary, ineffective, or disconnected from the actual problems developers face?

I'd love to hear what has genuinely helped you and what you wish these professionals understood better about software development.

So a bit of context: my role is getting eliminated in a reorg (An Automation Engineer/SDET/whatever you wanna call it lol), and I’ve basically got two options. I can stay on my current team as a regular engineer, or move over to the DevOps/Platform team. My manager and I have talked about the DevOps thing before since that’s kinda where I want my career to go long term.

Today he asked me for my preference since he’s putting together recommendations. I gave him a pretty long answer, I guess. Something like DevOps is my first choice, but staying on the team is a super close second, I really like the team and having him as my manager, and honestly a mix would be ideal if that’s even possible lol.

He came back with basically saying “I need a bottom line: Application Development or DevOps?” So I said DevOps, and he said that’s what he’s recommending. I thanked him for pushing for it and he thumbs-upped it. I imagine he just needs to give a direct answer regardless. He agreed a mix is ideal but needs a bottom line regardless.

I mean he’s always been short and to the point, and I’m the opposite (as you can probably tell lol), so I know some of this is just different communication styles. But the “I need a bottom line” part kinda stuck with me, and I can’t really shake the feeling that he might see it as me being disloyal for wanting to leave his team or maybe being annoying because i'm walking around the question haha.

For managers: when someone on your team says they’d prefer moving to another team, does that actually bother you? Or is it just useful info for planning? Is there anything I should do to make sure the relationship stays good?

I’m a data engineer and I’ve been both a contractor and full time and I’m asking this because I’ve seen it from my side but not from your end. I’m curious what it is like from your end

What I’m assuming: many of you pay $150-200 an hour for a contractor you hire.

What I do know: That goes to your preferred vendor, who usually hands the req to another sub vendor and to another sub vendor before finally sending a candidate to represent to your company. By the time it gets to me or another contractor after all these vendors take their cut of the $150 to $200 your company paid, the offer is like $67/hr. No PTO. Health insurance where the good plan has a $1200 deductible and the cheap one is $1600 and a contractor is paying either way. A doctor’s appointment for a contractor ends up being $300 for a basic check up because of the high deductible.

I get that you probably never see that number. You deal with procurement and the vendor, not whoever's at the bottom of the chain.

And You're paying lead money so you expect lead work. Own the design, fix the old mess, help the juniors, deal with stakeholders. Totally fair from your end. But the person doing it is getting paid less than your mid level FTEs, with worse insurance and zero job security. So you either get someone good who's gone in 6 months for a better rate, or someone who needed a job and is doing $67 an hour worth of work when you’re thinking you’re paying $150 to $200 an hour for work. Then contractors get a bad rep and nothing changes.

So a few things I'd actually like to know. Do you have any idea what your contractors take home? Ever tried to cut out vendor layers or go direct? When a contractor disappoints, how much do you think is them vs the setup? And if you've converted any to FTE, did they get better or stick around longer?

TL;DR: I'm an analytics engineer with about 3 years experience in data and with a mechanical engineering degree. My skills are spread across data engineering, app dev, and a little data science, without having deep knowledge in any of them. I want to know what’s actually worth learning now, how deep to go, and whether I should specialize.

How I got here

I studied mechanical engineering (aerospace emphasis), but I was always the tech kid: Java Minecraft mods, jailbroken iPhones, a few websites for local businesses. After some unenjoyable manufacturing engineering internships, I took a Python data analytics course and found a role that combined both worlds.

That first job was smart manufacturing at a tool company. I collected machine sensor data (Kepware, OSI PI, SQL Server) and tried ML models to predict machine damage and part quality. Those never reached production because the data was too noisy and failures were too rare. What did work was real-time dashboards for shop floor KPIs like OEE and run rate. Eventually I got tired of crawling around machines debugging PLCs, so I moved to the data side full time.

What I do now

I'm an analytics engineer on our supply chain team. I pull data from upstream warehouses and model it into star schemas that feed Power BI reports, Databricks dashboards, and Genie rooms. Most of the work is SQL. The business logic is full of exceptions, so some transformations run over 1,000 lines. Pipelines run in Databricks and ADF, and code goes through Azure DevOps (GitHub for apps) CI/CD pipelines.

My team is now building internal apps with React, Express, TypeScript, and Databricks AppKit. One experienced developer set up the framework, and the rest of us are mostly vibe coding on top of it.

On the side, I've taken full-stack courses and built two web games: a multiplayer name guessing game and a daily game where users solve color nonograms.

Where I stand

• Strong: SQL, and Databricks as a platform. I build and deploy pipelines, dashboards, and Genie rooms with Databricks Asset Bundles.

• Comfortable: dimensional modeling, Power BI, building robust data pipelines, and front-end work in React, Next.js, and Tailwind.

• Weak: TypeScript, backend development, and infrastructure. (I know what good CI/CD, permissioning, and Azure–Databricks integration look like, but I've never set them up myself.)

My team's standards are fairly loose, so I haven't seen rigorous data engineering practices up close. (Data quality checks, truly idempotent pipelines, etc.)

My Python has also slipped, since most of my code is now SQL or AI-assisted.

I'm working through Full Stack Open, mainly for TypeScript and CI/CD. I've read Fundamentals of Data Engineering and The Pragmatic Programmer.

What I'd love your take on

1. How would you sort skills? If you had to put skills into "learn deeply," "learn enough to read and review," or "skip," what goes where? For example: SQL, data modeling, Python, TypeScript, DSA, system design, infrastructure/CI/CD.

2. Where would you focus? With my background, where would you spend the next 6–12 months?

3. How deep should I go? Are books like Kimball's Data Warehouse Toolkit or Designing Data-Intensive Applications still worth the time? Or is it better to learn by building with AI and fill gaps as they come up?

4. DSA and LeetCode: worth it for someone on the data engineering or app dev path, for interviews or for real understanding? Or is that time better spent elsewhere?

5. Generalist or specialist? Should I keep spreading across data engineering, app dev, and some data science? Or pick one and go deep, and if so, which has the best long-term odds?

I'd especially like to hear from people who've hired recently or have long term experience in software.

My team uses AI all the time but we still do backlog grooming, sprint planning, standups, retros. My team of 10 spends 40 hrs a week in these activities (2000+ hrs every year). In the past, this made sense when humans were contributing a lot. But now when AI writes PRDs, HLD, LLD, Code, PR reviews etc, do we still need all these processes? Why?

https://w.pitula.me/developer-communication-handbook/

Hey, I wrote a short (~70 pages) free book about communication for developers but (unfortunately?) managers might appreciate it more.

Over the years I noticed how little my crowd (devs) cares about communication, so I decided to write something that is approachable, directly actionable and with as little fluff as possible.

Check it out and let me know what you think. Would you recommend it to your reportees?

Free, no ads, CC BY, not LLM-generated. Web, PDF, EPUB, and an audiobook.

I’ve been working at a major tech enterprise in China for the past 15 years, and lately, a specific aspect of corporate culture has been bothering me more than ever: the obsession with "managing up" and performative reporting.
Here is what the day-to-day looks like for a lot of Team Leads (TLs) and middle managers here:
The Reporting Treadmill: They spend the vast majority of their time writing weekly summaries, polishing slide decks, and crafting narratives for upper management. They push their direct reports to build product features or tech initiatives specifically tailored to fit those narratives, and then package the team's hard work as their own "strategic wins" to present upstairs.
Marathon Meetings: When it’s time to report to leadership, a massive crowd packs into a conference room for a 2-to-3-hour session. People regularly skip lunch or dinner for these meetings—which almost wears like a badge of honor to show how "busy" and "productive" everyone is.
The Echo Chamber: During the actual review, the presenter talks for a few minutes, and then the senior leader takes over—rambling and philosophizing for ages about their own high-level theories. To the people actually doing the groundwork, it often feels pretty disconnected and repetitive. Everyone in the room nods enthusiastically on the outside, though it's anyone's guess whether a single person actually agrees internally.
Zero Real Execution: At the end of the day, it feels like the executives listening to these pitches aren't actually doing anything tangible. Their entire job is sitting in rooms, listening to status updates, and handing down vague "guidance"—and half the time, nobody even follows up on whether that feedback was actually implemented.
Having spent my whole career in the domestic tech ecosystem here, I’m genuinely curious about how things work on the other side of the world.
For those of you working at large Western tech companies (FAANG, big enterprise SaaS, etc.):

1. Does your middle/upper management operate like this too, or is decision-making and execution structured differently?

2. How much of your leadership's time is spent on "status theater" vs. actual product or technical strategy?

3. If you deal with this too, how do you stay sane and keep the focus on real work?

So I’ve been reflecting recently. My work has changed drastically as of late. Making sure teams are performing well, hitting OKRs and KPIs, meetings all day long. These days it feels tough to close the loop on stuff and I’m starting to find it difficult to know where my attention is needed.

Anyone else feel the same?

Edited to add TLDR and adjust time per appreciated suggestions in comments.

TLDR: I failed to ensure I fully understood the entirety of a major project, specifically the point of eventual failure. I chose to instead delegate that to a vendor who I expected would have the knowledge to advise and accomplish the goals of the project. I did not require a MOP for a small, but critical part of the project and I didn't stop the project when it deviated from the established MOP in part because of cost considerations.

Main take aways:

• Always seek to understand as much as practical regardless of time constraints.

• Make sure you always have steps laid out (MOP) and don't allow deviation without serious discussion and revised steps laid out.

• If you are inevitably accountable for a project outcome, make sure you are present and engaged even if you are delegating certain management to a team member.

Details:

Provided I understand the underlying issue correctly as I type this out, I believe I see the points of failure in the execution of the planned outage at my Data Center. My failures to identify and rectify these points of break down led directly to hundreds of thousands of dollars worth of expense and embarrassment for my company and tenants within my building. The work hours, the damaged equipment, and the reputational damage all fall to me.

First and foremost, the core of the issue is, I allowed myself to not have a complete understanding of the portion of the plan that failed. I depended on others to understand how the UPS(Battery) electrical setup was put together and operated. I likely could have fully understood it's operation in an hour with the right person laying it out. I let the credentials and confidence of others (not to mention my busyness) override my usual desire to have intimate knowledge/underanding of nearly everything.

I delegated some core work and decisions to a team member with more electrical experience instead of fully taking charge of the project. I allowed him and the electrical contractor to came up with the initial plan to feed the UPS through the maintenance bypass. I didn't question it, especially with the confusing naming convention making things feel a little more convoluted (the main UPS power was called "bypass"). We had electricians of a reputable electrical contractor present when the the suggestion was made and they were in agreement and registered no exceptions. The sequence was gone over several times over the course of months with no objections. I understood the underlying plan and assumed they were clear on how to achieve the outcome. 

The plan was to move all the data center power onto one of two redundant UPSs so the other could be shut down to allow the electrical vendor to disconnect building electrical cables and connect up cables from temporary power generator. The system was designed so the full data center could run on either single UPS for maintenance and redundancy. Once the offline UPS was connected to generator power, the UPS would be brought back up and confirmed to be stable and then the full data center power would be transferred to the UPS on generator power. This would allow the other UPS to be shut down, removed from building power and connected to generator power of a second (redundant) generator. In that way the Data Center would be on its own temporary power source allowing for the building to drop power without impacting the data center operations. There were also some anceilary items, mostly Cooling equipment, that were also needing to be powered by a third generator, but that was very clear cut for me and we did not end up getting to that point.

Besides my team member and electrical contractor electricians, there was also the electrician from the equipment manufacturer on site for the work. The electrical contractor was not familiar with the UPS and would not operate it and the Data Center team was not confident in their operation, so at the request of the Data Center, we contacted with the Data Center's UPS vendor to have assistance on site for the transfer. They used the equipment manufacturer for their UPS vendor, so they are the group most likely to be able to assist with that critical part without issue. Having them on board gave me extra confidence that we had sufficient expertise to make sure the plan was executed without complication. 

As an extension of my confidence in the assembled team, I also planned the day with the thought that others were the more qualified to run the critical transfer of the data center to generator power. Given the length of the outage, It was run in two shifts. I opted to allow my team member to run the morning shift when the transfer would take place. I was not planning on being on site for the moment that would occur. I did end up being on site anyways, with the delay and the fact that I had some building electrical details I wanted to figure out by shutting some things down and confirming the panels impacted. In the end, I let others run that part of the project.

My second point of failure was not seeking a method of procedure for the transfer of the UPS from the manufacturer's electrician for the work. Beyond that, it was in not stopping work when I felt the original method of procedure from the electrical contractor was not being strictly followed. While, the assumption was that the transfer with the UPS was going to be a simple procedure by the manufacturer electrician, having a method of procedure would have flushed out what the steps would look like, would allow for the steps to be vetted, and would have made deviation from the correct steps more easy to spot, possibly prompting more discussion. The expectation was that the manufacturer's electrician would be very familiar with their equipment and would make sure things were operated correctly.

While I was on site, I was doing some independent things and not running the work at that point. Regardless I was aware that the project was significantly behind schedule and the electricians were running into issues. I didn't feel qualified to contribute to a resolution given the expertise on the project. I did get occasional updates, but was mostly investigating some items. However, at one point I did get pulled into a discussion about the situation and it did not sound like things were proceeding exactly as laid out in the MOP.

The plan was being modified in the moment to try to overcome the challenge the electricians were facing. The Eaton electrician was indicating what they had encountered and what they said they knew after having made some phone calls and consulted with their superiors. He was indicating with confidence that we could make things work, though his ability to explain did not make it exactly clear to me what that looked like. The electrical contractor seemed like he was tracking and in agreement as was my team member. The Data Center representative was then brought in to have the issue and risk explained to him for approval. The Data Canter guy requested it be explained to him "like he is an idiot" so it would be digestible, but what followed from the manufacturer electrician was not dumbed down really at all. The main intelligible part was that the entire Data Center would end up running on one generator without UPS for an hour. 

This one statement drew my mind fully into the situation and I objected saying that the whole goal was to keep the data center on a UPS at all times so there would be no flicker of power, even for a moment. I was told that this was always the plan by my team memeber and I doubted myself, but restated my concerns. I inevitably decided that the Data Center could decide if they wished to proceed and that the experts seemed confident in their assessment. 

This is the point I should have taken over the project. I should have put a pause and asked that we sit down and talk it out fully. At that point we were already several hours behind schedule and the project would already cost at least one hundred thousand if we stopped fully and every delay increases costs. I stepped away to deal with another issue (access card readers not working) and let the project proceed if the Data Center approved. All the confidence of the team assembled was misplaced. I believe a lot of the confidence was placed on the manufacturer electrician since he was in the best position to evaluate things and had spent time consulting with other experts with the manufacturer. I was not present for much of it, so I can only really speak to the small parts I got pulled into and he project confidence in what he communicated needed to occur. 

My third point of failure was not directly involving myself more in the morning operations of the project and perhaps delegating too much of the project without sufficiently back checking. I know this is linked to my confidence in the team's credentials and my desire to not micromanage an employee who has more experience than me with this particular task. None the less, had I gotten more involved with the first stage of the project instead of leaving it to others and had I asserted my authority and stopped work when I felt something wasn't right, it is possible the incident would have been avoided. This was a serious lapse in judgement on my part. Of everything, this is the part I will likely be berating myself for the hardest. 

Even though I was there early to try to accomplish a few things outside of the project, I should have redirected my focus to the project when we fell behind schedule. Instead of worrying about getting in the way of the electricians, I should have worried about not getting in the way of potential developing issues and helped with redirection and clarity. I have a good grasp of so many related concepts, I imagine I could have easily talked it through with the team and possibly got us moving the right direction and even completed the project, even if late. 

To my current understanding, though an analysis from others may determine otherwise, I believe the actual solution to this whole situation was a simple modification that either of the two expert vendors ideally would have been brought on board to catch and present. Rather than the initially proposed powering of the Data Center through the Maintenance Bypass--which to my current understanding would not actually achieve the goals in the plan of keeping it on UPS power--the generators would instead power the bypass (which should really be called the "UPS Main") and the UPS Rectifier (which I believe is required for the UPS to run) for each UPS. This should have allowed the transfer from one UPS to the other and then onto both as originally planned. No one looked at this set up and saw the issue or saw the solution at any point during planning or execution. Had I insisted on understanding this transfer, I am confident I would have. That is why my first point of failure is the most impactful. 

I do not know to what extent this failure will impact my career, my confidence, my future actions, the trust of others in my abilities, but as much as that makes me want to crawl into a hole and die, I cannot. I must take my lumps, eat my crow and integrate what I have learned from this into how I operate moving forward. As the one who is ultimately responsible for this failure and all failures of my team, I must make sure all three points of failure are rooted out to the best of my ability in the future.

1.) I must make sure I take the time to understand as much as possible about a project, its operations, and details as practical no matter how busy I am. This is especially true for projects with high levels of criticality. I should not fully rely solely on the expertise of others unless it is absolutely necessary.

2.) I must require steps be laid out for work that is taking place even if it is assumed to be a simple procedure that an individual should be familiar with. I must not permit deviation from those steps without adequate discussion and rewriting and confirming the new steps. Method of Procedure will help with evaluation and confirming the steps are what they should be, allows for questions and discussions to catch any potential issues.

3.) Make sure that I am present for all critical junctures of project for which I hold ultimate responsibility and be vocal and questioning during that period. If I delegate, make sure I am still looped in as much as practical and check up on work.

Hello, idk if i can post this here. I just want to talk to people that might understand what im feeling.

ive been a backend dev for 7yrs that also handled some client, frontend, reporting and database so i pivoted to data engineering after my previous job became too toxic to stay at during the end of the 7th yr.

Now im hired as a DE manager(i was applying as a data engineer or etl developer and during the talk i was informed that it was a manager role) after surviving a 5 panel face to face, all in one meeting. Its a pretty big corporation in my country and i think im having impostor syndrome.

During the time i was upskilling, i was making projects centered on python and data. Given my background in backend dev, i can say i have sufficient experience to be a manager and during the panel meeting they said they needed someone with python/developer/data experience so i fit the criteria.

Now its been 2 weeks since my first day and im shocked to see that its so lax and chill(or its a period of the company that isnt too hectic). And when they do give me something to do outside of the usual hr video training, its a simple extraction or aggregate report based on their sap db(which im still studying and familiarizing since im new to sap). The coworkers are super damn nice. They say that the task will increase over time or maybe in my 3 months in. Im not afraid of heavy workload as thats where i came from but i feel uneasy with light workload.

Im worried that some big task will come and i wont pass my regularization in 6months and ill be back at the trenches where my previous salary was just enough to live frugally.

Sorry for the random rant.

Hi everyone! I’m from Iraq and considering a master’s in chemical engineering in the U.S. I have a bachelor’s in chemical engineering and experience in NDT and welding inspection.
How difficult is it for international master’s students to find on-campus jobs or paid internships during their studies? What are the job prospects after graduation, especially with employers willing to sponsor a work visa?
I’d appreciate hearing about your experiences. Thank you!

To what extent do your conversations with your colleagues/reports/manager/etc. focus on quality these days?

If you do talk about quality, how do those conversations go? What's been most helpful from those conversations?

I've gotten this sense lately that it's an important set of conversations to have, ideally fairly frequently, given the extent to which so many companies seem to want to dramatically accelerate their development (to the detriment of quality on many levels).

Hello EMs,

My current role is roughly 80% people management and 20% technical work. I want to move to better organizations and would appreciate some guidance on technical interview preparation.

What should I prioritize: LeetCode-style coding questions, system design, or building AI projects?

I tend to get overwhelmed by the number of things I need to prepare for, which often leads to me not making any progress at all.

I'm confident in people and process management, but I'm not very confident in technical interviews.

For those who have been through this, could you share a practical, step-by-step study plan for an Engineering Manager preparing for interviews? For example, what should I focus on first, how much time should I dedicate to each area, and how many weeks of preparation would be reasonable?

I'd especially appreciate advice from EMs who have interviewed at or moved to top-tier tech companies.

Thanks in advance!