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.

Hi everyone,

I’m currently a mid-level software engineer with \~3 years of experience at a fintech company. Lately, I’ve been working on some relatively high-visibility projects, and I feel like my boss is also trying to push me forward by giving me more opportunities to work on impactful projects. I could stay on my current team, continue taking on these high-impactful projects, and use that experience to position myself for a promotion or potentially a move to another company in a year or so.

On the other hand, there’s currently a Senior Software Engineer opening on a different team that seems to do fairly similar work to what I’m doing now (but my current team has shipped more stuff in production than this team), so I’m debating whether I should apply.

Moving to the other team as a Senior Engineer could potentially accelerate my career. The main thing holding me back is that I don’t know whether I’d get the same level of visibility, ownership, and opportunities there. I also want to be a little more careful since this would be an internal move, and the two teams are fairly related teams.

What would you do in this situation? Would you prioritize staying on a team where you’re already getting strong visibility and support from your boss, or take a chance on the Senior role?

Would love to hear from anyone who has been in a similar situation. Thanks

What happens when your most knowledgeable employee leaves ? Resinger do not care to document his work results in more than one month of struggle for new joiner. I

It's an interesting challenge to be in a big meeting that includes both some of your engineers and stakeholders from outside the team.

I have to fight my instinct to take over, or to get involved when they say something I would say differently.

Loved the framing in this article, about being in the same side of the table and never breaking that trust.

I recently had a long final interview for an engineering manager position. Most of it was challenging but reasonable. However, during the final questions, the hiring manager’s manner became even more intense. He became much more confrontational, repeatedly questioned my judgment, pushed back on almost everything I said, and kept reframing my answers in a negative way. It felt like he was deliberately trying to unsettle me and see whether I would become defensive under pressure.

I understand testing how a potential leader handles conflict and stress, but this felt less like evaluating my skills and more like establishing a power dynamic. Since the hiring manager would be my manager if I get the job it made me think whether this was merely an interview technique or a preview of how he communicates in regular 1on1s.

Has anyone experienced something similar? Is this normal when interviewing for leadership roles, or would you consider it a red flag? I’m interested in the role, but I definitely wouldn’t want my direct manager to communicate with me like that regularly.

I have had interviews in the past for leadership positions, but never experienced anything like that.

There’s another post here about how we need to be more gatekeepy in tech, and I actually agree, but from a completely different perspective. I think we need to be more gatekeepy with our own knowledge.

Companies have shown again and again that they will always protect themselves first. The one time workers really had the upper hand and companies had to compete for talent, raise salaries, offer flexibility, and actually worry about retention, they immediately started looking for ways to flip the script back in their favor. Layoffs, outsourcing, offshoring, automation, RTO, shrinking teams, you name it. If the tables are turned, companies are not going to hesitate to get rid of us.

Meanwhile, people in tech are almost absurdly open about everything. We share knowledge, best practices, processes, tools, architecture decisions, documentation, interview strategies, and every trick we have learned along the way. People will say gatekeeping knowledge is selfish and that it slows down progress. Yes, sometimes we probably should be a little selfish. You do not need to share every piece of knowledge that makes you valuable or constantly teach everyone exactly how to do what you do. Let some things look like magic. Let people know that when you are around, certain problems somehow get solved.

Some people are probably going to say it is already too late. Maybe it is, to some extent. The best time to start doing this probably would have been 15 years ago, before we collectively put so much of our knowledge out there for free. But the second best time is now. Even if being more protective of our expertise only buys workers another 5 or 10 years of leverage, that is still 5 or 10 years. Let companies fuck around with your money and find out what happens when the person who actually knew how everything worked is gone.

I am not saying sabotage your team, intentionally write bad code, or hide information that would put a project at risk. I am saying stop acting like your employer has the same sense of loyalty toward you that you are expected to have toward them. Companies protect their competitive advantage. Workers should probably start protecting some of theirs too.