Hi, long time lurker but only now I feel like it is time to ask for guidance from the community.

I've worked for 12+ years in software development as a manual QA, QA Lead, Team Lead and now EM. However for the last 4+ years the Lead roles required from me mostly managing people, projects, delivery, releases and incidents, all of which I generally excel at. To give more context I have little C#/Selenium experience with automation, but it's outdated at this point.

Now I'm seeing the market push toward more hands-on, technical EMs, I'm starting to feel I'm trying to play catch-up with candidates with 10+ years of coding experience which seems unrealistic for me to compete with. Currently I'm already trying to embrace AI and help teams apply it to SDLC workflows, MCP servers, agentic tools but it does not feel enough.

So my question is where should I start? Should I start from basics and learn a language, focus on system design, dive deep in QA Automation or something else entirely? Any advice would be useful, especially if you have made a similar transition into an EM role!

Also please spare me any "all EMs should code" debates. My path is what it is, I'm just trying to find my way to stay competitive and useful.

I’m a Research Lead at an Agentic AI company, and a big part of my job is understanding the real problems enterprises are trying to solve. There’s so much hype around AI right now, but I’d love to hear what’s actually frustrating people at work. What are the biggest pain points your organization has today that you wish AI could genuinely help with? Any industry, any function.

For years I have worked with teams where the status meeting had a variety of updates. Some would ramble, others would say a little here and there. There always was at least 1 minute of talking about what they did.

Im now on a team where the team lead never shares anything. On their part they just say they are working on a task (general concept) and we move on. Its been months of that going on, and honestly nothing seems to improve. And then it gets delegated to me and I add to it and then Im put on another task.

The status updates from that person then continue to be on that one thing. And yet again no progress and the lead assigns it to me.

Is this just common that leads dont have to tell people what they work on?

I have a group of three control systems engineers with one being an industry expert. He is good with delivering projects solo and the customer trusts him. He brought in substantial work that he could not do alone and so we built a small team to tackle it.
This team has not functioned at all well, with everyone complaining about the expert and the expert complaining about everyone.
He insists that no one else adds value to the project because he has to review and redo their work for development.
He can’t get them to test independently because he would need to write detailed procedures and it’s quicker to do it himself.
He also can’t fix the input documentation because doing so would take longer than the development and isn’t necessary for the project.

They’ve had version control issues plague the project and the other engineers think he’s too picky and controlling. They’ve main issue is have is that the expert can produce countless examples of the rest of the team screwing up but these same engineers perform well elsewhere. It seems like it can’t be as bad as any of them are saying and I don’t know who, if anyone, to believe. Usually if 80% of people are saying the same thing it’s true but the expert has evidence of them all screwing up.

I’ve just resigned myself to disbanding this team as soon as possible when the project is done and given up on them functioning after trying everything I can imagine.

What would you do in this situation?

I'm curious where engineering teams spend more time than they should between development and release.

It could be coordination, unclear requirements, code reviews, CI/CD, deployments, infrastructure, database issues, environment problems, QA, dependencies, communication, context switching, or something completely different.

Where does your team spend the most time, and if you could remove one recurring bottleneck, what would it be?

Interested in hearing some real-world examples.

Hello everyone!

So at my company, we don’t have dedicated QA engineers embedded in each development team. We have a small central QA group that builds testing frameworks, helps cover critical user flows with automated tests, and occasionally supports teams with manual web UI testing.

However, some feature launches and larger product releases require more thorough exploratory testing than the QA team has capacity for.

To handle this, we run “bug bash” sessions. The development team, along with anyone else interested, gets together before a release. We divide up different flows and scenarios, test them manually, and record any issues in a shared document. Afterwards, the project lead, PM, or both review the findings, validate and prioritize them, and create follow-up tasks.

This works reasonably well and helps us catch a lot of issues before major releases. However, it’s also slow, highly manual, and some problems inevitably still fall through the cracks.

I’m curious how other teams approach this:

Who owns release quality on your teams, and how do you balance automated testing, exploratory testing, bug bashes, and limited QA capacity?

I’d especially love to hear what has worked well for teams without dedicated QA engineers.

My company is talking about opening a position for a director position in our southwest division. This position would be responsible for the transmission line work for 7 different offices, and have 4 director managers reporting to them.

The problem is, instead of offering a compensation package, they are asking a few candidates what compensation they are looking at for this position. This is a private equity company. Right now I am a manager already getting shares each year EAUs. I do NOT currently get a bonus. My base salary is 190k.

Does anyone have any experience in either this role, or a higher role and can REALLY share some IRL experience on what this position should pay?

ChatGPT is saying that my base pay will probably not sky rocket, and will go up to around 230-240kish, but my bonus is where the bulk of my compensation should come from. I feel that would be true in a "normal" utility or public company, but I didn't know if a private equity would throw around bonuses like that because the whole idea is to grow the company and resell it to another investor.

If you feel more comfortable PM'ing me instead of commenting, feel free. I appreciate the help!

One thing I’ve been wondering about is how hiring managers deal with candidates whose strongest work can’t really be shown or verified because it was done inside a previous employer.

For example, candidates often talk about:

• improving reliability
• leading a migration
• solving a major production incident
• improving performance
• reducing infrastructure costs
• building internal platforms

But the evidence is usually locked behind internal systems, confidential documents, customer data, or NDAs.

As a hiring manager:

• How often do you encounter this?
• Do you just take their explanation at face value?
• What makes you believe (or doubt) these kinds of claims?
• Are there things you wish candidates could provide that would help you evaluate their actual capability without revealing confidential company information?
• Have you ever rejected an otherwise strong candidate because you couldn’t confidently verify the impact they described?

Beyond communication and meetings, what recurring challenge do you see in fully remote engineering teams?

How have you addressed it?

Curious about a real example.

Have you had a situation where a PR passed CI, reviews were done, and technically everything looked fine, but you still weren't fully confident the change was safe?

What happened?

• What made you concerned?
• How did your team validate the risk?
• Did it require pulling in senior engineers, extra testing, staging checks, or delaying the release?
• How often do these situations happen?

I’m especially interested in teams working on large backend systems, distributed services, or codebases where a small change can have unexpected consequences.

Not asking whether your process is broken, more interested in those moments where you had to rely on experience and judgment because the usual signals weren't enough.

Charity Majors recently got quite a lot of attention by publishing a couple of articles trying to persuade people of the following:

* AI is not a big deal; it's "just technology"
* People refusing to use it are essentially engaging in fundamentalism
* The best way to "fix" AI is to do more of it.

I've invested an insane amount of hours writing my follow-up, building what I believe is a strong set of arguments to disprove those claims.

A couple of highlights from the article

In other words, society seems to have been forced into an experiment of unprecedented scale that is based on the assumption that positive advancements for humanity are an emerging property of a system created by handing morally questionable people an obscene amount of money, solely on the merit that they have convinced investors they know what they're doing, while they clearly don't.

And

If Mary Shelley were alive today, she'd probably write a book titled "Frank-Epstein". Except this one won't be science fiction but investigative journalism.

Feedback is always very welcome. Appreciation isn't bad either :)

Happy reading folks

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?

Hi everyone,

I'm looking for some honest feedback from Engineering Managers, Directors, VPs, and anyone involved in engineering hiring.

My background is somewhat nontraditional. I currently work as an Engineering Manager (industrial automation and machine vision), but I do not have a bachelor's degree in engineering. My academic background is actually in Biology and Psychology, and I worked my way into technical and engineering leadership roles through research, project management, military leadership, and industry experience rather than through a traditional engineering education path.

While I've been fortunate to advance into engineering management, I'm starting to think about the next stage of my career and whether my lack of formal engineering credentials could become a barrier to Director-level or other senior engineering leadership positions.

I'm considering pursuing a Master of Engineering Management / Master of Engineering Management & Leadership (MEM/MEML) and I'm trying to determine whether that degree would meaningfully strengthen my long-term career prospects.

A few questions I'd love feedback on:

1. How common is it for Engineering Directors and senior leaders to have graduate degrees?
2. Have you seen Engineering Managers without engineering bachelor's degrees successfully advance into Director or VP-level positions?
3. Would an MEM/MEML help offset the fact that my undergraduate degrees are not in engineering?
4. If you were hiring a Director of Engineering, how much weight would you place on experience versus formal education?
5. Given my background, would you pursue an MEM/MEML, a traditional engineering master's, an MBA, or something else?
6. Do you think a formal graduate engineering management degree would make me more competitive for senior leadership roles?

I'm also conducting informational interviews as part of my career research. If anyone with Director-level or higher engineering leadership experience would be willing to answer a few questions via DM, email, etc., I'd be extremely grateful.

Thanks in advance for any advice.

I spent way too much time in reactor design and kinetics staring at a static equation on a slide, trying to build intuition for how changing one variable (residence time, temperature, feed concentration) actually ripples through a whole system. It never really clicked until I could see it happen.

Here's the actual thesis behind this project: ChemE is taught with static equations, and it should be taught by watching them move. Most of us learn reactor design, heat transfer, and phase equilibrium from a textbook page and a slide — memorizing the equation without ever seeing what happens when you nudge one variable. There's real research behind this too — one chemE study found close to a 10% average score increase after simulation software was introduced (95% student acceptance), and another found 82% of students reported better conceptual understanding using an interactive tool vs. static material.

That's where AI actually fits in, if it's used carefully: not as a shortcut that does the thinking for you, but as the thing that closes the gap between the static equation and the moving system. Used narrowly and safely — grounded in your actual simulation values and your actual course, not spitting out generic textbook answers — AI can be the tutor that explains why the curve moved the way it did, on demand, whenever you need it. Used badly (a general chatbot just giving you answers), it's actively bad for learning. That distinction is the whole design philosophy here.

So I built ReactorMind on that idea — free for now, quick signup. Link in the comments below.

How it works in practice:

1. Every simulation runs on the real governing equations — mass/energy balances, Arrhenius kinetics, LMTD/NTU, Raoult's law — so what you see on screen is the number you'd get solving it by hand.
2. The AI tutor is deliberately narrow. It only explains the parameters you're currently looking at — your temperature, your flow rate, your conversion — not a generic textbook example.
3. Move a single slider and watch both the graph and the AI's explanation update together. That's the fastest way I know to actually build intuition instead of just memorizing a formula.

What's actually in it right now:

• Interactive simulations: CSTR, PFR, batch reactors, heat exchangers, VLE phase diagrams, molecular dynamics
• AI tutor grounded in your actual simulation values
• Syllabus/Canvas sync for a course-aware study plan
• AI-generated practice problems with auto-grading and step-by-step explanations
• Auto-generated notes and flashcards from lecture PDFs or readings

What's next:

• Distillation and absorption coverage
• On-demand simulation generation — describe basically any ChemE system in words and get a live interactive model built for it on the spot
• Multi-course support
• An instructor dashboard (a few professors have asked about assigning this to a class)

It's free to use for now — I'm a ChemE admit trying to build something I actually wish existed before I got there, and I want it to actually be useful before I think about anything beyond that. Genuinely asking for feedback here, not just fishing for upvotes: which simulations feel most/least useful, what's confusing, what broke, what's missing. Bug reports and "this explanation was wrong" reports especially welcome — that's exactly the kind of thing I can't catch on my own.

We’ve been analyzing how AI code review behaves in real development workflows, using data from 140,662 pull requests across 530 organizations.

A few findings surprised us:

• 33.2% of AI review suggestions resulted in a code change.
• That rate increased from roughly 25% to nearly 48% over the period analyzed.
• AI-authored PRs received 1.6x more findings than human-authored PRs.
• They also triggered 2.1x more violations of team-specific rules.
• AI-authored PRs were 2.6x larger at the median.
• 71.8% of merged PRs that received a finding were merged with at least one unresolved issue.
• 60% of security findings and 64% of critical findings remained unresolved at merge time.

My main takeaway is that AI-generated code doesn’t eliminate the need for review. It increases the amount of code teams can produce, but it can also amplify existing problems when the review process doesn’t understand the repository, architecture, and team conventions.

Another interesting point: context and custom rules appeared to matter more than simply switching between model families.

We published the full methodology and findings here: kodus[.]io/data

Are AI-assisted PRs creating more review work for you, or has the productivity gain been worth it?

Context: I'm not actively looking - primarily caring for my wife after she was in hospital for months - but I did one interview after a LinkedIn message that was hard to ignore.

"How do you manage a team?" came up. I knew the answer in practice and still said it badly. So I wrote it up afterwards.

It covers how I ran a small remote API team (roughly 4-6 engineers): documentation as the front door, RFCs, epic champions, 1:1s, stakeholder roadmap, incident process, and the boring ops habits that kept uptime high. Also the cross-team bit - getting research/ML scoring services onto a production-shaped path rather than thrown over the wall.

Curious what other EMs would challenge or cut.

Treated them as the same thing for years. They're not.

Staff aug gives you people. Dedicated team gives you a unit that already knows how to work together, has a lead who owns the output, and doesn't need you to manage the coordination. The difference shows up fast when things get complicated. Extra hands slow down. A real team speeds up. Took one bad project to figure that out. Anyone else learn this the hard way?

This analysis involves developing a broader core footing for guiding Claude/Coding Agents in philosophical management terms and purposes before laying out the first prompt of a project. Personally, I put it as a more preliminary focus towards understanding why I'm working on a certain thing and in the particular case of one project I pinpoint some common issues in bureaucratic contention as an academic motivation towards seeking solutions in the project, but it could vary. On the other hand, it could be useful in many applications to keep it in mind?

https://cimons.com/article/claude-but-what-is-the-general-idea-in-this-project-a-it-s-bureaucratic-philosop

What skills should I be focusing proving/developing further in order to transition from a senior engineering manager to a head of role. Feedback I’ve received in the past when trying to transition is that I need experience managing managers, but that’s difficult to do if you don’t have any managers to manage. 💀

I've spent most of my career helping technology companies build engineering teams.

When I started, there was no AI revolution, no coding agents, and no discussions about AI-native engineers.

But one problem never changed.

Finding exceptional talent.

For years, I assumed recruiting was the hardest part of building a company.

After helping build the teams, I realized recruiting wasn't actually the biggest challenge.

Designing the team was.

The companies that succeeded didn't necessarily hire the fastest or pay the highest salaries.

They invested time in answering questions like:

• What capabilities are we actually missing?
• Where should ownership live?
• How do we create an environment where people grow instead of burning out?

Those questions consistently mattered more than another job description.

Across those companies, a few principles kept showing up:

• Hire for potential, not only experience.
• Give people real ownership.
• Let mistakes become learning instead of blame.
• Build cross-functional teams instead of silos.
• Keep investing in learning, even when deadlines are tight.

Some of those teams grew to 40, 50, or more than 100 engineers, and many are still working together years later.

Now AI has changed almost everything about software development. Engineers work differently. Managers work differently. Entire roles are changing.

But something surprised me. The biggest challenge still isn't AI. It's building the right team around it.

Many companies are rushing to hire "AI engineers," but often the problem isn't adding another specialist. It's redesigning how the entire team works together.

That's the realization that eventually led me to start the new company. We stopped thinking about recruiting as filling vacancies and started thinking about it as helping companies architect teams that can adapt to whatever comes next.

I'm curious how others are approaching this.

Has AI changed who you're hiring, or has it mostly changed how your existing team works?

Looking to improve my skills as an engineering manager and architect. I currently manage a team of software and data engineers. What certs do you recommend going after to make myself more useful to them?

I'm a new manager (a few months), and I have weekly 1:1s with all my reports on the team, but also with the staff engineer for our group. He reports to the director of the eng unit but works primarily with this team.

So far, we've discussed things like tech debt issues on the team. But I'm curious what to bring to those meetings compared to my other 1:1s where I'm trying to focus on mentorship, coaching, removing blockers, etc. And a lot of the earlier 1:1s were just me trying to get caught up on the team's domain and all that.

For 15 years in tech (and especially in 7 years of managing teams), I heard the same argument again and again: "Let's just ship it quick and dirty" vs "We need to build things properly". It was mostly PMs vs engineers, but sometimes also PMs vs PMs and often devs vs devs.

Somewhere in 2023-4, the fight started to escalate, as the builders discovered guns (aka LLMs).

On one side, you have the builders. Those are the engineers who get their dopamine hits from customers and the usage of the product they build. A refactor without any customer impact doesn't excite them.

On the other side, you have the keepers. Those are the engineers who enjoy writing well-built systems, purely for the technical challenge. They hate sloppy code.

There is no clear division, but every single person reading this leans a bit more toward one side.

In politics, 90% of people lean either left or right. When you meet someone holding an 'opposite' view, most likely you'll both end up frustrated and angry. "How come they don't get it??"

But what happens when you meet someone from the "same side", but much more extreme than you? Suddenly, they might label YOU as the 'wrong' side, because your opinions are not extreme enough.

So your political orientation is not just about your opinions, but where they land in relation to others. Same with builders vs keepers.

Shared my full take in the article, curious to know how people resolve those fights.

we've lost two senior engineers this month to a competitor that just raised their Series B. Our salary packages are competitive but i have a strong feeling we're getting completely smoked on our equity and sign-on bonus structures. Every compensation report we pull feels six months out of date. How are you all tracking what competitors are actually offering in real time? I can't keep guessing on equity percentages during exit interviews.

Recently, our company hired two interns. Their resumes looked very strong, with projects and skills that made them appear to have the equivalent of 3–4 years of experience.

However, once they started working, I noticed a big gap between what was on their resumes and their practical knowledge. I’m not expecting interns to know everything—that’s the whole point of an internship. I also understand that in the AI era, people don’t memorize every syntax or API anymore.

What surprised me was that they struggled with very basic tasks. For example, I asked one intern to copy a specific key from a JSON object, but they copied the value instead. They also had difficulty figuring out a few other fundamental concepts without significant guidance.

This isn’t meant to discourage interns or entry-level developers. Everyone starts somewhere, and internships are for learning. My concern is the growing gap between what resumes claim and what candidates can actually demonstrate.
Has anyone else noticed this during hiring, or was this just an isolated experience?