r/EngineeringManagers

I’m a civil engineer from Jordan and recently started working with an international organization on desalination-related projects. Honestly, I’ve become very interested in this field and I feel that water and desalination could become a major direction for my career.

At the same time, desalination is still considered a relatively new field in Jordan compared to Gulf countries, and we still don’t have a large amount of local expertise or opportunities in it yet.

For engineers who work in water, infrastructure, or desalination — especially in the Middle East — do you think this field is worth pursuing long term?

Would you continue building experience in it from now, or would you keep your options more open before specializing too much?

I’m also hoping one day to find opportunities in Gulf countries, so I’d really appreciate honest advice, career direction, or even different points of view from people with experience in the industry.

I’d especially appreciate insights from engineers working in GCC countries or large-scale water utilities.

Thanks a lot.

I’m just curious if anyone has experienced this feeling that engineering leverage is getting less.

For instance, we were raised to discuss tradeoffs with Product when reviewing scope. Most of the time, we try to help prioritize impactful work.

Usually this means we descope bells and whistles. In the past, Product would just have to take our word for it base on our estimates because the “engineers” are doing the work.

Now with AI, technically “anyone“ can code now. Coding well can be debatable, but that’s not the point. The point is that the barrier is much less than it’s ever been. This is what I mean by leverage getting less.

I’m just curious if anyone has ever experienced something like this lately where negotiation power as an EM has been impacted. Any examples? Any tips to adapt to the changes?

I joined a company where the CEO had a very clear vision of what the product should become, with a three year roadmap, detailed feature list, and slide decks full of confident projections. The problem was that the engineers and middle managers who talked to customers every day kept coming back with signals that didn't match the roadmap. Customers were asking for simpler integrations and reliability improvements, not the ambitious new platform features the CEO had planned. Every sprint retrospective, the same feedback surfaced. And every time, leadership dismissed it as noise from people who didn't see the big picture.

Two years later, the company had spent millions building a product suite that nobody was asking for while ignoring the core product that was slowly breaking under its own complexity. The CEO held an all hands and said the market wasn't ready for their vision yet. But the market had been telling us exactly what it wanted the whole time. We just weren't listening.

I've been reading about this dynamic between dogmatic and pragmatic strategy modes, and from what I've seen the trouble starts when you commit to the wrong mode for too long. The money keeps coming in and the complexity keeps growing, and the gap between what leadership wants and what the market needs gets wider until something breaks.

Has anyone else here worked somewhere where the roadmap was set in stone and the CEO treated customer feedback as a distraction?

For those of you who have worked in software engineering management roles, like team lead, group manager, and so on, and then went back to writing code either part time or full time:

Do you feel that coding with AI has affected the way you manage people?

The reason I’m asking is this:

When I code with AI, it sometimes feels like I’m managing agents in extreme micromanagement mode. No compromises, no mercy, no shame in asking dumb questions, and sometimes maybe not using the nicest language either.

Do you feel like you’re able to keep that completely separate when managing human developers? Or do you feel that some of the way you manage AI agents leaks into the way you manage people, even a little?

I worked at two companies where interviewing thirty people a day was completely normal. Not because we had a sudden spike in demand, but because the CEOs were so good at raising money that hiring became the product strategy.

At both places, the playbook was identical. Raise a big round, set a three-year goal that looked impressive in a pitch deck, then reverse-engineer a roadmap to match the story we had sold to investors. That meant creating more teams, adding more features, and constantly expanding the headcount to show momentum. I sat in roadmap reviews where every justification traced back to the pitch deck, not a customer conversation.

The CEOs weren't malicious. They were just really good at raising money and the problem is that raising money fabricates demand based on the power of convincing investors, not real customer demand. The excitement of the next round drowned out the real market feedback.

I spent entire weeks in back-to-back interviews while our actual product stagnated. We were hiring people to manage the complexity of hiring people. The capital had stopped being fuel and turned into a production line for internal bureaucracy.

That experience broke my assumption that more money equals more progress. Now I think hypergrowth is just bad money in disguise, a way to mask the gap between what investors want to believe and what customers actually need. Has anyone else watched a company hire aggressively into a demand curve they mostly invented in boardrooms?

Hello,

I would like ask the forum to advice or suggest for my future position.

I am first time will hold the position of the Head of Development, Engineering and Systems in small scale company for the building envelope systems.

No employee under me and I will report directly to CEO.

I have in my head some sort of plan how to help the company grows up, but maybe some one has an advice for me.

Thanks

I have access to Claude, but it is currently limited to basic bookkeeping tasks. I want to be more productive and prepared for new job expectations.

"The good news for engineering managers who find their place in the engineering org may be shrinking is that they’re in high-demand as ICs."

Orgs are flattening
Headcount is reducing

What is the future of this profession?

I’m an intern and my manager asked me to modify a spreadsheet containing company info. However I don’t have a lot of skill with excel so I was planning to just figure it out as I go. Our work computers have Copilot built into them with a license I think the company pays for. I also heard some of the senior managers say that it has firewalls that prevent data from being leaked. I was thinking I could upload the spreadsheet to Copilot and ask it to provide me with a list of features I could improve and how to do so. Is it safe to do this? I know uploading intellectual documents to public AI like ChatGPT or Gemini is strictly prohibited but is it possible with Copilot?

since we leaned heavier into claude code and cursor over the last 6 months individual output has gone up a lot, but our review process hasn't scaled at all. PRs sit for 2-3 days waiting on the same 3 seniors who were already the bottleneck before AI showed up

we've tried smaller PR rules (helped a little), rotating primary reviewers (helped a little), explicit review SLAs (helped for about a month then slipped), and adding coderabbit on every PR for the first pass so humans only see the meaningful stuff (this one helped the most but still doesnt solve the architectural review part which is where the actual delay is)

honestly at this point i think the problem is organizational not technical. the volume of code shipped per engineer has gone up maybe 2x and the supply of senior reviewer hours is flat. and no amount of process is going to fix a math problem

curious what other teams are actually doing. specifically the 10-30 engineer range. is it more reviewers, fewer reviews, different review structure, accepting longer cycle times. genuinely asking, we havent figured it out

Last year I was running a five-person team and someone handed us a feature that was genuinely simple: parse some data, display it in a dashboard, two weeks of actual work maybe three if you count testing. Somehow it took four months. We finished the code in two weeks, like we estimated. But then the platform team had to review the API contract, who had their own backlog, and someone realized the dashboard touched a data pipeline another team owned, which meant a schema review, which meant two more meetings. None of this was anyone's fault because everyone was busy doing their jobs. Every handoff added another week of waiting, and every week of waiting triggered another stakeholder asking for a status update, which triggered another meeting to produce the status update, which ate the time we could have used to unblock ourselves.

The delay wasn't linear because the overhead was generating more overhead. A two-week delay created a coordination meeting, which created an action item, which created a dependency on someone who wasn't in the room, which created another meeting. The process was feeding itself and the only thing we were shipping was alignment. By month three I stopped tracking the timeline and started counting how many people were now involved who had nothing to do with the code: fourteen people across five teams, and the original two-week feature hadn't changed in scope. The complexity had moved from the software into the human circuitry we built to manage it, and that circuitry had developed its own appetite.

I've been wondering how many teams are in this position right now, paying this invisible tax without ever calculating it. I'm talking about the quiet compounding cost of every architectural decision that adds friction to the system, not the obvious refactor conversation.

Has anyone else actually calculated the actual cost of a feature that should have been simple but turned out to be so complicated? What did you find?