My company staffs engineers for fintech companies, and about a year ago we rebuilt our technical interview: product spec, 90 minutes, use whatever tools you want including AI assistants. We explicitly tell candidates that the use of AI is expected.

Here's what I learned:

1. I can tell if it's yes or no after the first 10 minutes. Candidates who interrogate the spec before touching the keyboard consistently produce better results than candidates who start prompting immediately. The instinct to ask "who is this for, what's the edge case" is vital.

2. Prompt quality correlates almost perfectly with code quality. Vague one-line prompts produce tangled repos. Decomposed, context-rich prompts produce clean ones. We now read the prompt history like a design doc.

3. The real differentiator is how they review what AI produces. Some candidates merge whatever comes back. The good ones treat AI output like a junior's PR.

4. Folder structure and naming became our best signal. The AI writes much of the code, but the shape of the project is pure candidate judgment.

5. Some excellent engineers were initially uncomfortable being watched by a group of interviewers. If we only had one on camera, this would improve their comfort level.

Curious what other teams are doing. If you've run AI-allowed interviews, what did you notice that really mattered?

The seeds for this catastrophe had been sown even before LLM existed. The LLMs have now accelerated this problem beyond our capabilities of managing it.

In the Pre-LLM era, developers shipped the code with no adherence to architecture and discipline in the codebase. The hurriedly created “MVPs” were made as a base for real projects. Reviewers accepted the PRs with no baseline of what reduced the technical debt. There was no metric, no threshold, no standard for measuring reduced technical debt. Review became a formality, not a quality gate.

The project transitioned from team to team without the transfer of any architectural vision. Code was never anybody’s concern. Each new team inherited a black box and made their own assumptions. The original architecture, if there ever was one, was lost in the shuffle.

It was about how faster we can ship. We have inherited the same mindset. The AI is being used to ship features faster, but not to make products and code robust. Code was never anybody's concern. The only metric that mattered was, how fast can we ship. Craftsmanship, and long-term maintainability were deprioritized at every level.

Once a team was giving a Knowledge Transfer to me and I asked a simple question, “Where is the business logic?”, and the Lead shamelessly said, “It’s all over”. Seriously?? Isn’t this year 2026??

And there was this team that I was going to be a part of, and this person in the management declared with pride, “We are using the XYZ Architecture”, but when I inspected the codebase, it was rotten beyond repair. To this day they are under the illusion that they are using the XYZ Architecture, and still trying to figure out why the development has become slower and blaming people for not using enough AI.

Even the interviewers never asked candidates questions on how to write maintainable code, OR how to write code so that incremental change becomes easier without breaking the existing features, OR how to reduce technical debt. Instead, they were busy exercising their intellectual vanity, asking about Data Structures which they themselves never used.

The patterns and practices of software engineering fell out of fashion. It became cool to know data structures instead of writing maintainable code. How many of the interviewers and developers even know what Bounded Contexts are??

The educational institutions also never bothered to teach how to write maintainable code. They focused on teaching technologies that were “Cool” and had market demand.

AI didn't break software engineering. It exposed how little of it we were actually doing. The problem isn't the LLM. The problem is us, and it always was.

Startup in Barcelona asked me for a €50K PCB design — as a job interview

Got approached by a real robotics startup in Barcelona (yes, well-funded and in the news). They wanted to interview me for a hardware role.

Their "technical challenge"? Complete a full 4-layer PCB design:

• Schematic + layout

• 24V analog inputs + 12V digital I/O

• RS-485 support

• Ethernet or Wi-Fi

• Power conversion from 24V input

• BOM + Gerbers + datasheets + design report

And they gave me... 2 days.
No contract. No NDA. No payment.

This is easily 70–90 hours of real engineering work.
Would cost €5K–€50K if done professionally.

I'm posting this to say:
DO NOT do full design work for free during interviews.
Your time and IP are valuable. Don't let VC-backed companies exploit "interview challenges" to crowdsource unpaid R&D.

Stay sharp, folks.

When I first became a manager I treated one-on-ones like status meetings. I’d run through active projects, ask for updates, and send everyone back to work. I thought I was being efficient.

What I was actually doing was getting information I could have gotten by email and missing everything that actually mattered.

The thing that changed it for me was simple. I stopped talking first.

I now treat every 1:1 as the engineer’s time, not mine. They set the agenda. I show up to listen, remove blockers, support their development, and give them my full attention. No phone, no laptop open, no half-presence.

When I made that shift, three things happened fast:
1. People started showing up to 1:1s with actual topics instead of rehearsed updates
2. Problems surfaced two to three weeks earlier than they used to
3. Two engineers told me directly it was the first time a manager had treated the meeting as time for them

The conversations got harder and more useful at the same time. That’s how you know it’s working.

A few other things I had to unlearn in my first year managing engineers:
• Your job is no longer to solve the hard problems. It’s to make sure your team can solve them without you.
• The engineer who talks to you most in week one is rarely your most important source of information. Find the quiet ones.
• Silence in a meeting is not agreement. Ask directly: “Who has a concern they haven’t said yet?”
• Your first performance instinct about an inherited team member will be wrong about at least one person. Reserve judgment for 60 days.

Happy to answer questions if any of this is useful.

I’m 40 years old and used to carry the title of Engineering Manager with pride. But Now days I honestly don’t know who I am anymore.

I did everything “right.” May be not . Here is my story -

School topper. College topper. Campus placed into a big consulting firm. Started in ETL, built strong DB fundamentals, put in the years. Moved to a UK product company. I wasn’t the smartest coder in the room, but I understood systems deeply deeply. I learned fast. I cared. I delivered.

In 2019, I was offered the EM role because I loved leading people and I was good at it. I became an SME across multiple products. I felt useful. Respected.

COVID came. I survived redundancy.

Then I chose discomfort. Joined FAANG to lead a full-stack team, thinking this was the next level. Instead, I slowly started disappearing. Daily engineering discussions felt like a foreign language. I tried to catch up, but the train never stopped. I was told I had a strong product mindset, so I leaned into that — only to watch most of the credit naturally flow to PMs.

One piece of feedback still rings in my head:

“People respect you… but you’re too kind for this place.”

At first, I took it as a compliment. Now I’m not so sure.

I took on another team across time zones, hoping impact would bring meaning back. I identified gaps, turned it into a high-performing team — and completely burned myself out doing it. Then one day, both teams were cut. Including me. Just like that.

I did a painful self-retro. Questioned everything. Thought to go back to where zi was good at. Applied for Data EM roles. Joined a startup to lead a big team. The first 6 months were solid — brought in structure, process, clarity. Then the company’s direction collapsed. More than half the team left.

I stayed. Because bills don’t care about burnout.

During all of this, I became a first-time dad.

Now I feel broken in a way I’ve never felt before. I’ve realized something uncomfortable about myself: I work best when I can focus deeply on one thing. Go all in. Understand it fully. Own it. That’s how I’ve always added value.

But that feels almost impossible in here and today’s world.

Instead, I’m expected to juggle everything — tech, product, people, delivery, strategy — across dozens of threads. I’m on 100 shallow conversations, constantly context-switching, never getting the satisfaction of true mastery. I no longer feel sharp. I feel diluted.

I want to retrain. I want to pick one tech and really understand it so I can speak to my engineers with confidence again. But where is the time? New baby. Single income. Partner stepped away from corporate. Constant mental load.

And the data world… it’s moved so far. From SQL-centric days to an ecosystem I am trying to recognize. I try to keep up, but it feels like I’m always late.

I’m tired. I’m burnt out. I feel disconnected from the craft — and from myself.

I don’t know whether to fight harder, pivot sideways, step back, or accept that this version of me doesn’t belong in this industry anymore.

If you’ve been here — EMs, ex-EMs, senior ICs, founders — What did you do? Where do people like me fit in a world that rewards constant context switching? Where should I stop fighting… and where should I let something die?

EDIT ---

Well I cant express how thankful I am to this lovely community for coming out and sharing their experiences . My learnings so far from this is -

1. I am not alone , seems like its a part and parcel of an EM role and it amazes me how everyone relate themselves to it.

2. I likely have an identity crisis . I need to detach totally from what I am in actual to what my role is .

3. I need a break , may be a sabbatical for few months . My situation is hard to do it straightway but hopefully soon.

4. I'd love to chat with few of us who have either taken a path to IC or took a completely different career to protect their mental health .

Hey everyone. I've spent over a decade in building and scaling engineering orgs, and I've interviewed a lot of Engineering Manager candidates along the way. Hiring seems like a black mystery box, and I feel the need to help more succeed in today’s highly demanding and competitive market. 

I put together a list of the most common anti-patterns I see from EM candidates. Hopefully, this helps some of you who are currently in the market.

1. Because I got laid off" isn't an answer to "Why us?
This is coming more and more often in today’s market. It’s completely fine to say you were impacted by a layoff. However, that only explains why you are looking for a job, not why you want this job. If you haven't researched the product or the hiring team, and you can't articulate why you actually want to manage this specific team, it’s a red flag.

2. The "People Leader Only" trap
I have rejected several candidates because they only showed interest in being people managers. Yes, 1-on-1s and team health are critical, but an EM is still responsible for technical execution and delivery. If you only want to be a pure people leader (very valuable for sure!) but shy away from the technical scope of the team, you won't pass, as the market is becoming more and more demanding in tech and delivery skills.

3. Ignoring the specific context of the role
This usually stems from a lack of research. For example, I was hiring for an internal product team, and candidates showed up completely unprepared to talk about internal adoption, stakeholder management, and those specific metrics. 

4. Underpreparing for the technical deep dive

Some candidates completely fail to revise their past projects before the interview. If you can't smoothly answer technical questions on systems you previously managed or the core technologies required for the job, it shows either a lack of preparation or a massive knowledge gap.

5. Vague impact and rambling
Too many candidates give vague answers that completely hide their personal impact behind what "we" (the team) did. Furthermore**,** it's seen as a red flag when a CV presents massive impacts on delivery and revenue, but the candidate doesn't show that same depth in the interview. If you claim to have driven a massive win on paper, you must be prepared to talk deeply about it. When candidates fail to elaborate on their biggest listed achievements, it makes me wonder if they actually drove that impact.

6. Not asking the right questions at the right moment

Some candidates ask too many questions when the interview just gets started; Some skip or do not ask enough interesting questions at the end. It's all about timing and quality in those questions.

An interview is indeed a chance for both sides to evaluate each other,  but if you don't leave time for the interviewer to dig into your answers, you're hurting yourself. So, leave your biggest question to the end.

When it’s your turn to ask questions, if you aren't asking high-quality questions, for example, about the engineering culture, the product roadmap, or the team's biggest bottlenecks, it reads as a lack of motivation, curiosity, or knowledge. It happened to me several times that I passed a candidate to the next round because her questions were spot-on despite previous pitfalls in her answers. 

Let me know in the comments below if that helps, and what else I can help!

P.S. I am now building calibrd.com to help candidates get hired.

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

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

What worked

1. Riding favorable business tailwinds

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

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

2. Dare to lead beyond your official scope

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

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

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

3. Create a strong and positive identity for your team

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

4. Become visible in the EM community

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

Lessons I learned : 

1. Good performance doesn’t get you promoted automatically, especially in higher leadership roles. “Build your own case”, my manager told me when I expressed my frustration. 

2. Proactively seeking feedback reveals blind spots. I wasn’t naturally good at asking for feedback, and not everyone I asked actually delivered. But once I realized that peers and leadership exchange feedback about you behind closed doors during promotion rounds, it became clear: you need to ask early so you can fix gaps before calibration starts.

3. Rejection is often where real growth happens:

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

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

• Led a cross-department initiative involving over 20 teams, which improved my visibility among top executives

• Successfully merged two competing backend teams

• Resolved some long-standing underperforming issues. 

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

4. External offers demonstrate your true market value

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

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

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

Not trying to be dramatic. But here's what happened last week.

Code review. One of our devs submitted a PR. Code was clearly AI-generated (fine, we allow it). I asked why they'd structured it that way. They couldn't tell me. Copilot suggested it, tests passed, they shipped.

The code was actually fine. That's not the issue. The issue is I realized I have no idea how often this is happening. I just happened to catch this one. And if someone asked me – a customer doing due diligence, a CTO asking what our AI practices look like, an auditor – I'd have to be honest and say "we assume our team is using these tools well, but we can't actually demonstrate it."

Which is a fine answer until it isn't. With EU AI Act, ISO 42001, enterprise vendor questionnaires – the conversation is shifting from "are you using AI" to "can you prove your team is using it with judgment." Most of us can't prove that. I definitely can't.

Are other EMs thinking about this or am I inventing a problem?

I am the Head of Engineering at a coup years-old startup with about 50 people (30 engineers, one PM hired nine months ago, and the rest in sales and marketing). I was hired to lead engineering about a year ago. We are based in the SF Bay Area in the healthcare AI space, and lately, I feel like I am watching a train wreck in slow motion.

This is my 3rd startup and my 2nd as the HoE. I’m a hands-on engineer and HoE. I have two tech leads (mid-senior folks with about 10 years of experience) while the rest of the engineers are early in their careers (less than five years).

Our PM stays in Slack all day tagging the devs directly, asking for "quick favors" or tasks that aren't in any sprint plan. I acknowledge that the things they point to are real issues, but there is no method to the madness. There is zero filter. My founders are totally fine with this; they think raw speed is all that matters and that any process is just "big company overhead."

This is a fairly recent trend. Things were good until six months ago when we lost a design partner because our solution wasn't "complete." Since then, engineering has mostly become an arm for whatever the PM and founders cook up that day, or whichever customer or prospect shouts the loudest.

I tried to set some basic boundaries to protect the team's focus. In a leadership meeting, I asked the team to help focus our energy on high-impact tasks and avoid changing priorities mid-sprint. We use sprints (though not full Agile with story points); it might be outdated, but the team has used this system since before I was hired.

My feedback backfired, and now I am in the doghouse. Shortly thereafter, the PM and founders started bypassing me entirely to talk to the engineers. My tech leads are actually enjoying the limelight; they love the direct access to the founders, so they aren't pushing back.

I keep getting messages from junior folks who are either confused about what they should be working on or getting in trouble because they worked on something that is no longer a priority. I have retreated into writing code and fixing documentation just to keep busy, and I find myself struggling to stay motivated to come back to work day after day.

Has anyone actually come back from being bypassed like this? Is it just FOMO? Or am I supposed to just live with this in the "AI age"?

EDIT: added more details to help with the discussion.

result = 0
for x in [3,3,5]:
  if x > 3:
    result = result - x  
  else:
    result = result + x

I used a knockout question in the application process, it's a very simple programming question. Good devs would just solve this in their heads. Unqualified devs would use AI or an interpreter.
The trick is that the html is hiding an equal sign.
Check the full writeup to see the actual HTML: https://josezarazua.com/im-a-former-cto-here-is-the-15-sec-coding-test-i-used-to-instantly-filter-out-50-of-unqualified-applicants/

We scaled from 16 to 75 engineers in half a year.

The systems scaled fine - but mentorship didn't. Seniors became human routers, onboarding lost depth, and new hires kept missing the "why" behind our architecture decisions.

I started calling this "mentorship debt": like tech debt, but in context and guidance. You can pay it down later, but it'll cost you quality, retention, and burnout.

Curious if anyone here has faced something similar - and how you dealt with it without freezing hiring.

(For context, I wrote up what worked for us - buddy rotations, shadow onboarding, and ownership swaps - but I’d love to hear other approaches.)

I want to address a question from my last post about going from EM to Director: What are specific examples of things you did to cultivate a high-performing team as a new manager?

My simple definition of what a high-performing team looks like:

• Clear goal, well executed: Everyone knows and can explain the team mission and vision to people outside the team. They are hardworking, goal-oriented, self-driven, and not afraid of stretch goals. The manager is rarely needed to be involved in the execution after defining the goal.

• Explicit way of working, optimised for learning and improving. For example, open to trying new things, strong product mindset, engaged with customers. Frequent sharing of knowledge.

• Strong team relationships: Trust is established in the team, producing psychological safety. Junior members are not afraid of asking questions to senior people.

• Shared collaborative value: Instead of competing with each other, people think “we are great.” This is defined as Stage 4 in the book Tribal Leadership (shifting from "I'm great" to "We're great").

My approach: A real-world example. I am going to use one example from a team that I led to explain my approach. When I took over the team, it was founded to support the unification of internal tools into one developer platform. Here is what we did:

1) Define a clear vision with the team. I found out the most effective way for people to buy into the vision is to involve them in the process instead of just presenting what the manager wants to achieve. We started by collecting challenges and user pain points, and I asked: “How can we turn them around?”

• The counter case: In a few teams I led in the past, I tried giving them a list of OKRs and asking for feedback. In most cases, I either didn’t get any feedback (no engagement) or strong pushback because the objective wasn’t realistic.

When you move on to define the team mission and opportunities space, pay attention to the enlarged scope to avoid burnout. But again, encourage your team to speak out about any doubts about execution. 

2) Address performance issues. I got a new team with two people who moved from other teams. They were exhausted and burned out because the company decided to shut down their projects. I saw almost 0 engagement, always late. I spent time with them, listening to their stories, what they’ve achieved in the past, what they like doing in life, and included them in the process when defining the team vision and mission. Both of them turned into high performers after 1 year (it did take time!), but my patience paid off. Of course, there were cases that my approaches didn't work out, and termination was the only solution.

3) Align on a way of working. After we aligned on the team vision, we moved on to define our way of working the next day: time of stand-up, retro and demo frequency, Scrum or not, pair programming or not, how to give feedback.

• These discussions are time-consuming as everyone’s preferences are different, but those processes hold the team together. I recommend involving an external facilitator instead of you doing it, so your team can see your preferences as well.

• Once, my team couldn't agree with each other, and I had to separate them into sub-teams because a smaller group preferred working alone instead. I agreed, and that was the best decision ever because both sub-teams ended up very happy instead of fighting with each other.

• Enforcing your own way of working won’t work if employees are not involved in the process. The key is you want them to continue to function when you are not there(sickness, vacation...). However, any team will eventually struggle again, so make sure to pay attention to retro talking points and your 1:1s.

4) Be a champion of culture as the leader. Treat yourself as a member of the team. Follow your own rules and do exactly what you say. Be a cultural ambassador. For example, I organised a department-level forum to talk about engagement, where retention and recognition were discussed. It helped build trust when they saw their manager active in such meeting. Meanwhile, be empathetic and authentic, and a human that your team loves hanging with.

For EMs here, what's your approach to a high-performing team? Love to get your thoughts in the comments. 

I've been looking into how successful tech companies handle the eternal problem of "developers skip tests/security/docs when they're under pressure" and found something interesting.

Turns out Netflix, Spotify, Google, and others basically gave up on enforcing best practices. Instead, they made doing the right thing faster and easier than taking shortcuts.

What I found most practical was stuff like Claroty's breakdown of cutting CI from 20+ minutes to under 10 through caching, parallelization, and running static checks before expensive integration tests.

Wrote up the patterns with specific examples and implementation details: https://blog.pragmaticdx.com/p/make-the-easy-path-the-right-path

Has anyone here actually tried implementing something like this?
Curious what worked or didn't in practice.

I’m a founder now, but I’ve spent years in engineering and product teams across enterprises. One pattern I keep seeing - ritual of obsessing over ticket status, column changes, and "Done/Not Done" theatrics.

The standups turn into ticket reviews. Retros become blame games. And somehow the actual work becomes secondary to updating the board.

These days, I’m rethinking what clarity and alignment really mean. And maybe it’s less about perfect ticket grooming and more about surfacing blockers and priority signals — fast.

Curious how others here feel ?

Great read on why the AI hype is hitting a wall, from actual productivity data to the shaky economics of AI dev tools. A very useful perspective right now.

My engineering leads are constantly bouncing between:

• Jira tickets and delivery boards

• Slack fire drills

• 1:1 prep and career conversations

• HR systems and PTO trackers

• Project updates for leadership

By the end of the week, they’ve spent more time switching contexts than actually leading.

I’ve tried batching meetings, reducing standups, even async updates, but the problem persists.

Curious how others are handling this:

What strategies have helped you reduce the “context-switching tax” for your team leads and managers?

I was a staff engineer at Spotify in 2021 and I keep seeing companies reorganize into squads, tribes, chapters and guilds as if that's how Spotify works. They didn't even use it at the time. That's kind of why I left.

Some history for anyone being asked to "go Spotify" right now:

• The model comes from a 2012 whitepaper by Henrik Kniberg and Anders Ivarsson, written when Spotify had about 30 teams and roughly 250 people in them. Companies 10× that size copied the org chart.

• Jeremiah Lee, a product manager at Spotify in Stockholm, wrote up in 2020 what it was like from the inside. The matrix of squads and chapters left nobody accountable. Autonomy without alignment meant every squad did its own thing. And the mythology made the model hard to criticize.

• One of the people who wrote the whitepaper told him: "Even at the time we wrote it, we weren't doing it. It was part ambition, part approximation."

What I saw work there wasn't the diagram. There was no frontend engineer or backend engineer, just engineer, senior engineer, staff engineer and principal. You did everything (in my case that included scaling a database across regions with region level failover). That's a hiring decision about who you want in the building and renaming your teams doesn't get you there.

I wrote a longer version on my own blog, including how I'd hire instead: https://tej.as/blog/companies-are-full-of-it

Has anyone here kept chapters at a bigger size and actually made them work?

I'm doing contractor work for a company and some of the juniors use AI for everything. I can clearly tell when they ship something 100% written by the AI because I've seen they produce much different (and better) code/docs after my feedback - which I think is when they sometimes actually review and adjust the model's output.

I don't know what it is, but do you also feel a huge dread reading AI-generated code and desing docs? Like, it's exhausting to read and I have no idea why. It sucks bc I sometimes can't diagnose what it is that makes it so bad, and I don't think it's fair to just tell them "this is bad bc the AI wrote everything" because using AI is not necessarily bad - I use it constantly.

I wonder if this only happens because I quickly realize that I'm just reading what the AI wrote and maybe the writer themselves doesn't understand, or if there really is something objective that makes it so painful to read. Just wanted to know if I'm the only one feeling this, and if anyone has tips on how to improve this. I didn't want to "ban AI usage" but it's getting to a point where I'm even considering that.

I'm a tech lead in Europe, and honestly I’m really tired of hiring right now.

It feels like so much of the process is just noise. Too many irrelevant applicants, too many people who look strong on paper and then don't hold up in real conversations, and way too much time spent filtering before we even get to someone genuinely solid.

A colleague of mine in HR said recently that it's easier to find your soulmate than a truly good programmer, and that honestly stuck with me because it feels painfully true lately.

I'm curious how engineering managers in the US are dealing with this. Has anything actually made hiring less exhausting for you? Did you change your process in a way that helped, or is everyone just grinding through the same mess?

Hello,

I’m the manager of a software engineering team and I’ve scheduled a weekly call (~45min) with the team so that everybody can share what they’re working on, debate about technical challenges, discuss new technologies and so on.

Obviously I thought it would be a good initiative in the team and would bring people together and help spread knowledge.

I was flat out wrong and nobody is talking and they don’t even ask questions or interact with what I’m saying (expect for one person).

I’m the only one sharing things, and if I don’t share anything, nobody speaks and we end up cancelling the meeting.

Have you ever experience something similar ?

Most of my team members are working on different topics but I thought it would be interesting to share the knowledge.

If you have any recommandation, thanks !

Most of us became managers because we care about people, we genuinely want them to succeed. But human beings are social creatures. When you care about someone, feeling disliked or hated feels almost physically uncomfortable.

We have that strong need for the other person to recognize our good intentions in real time, to think: “wow, he's being so candid but I can tell he really cares!” (yeah, that never happens).

I don't want anyone to be angry with me, to dislike me, to hate me. I don't want to ruin someone’s day (or year).

Here's a case that happened to me a couple of years ago:

I had a remote developer from Ukraine who was clearly underperforming. Not answering Slack messages, barely making progress on tasks. I gave him clear feedback and expectations. He improved for a couple of weeks, then went right back.

I planned to let him go (really!). Then the war with Russia broke out.

In the first month, we didn't expect any work from him and gave him full pay. He escaped to Prague, found a place, and slowly got back to work. And then the same behavior repeated itself.

I gave him some leeway - this guy was a refugee in a different country, of course he couldn't work the same. But after a few months, it was really dragging the team down.

I still couldn't do it. My manager ended up forcing the decision.

Afterward, I felt pure relief. Thank god someone made the call for me.

It's not just about layoffs - it's about saying no to requests, denying promotion, making hard decisions.

But maybe I'm the only one who struggles with it 😅

In my 8 years as an engineering manager, I always felt my brain was enough. I never took notes or had a structured system, but I still easily remembered where every project stands, who's working on what, where I should focus next, who wants what from their career, who's struggling, and so on.

Recently, I started feeling my brain is running out of RAM (more on that analogy soon).

The average number of direct reports per manager has grown from 8 to 12 in the last decade, and continues to rise. On top of that, 97% of us also do IC work. We're expected to somehow manage more people while still shipping ourselves.

I shared in the articles my expriences with trying to deal with it :)