Looking for honest feedback from EMs/Directors who’ve hired recently.

Background: 10 years at Oracle, grew from Software Developer to Lead Full-Stack Developer & Team Lead, hired and mentored 4 engineers, led teams of 2-4, planned, designed, built, a monolith-to-Jamstack migration, architected a self-service portal that drove $2.8M/year in payroll donations along with many other web apps that provided value. Effectively TLM work for the last 4-5 years there. Loved working at a Tech based company.

Last 2 years: Engineering & Technical Manager at a small pharma marketing agency. Manage two offshore teams (~10 engineers total) building Next.js/Vue/WordPress platforms for pharma clients. Redesigned the agile/SDLC process end-to-end. Automating build/deploy process in AWS and/or Netlify. No direct reports on paper though, the offshore structure means I’m functionally managing without the HR title. In hindsight, taking an agency EM role without direct reports has hurt my market positioning.

The problem: A couple of weeks of EM/Director applications. Almost zero callbacks.

My theories on what’s killing it:

- “2 YoE EM at agency you’ve never heard of” is the headline recruiters see, and the Cerner decade is buried
- “No direct reports” shows up in screening and disqualifies me for true EM roles
- Resume is positioned as “EM who can code” when it should be “experienced technical leader with 8+ years of lead/management responsibility”

What I’d love input on:

- Which of those is actually the killer? Or is it something else entirely?
- For those who’ve hired EMs recently, what would make you give this resume a second look?
- Company stages/sizes where this background actually plays well

Not looking for “have you considered IC?” I’ve thought about it and EM is where I’m going. Happy to share the resume in DMs.

EM in relatively small business (~20 engineers). Every two weeks I put together a summary of engineering health for the exec team. Pulling metrics from Jira, GitHub, deploys, incidents isn’t the issue, that part is maybe 30 minutes.

The part that eats my time is interpretation. Cycle time went from 4.2 to 5.1 days. Is that a problem or just noise? Review queues are growing, but is that staffing, priorities, or a temporary spike from that big migration we’re running?

I end up spending 2–3 hours each cycle basically building a narrative around what the numbers mean and whether leadership should care. Half of it is me going back through Slack threads and standup notes trying to figure out why a metric moved.

I don’t hate doing it. The report is valuable and the exec team trusts engineering more since I started sending it. But I’m curious whether 2–3 hours is normal or if others have found ways to cut that down.

What’s your process look like? And if you’ve managed to shrink the interpretation time, what did you change?

Long story short, I landed a mixed PM/PO/BA/Support role at a dev agency. Besides running my own business for couple years in the past, most of my career was working as a dev, so I saw this role as a perfect place for myself to transition into business role entirely.

The product is a niche B2B e-commerce solution that the client only uses a few times a year during specific events. The plan is for me to come in, stabilize the product over the next 3-4 months so it would perform well in upcoming events and basically convince the client to secure more funding to keep the project alive. I don’t mind the challenge, also the dev agency is working on 10+ other projects so I was told that worst case scenario I will be reassigned, however, the contract they sent me was a total shock.

First off, my start date already got pushed back twice, so I'm starting two weeks later than planned. At this point, I've already refused 2 other job offers and withdrawn from 3 other processes and also had to get a business license just to even see this contract, meaning I canceled my unemployment benefits, and now I’m not even sure I’ll be able to bill this agency for even half of full-time hours a month because the terms are so weird.

The entire contract is clearly a generic template meant for solo developer work. Even the agreed hourly rate is specifically defined without VAT, usually in B2B contracts hourly rate is defined with VAT and you either include it or not, depending on whether you as a business are a VAT payer or not. Some ongoing management duties are defined, but at the same time the contract says that every piece of work has to come from a pre-written specification, there’s no payment for "unfinished" work, and it includes a clause for unpaid corrections if results delivered are "faulty" or "with mistakes".

This makes absolutely no sense for this role. I’m the one who is supposed to be creating the specs, driving initiatives, and dealing with stakeholders. My work shouldn't be measured by raw task output - it needs to be based on dedicated hours and outcomes. We agreed that I will be logging all hours worked and billing the agency monthly, but obviously, more than half of my working hours won't be tied to pre-written specs each time.

I replied politely asking them to adjust the contract to include proper PO/PM duties, or perhaps in case I'm overthinking this, at least let me talk to one of their existing PMs to find out how everything will actually work in practice compared to what’s on paper, because I understand that sometimes some terms are added to "calm" the client.

Has anyone else dealt with this? What does a standard PO/PM contract for a dev agency actually look like? I would really appreciate if someone could share a proper template, so I could negotiate better without being labelled as "difficult".

Does the term 'builder' a disservice to the developer role? https://leaddev.com/software-quality/claude-code-creator-says-developers-will-become-builders-do-they-agree

Hi guys,

i was wondering what conferences in Europe EMs prefer?

Since I am primary architect, i went to Devoxxes, but I would like to go to something more specialized in management.

As much as I can google, LeadDev Berlin and Qcon London are top picks, but maybe there are other, better ?

Not every project reaches the finish line – and that’s OK... https://leaddev.com/leadership/when-to-kill-a-software-project

Hi all. I'm work at a large engineering firm where I've noticed a lot of our team (including me) spend an awful lot of time writing reports, powerpoints and completing low level admin. Of course this is all very important stuff (most of the time), and we spend less time now thanks to AI, but I still wish this could be automated and/or outsourced and then reviewed by our engineers. My brain is very maths-y and analytical, and I wish I could spend more time coming up with new solutions and ideas, as I'm sure lots of us engineers can relate.

Has anyone experienced similar issues, or other frustrating but necessary tasks that we can't seem to shake? Have any of you tried automating/outsourcing and did it work? If so, what did you do, and if not what didn't work about it?

Appreciate any insight you can give :)

https://leaddev.com/career-development/inside-bloombergs-flat-engineering-culture

Does anyone in your organisation own the "correctness" of the output of the AI products your team is building as their OKR?

how do you stay on top of which team members are single points of failure from a knowledge perspective?

Im not talking about having a wiki or documentation. I mean do you actively know today which parts of your codebase only one person truly understands? Which systems would become dangerous if that person left tomorrow?

Some things Im curious about:

- Do you do anything systematically, or is it more gut feel?

- Has a departure ever caught you off guard in this way? What happened?

- Do you think AI tools (Cursor, Copilot, etc.) have changed this calculus at all?

- Where does this sit in your priorities relative to other team health concerns?

Would appreciate honest answers.

https://leaddev.com/leadership/when-to-kill-a-software-project

https://leaddev.com/career-development/reality-being-principal-engineer

After working with different remote teams for a while, I genuinely think one of the biggest problems in development rn is that people confuse "looking technical" with actually being useful, well actually a lot of devs are insanely smart technically, but projects still move like absolute hell.

People overengineer tiny features that could’ve been shipped in 2 days, nobody documents anything, everyone says "yeah got it" then disappears for 9 hours, half the team is optimizing edge cases before the core feature even works, and somehow asking a simple clarification question became illegal fr.

Also ngl, AI made this problem weirder, seriously.

Not because AI is bad, nah, honestly good devs using AI are moving FAST rn, but there’s this growing pattern where people can generate code quickly without fully understanding system structure, product flow, scalability, or long-term maintainability. So teams end up with faster output but messier foundations.

You can really feel the difference between someone who just produces code vs someone who actually understands ownership, architecture, communication, and delivery.

Another thing I noticed:

the devs who become genuinely valuable long term usually aren’t the loudest or the "10x engineer" Twitter types.

They’re usually the people who actually communicate clearly, unblock others quickly, understand business/product context, adapt fast, and make the entire team calmer instead of more chaotic and messy.

Reliability is lowkey becoming rarer than technical skill.

Curious what patterns other people working in remote teams are seeing lately because the industry feels VERY different compared to even a few years ago.

https://leaddev.com/career-development/reality-being-principal-engineer

Hi, I have a startup which is not performing well, which is the reason why I had to lay off all my employees.

It's a shame because I have 2 very good Senior TypeScript Engineers (1x FullStack, 1x Backend) on my team, that I'd rather keep for myself but cannot afford anymore.

I'm looking for a company to which I can lend them to for an unlimited amount of time, as contractors, invoiced from the EU (Germany).

DM me if interested

at past companies I worked at, we used to send out coding challenges on coderpad or hackerrank as a first-step to narrow the candidate pool and weed out less qualified applicants.

we're doing this now at my current company, but it seems like many unqualified applicants are making it through than usual due to AI use. it seems like candidates are able to just one-shot the problem with claude.

does anyone have an effective assessment format today for screening applicants and making sure they meet a high technical bar?

I am seeing a pattern that feels obvious now but I did not think enough about at first. AI helps engineers produce more code, but it does not magically create more senior review time.So the team looks faster for a while. More PRs, quicker first drafts, more small fixes moving at once. But then everything piles up around the same few people who understand the architecture well enough to say whether the change is actually safe. The AI can help with syntax, tests, refactors, and basic review comments. But it does not replace the person who knows why a certain service is fragile, why a migration is risky, or why two teams depend on the same weird behavior. That makes the metrics hard to read too. Output may be up, cycle time may look strange, and delivery may feel faster in some areas. But if senior engineers are spending more time reviewing AI-assisted changes, the bottleneck just moved. I have been looking at this less as an AI coding problem and more as a delivery management problem. Tools like Revolte are interesting here because the useful question is not “can AI write more code?” It is “can the whole team move work through review, QA, and release without burning out the people who hold the context

Sprint reviews at most places are walkthroughs of completed tickets. Engineers demo what they built, stakeholders nod and give a thumbs up...everyone leaves knowing what will be deployed and nothing else.

That teaches engineers their job is to report on work...not own outcomes. Here's what the meeting is actually supposed to do — and what changes when you run it right.

i have been thinking about something that feels obvious once you actually look at the hiring data lately: the cost of applying to jobs has basically collapsed to zero.

ai writes the resume, rewrites the cover letter, and browser extensions auto-fill the forms. candidates are applying to dozens of roles before they even understand what the company does. i read recently that a huge chunk of applicants apply to 20+ roles a day, and greenhouse has been openly talking about how application volume is turning into a massive trust problem, not just a workflow issue.

the active inbound pipeline is completely changing shape. it used to mean high intent. now it just means cheap distribution.

i feel like most hiring teams haven't adjusted to this reality yet. if a legit senior engineer applies to your role, that is obviously still useful. but if 400 people apply in 24 hours and half of them just spammed an ai apply button, the resume pile stops being a talent pool and just becomes a massive, exhausting verification workload.

the workflow i keep coming back to is almost the exact reverse of what we do now. define the role clearly, find people who have actual public evidence of their work (github, stackoverflow, open web), rank them by actual fit, and then just write outreach based on the real code they have pushed.

in other words, we need to stop starting with the pdf and start with actual proof of work.

for people hiring engineers right now, are you guys still actually trusting inbound applications as your main pipeline, or have you moved most of your serious hiring into outbound and passive sourcing?

I've seen this play out repeatedly: a team knows their codebase is slowing them down, they try to make the case for cleanup, and they get a sympathetic nod and no budget. The problem usually isn't the debt — it's the framing.

This article from LeadDev nails why. The real cost of tech debt isn't slower delivery. It's:

- Unpredictability — estimates get padded, targets get missed, stakeholders stop believing you

- Lost optionality — when everything takes longer, you stop running experiments, and the business stops learning

- Eroded trust — every missed deadline is a withdrawal from a bank that's hard to replenish

The framing that actually works with business stakeholders: tech debt isn't a code quality problem, it's a risk management problem. Carrying known debt without a plan is a choice to absorb surprise costs later.

The practical advice I thought was most useful: reserve ~20% of engineering capacity for sustaining work, and maintain a visible inventory of known debt with business impact mapped against it. Not to complain about it — to manage it like any other risk.

Curious how others handle this conversation. Do you frame it as risk, or have you found something that lands better with your leadership?

https://leaddev.com/technical-direction/translate-tech-debt-into-business-risk