r/EngineeringManagers

Hear me out.

We all know that business has never cared about the code. What they want to care about is the derivative of the code which in most of the cases is related to money.

The reason they have had to actually care about the code is the cost of maintenance. If the code is bad, managing change is expensive.

Now, with agentic engineering industrializing the SDLC, the code itself is becoming less important, if it can be reliably generated from another substrate. This substrate is what can be loosely defined as the “business know-how, processes and workflows”.

So my question to you folks is, do you believe business is going to stop caring about the code entirely and shift its focus elsewhere?

In my team I notice senior engineers write detailed explanations in Slack, but months later nobody can find them. Curious how others solve this.

After the arrival of Claude, my company has started building a lot of AI “skills” to automate the software development lifecycle.

Some of the skills our CTO has created include:
Jira Ticket Creator
Batch Ticket Analyzer
Interactive Tickets
Auto QA
Manual QA Assistant

For example, the Batch Ticket skill reads a Jira ticket, searches across all of our repositories, identifies the likely root cause, and prepares an implementation plan.

Once the code is implemented, it automatically triggers Auto QA, which runs Playwright tests, attaches the test evidence to the Jira ticket, creates a PR against the target branch, and updates the ticket status.

Lately, management has been saying that developers won’t be writing much code in the future—they’ll mainly review AI-generated code.

To be honest, this makes me a little concerned. It feels like they’re gradually building an AI-driven workflow that automates more and more of the engineering process, and I can’t help wondering whether this could eventually lead to layoffs.

Is anyone else seeing something similar at their company? Is your engineering team building internal AI agents or workflows like this, or is this still uncommon where you work?

I’d be interested to hear what your company is doing and how your developers feel about it.

I've noticed that teams can have a sprint where most work is still marked "In Progress" or appears to be moving, yet the sprint slips near the end.

In your experience, what's usually happening behind the scenes?

Is it dependencies, QA, code reviews, environments, changing priorities, CI/CD, or something else entirely?

I'm interested in hearing real examples from engineering teams. What patterns have you seen?

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 !

At my work, the fix usually isn't the slow part.

The slow part is figuring out whether it's the application, the pipeline, a flaky test, a dependency, or some cloud/platform issue. Developers end up digging through thousands of log lines or waiting for someone from DevOps or Platform to weigh in.

I'm curious how other engineering teams handle this.

Do your developers own CI failures end-to-end, or do they regularly bounce between engineering, platform, and cloud teams before someone finds the real cause?

Has anyone found a process that consistently reduces that back-and-forth?

Every month I ask my reportees to prepare a document describing what they did in the last one month and I provide them feedback. This helps me and team member with the data when we do performance review half yearly.

I want to understand how others are doing? If my approach has any cons?

Spent most of friday writing the weekly update for leadership. Again. Pulled the Jira stuff, chased three people on Slack to find out where things actually landed, rewrote it twice so it'd read right to the VP. Couple hours gone. The thing it was reporting on didn't take much longer than that to build.
And it's never just once. Something slips, someone upstairs asks for a status, and producing the status eats the time we'd have used to unblock the actual thing. At some point the updates kind of became the work.

What I can't figure out is whether that's me being bad at this or just the job now. Half of me wants to make it vanish - one doc people can read on their own time, kill the syncs. But I think the reason they keep asking is they don't really trust the system to tell them, and a tidier report doesn't fix that.

So for people who've been at this longer: is it just overhead you've made peace with, or did something actually change it? And the honest one - when you have to show leadership your team was worth it, what do you reach for?

I moved to a startup fairly recently as an engineering manager, leaving a stable job to do it. During interviews I did my diligence — asked about leadership, product, culture, remote setup — and it read as a good fit with a boss I'd want to work for.

Since starting, a few things haven't matched what I was told. The remote policy is changing, and the product area I was hired to run wasn't as real as it sounded.

But the bigger issue is cultural. There's a persistent lack of trust in the engineers. Communication from the top is thin. Strong, experienced teams get overruled on technical decisions with regularity. And effectively no one below the exec level owns a decision — people make a safe call, then route it upward for approval, so there's constant churn and rework.

The part that really shifted my read: a major product direction was set unilaterally at the top, with essentially no engineering involvement, and it's being celebrated by the business. I get why from a business angle — but the teams now have no clear sense of what role they play. And the execution quality coming out of that process is rough: little to no testing, shortcuts everywhere, no real engineering discipline, and things break constantly as a result.

When I raised career growth with my manager, the implication I took away was that it's contingent on nights and weekends.

The throughline is that the engineering leadership and culture-building I was hired for don't actually seem wanted. There's little appetite for building sustainable process or a real engineering org. I feel less like a leader and more like a senior IC who also writes performance reviews.

Is this just normal startup stuff, or did I misjudge this?

Anonymized with Claude, my apologies for clanker words.

I’ve often heard people say that engineers and developers are great at solving technical problems but struggle to think from a business perspective.
Do you think this is just a stereotype, or is there some truth to it?

Why do you think this perception exists?

Have you worked with technical people who also had strong business instincts?

If you’re an engineer, how did you develop your business mindset?

I’m curious to hear perspectives from founders, engineers, product managers, and anyone who has worked closely with technical teams.

Something I see a lot with people (usually newer plant managers or founders) who are excited about lean and want to do it "right" ... they try to build the master plan first. Full current-state map, future-state map, multi-year roadmap, phase gates.... the works. Then six weeks later nothing has actually changed on the floor because they are still planning!

I made this mistake myself early on. Thought I needed a complete, defensible plan before I could touch anything. Turns out that's backwards, at least for how you start.

Here's the thing about problems on your floor (or in your process, if you're not literally manufacturing something): they are not evenly distributed. Picture a pyramid. Big wide base of simple, obvious problems: a tool that's never in the same place twice, a form that gets filled out three different ways, a handoff nobody owns. Small tip of genuinely hard, cross-functional, needs-real-analysis problems.

Most people start planning for the tip of the pyramid. You should start by clearing the base. It's not glamorous. It won't get you a case study. But it does two things a fancy roadmap doesn't: it gets you a fast, visible win, and it gets your people used to the idea that they're allowed to change how things work. That second part matters more than people think: a workforce that's never been asked to fix anything doesn't magically start solving problems just because you handed them a roadmap. They start because you let them fix something small and it stuck.

You don't need experts to start this way either. Lean, at the start, is closer to systematic common sense applied consistently than it is to a body of certified knowledge. Certifications and designations rarely matter... the deep tools matter later. At the start, they are often just an excuse to delay.

One caveat that I think matters and doesn't get said enough: this "start small, don't overplan" advice is for getting moving. It is not permission to stay tactical forever. At some point you do need the bigger picture. Otherwise you get a pile of disconnected local improvements that don't add up to anything at the system level. But that's a problem for month six, not week one.

For anyone who tried to build the full roadmap before doing anything, how'd that go? Did it ever actually launch, or did it die in the planning phase?

This is what real Agentic Engineering Loop looks like!

270 tasks in 1 week, just 3 engineers. Many of these tasks are very complex.

My traditional engineering mind would never have imagined the scale at which we're moving now.

I managed teams where 10 engineers would get 20-30 tasks done and still have a lot of spill over. We are now able to do literally 10x of that, and we are just getting started.

The responsibility of the team now is moving from doing the tasks to building the loop that gets the tasks done. There has been a big shift even for us, a team who has been at the edge of Agentic Engineering.

We are currently at a place where 70%+ of our tasks get done mostly autonomously, we aim to push that to 95% soon and also double the number of tasks the system can process.

It's systems engineering at the end, but with agents and humans as components in the pipeline.

Ask me anything about our stack, workflows, orchestration, review process, failures, costs, metrics, or how we got here. If it's useful to other engineers, I'll answer as openly as I can.

https://preview.redd.it/bre880sevtah1.png?width=371&format=png&auto=webp&s=805f0baa11c5116f05946cf98c9cc4b9f4f07383

I want to know what are the problems your facing in your daily life or in workspace or kn any field i want to start a startup so i want problem statements

i’ve been thinking about this after interviewing a number of engineers recently.

CVs are polished.
Linkedin profiles are polished.
GitHub can be polished too.

I feel like they’re becoming much weaker signals of whether someone can actually build and understands the systems they worked on.

So I’m curious:

What gives you confidence that an engineer can actually do the job before the interview?

How do people really understand if someone has teamwork skills or not just from an interview?

I’ve been reading a lot of incident postmortems lately, and one thing that stands out is how different every team’s investigation process is.

Some people jump straight into logs, others start with dashboards or traces, while some rely heavily on service dependencies.

In your experience, what’s the biggest bottleneck during the first 20–30 minutes of an incident? Is it finding the right signal, correlating information across systems, or something completely different?

what has actually improved your team’s workflow.

I am joining a new organisation as a senior engineer manager. It is one of MBB and I was a tech lead with managing experience to a smaller team.

What are some of the things I shd do to manage work, and set myself for success in my leadership role.

I am reasonably good with respect to technical strength.

Any guidance is really appreciated.

I have been feeling Imposter Syndrome as well lately and pushing myself to go out of my comfort zone.