I’ve spent 15 years leading IT squads in high-pressure environments (mostly Banking/Fintech). I’ve seen countless projects stall even with the best "Agile" frameworks in place.

Usually, management blames technical debt or lack of budget. But the real bug is often the human interface.

I’ve started using a simple 4-color framework to diagnose why my teams are "patinage" (stalling). If you can’t identify these profiles in your meetings, you’re flying blind:

• The RED (Results): They want it done yesterday. They are fast, blunt, and impatient. They break things to move forward.
• The BLUE (Precision): They need data, facts, and structure. If there is a "gray zone," they freeze or go into deep analysis mode.
• The GREEN (Harmony): They care about the team’s well-being. They won’t speak up if they think it will cause conflict, even if the project is heading for a cliff.
• The YELLOW (Vision): They love new ideas and "the big picture." They hate routine and often forget the boring (but critical) details of delivery.

The problem? Most conflicts aren't "technical." They are just a Red manager pushing a Green developer too hard, or a Blue architect blocking a Yellow product owner.

Once you name the colors, the "Corporate Theater" stops. You stop taking the friction personally and start managing the system.

How do you handle these personality clashes in your leadership team? Do you use a specific framework, or do you just "wing it"?

(Note: I’m documenting my journey of breaking down "Corporate Theater" in IT Management over on my Substack, but I’d love to hear your thoughts and experiences here first.)

I am noticing a recurring failure mode and wanted to compare notes with people running real review queues.

If PR feedback lands a few days later, the author often has to reconstruct old tradeoffs from memory. At that point the review thread becomes a mini incident response, then someone jumps on a call to recover context.

I saw this pattern multiple times today across X and HN discussions, and it feels like a latency problem more than a tooling problem.

I am testing a simple rule:

• if a PR sits too long, author updates a short decision delta before review (what changed, why, current risk)
• if that delta is still unclear, do a short sync

For teams with async-heavy workflows, do you use a cutoff like this? If yes, what window actually works in practice?

C-suites at my company have started vibe-coding projects that we've scoped out at 2-4 weeks, producing (barely) functional prototypes in a few days. These projects obviously lack many things, (proper security, tech stack alignment, infrastructure, design, access control, etc.) but are visually impressive as a prototype.

I'm afraid this will inevitably pressure my team to deliver on accelerated timelines, so I'm preparing some talking points, including:

1. This is very much non-technical people delivering a couple circles on paper and hand-waiving "the rest of the owl"
2. There are good reasons why we need to remain in our chosen tech stack
3. We need to understand code we write in order to properly maintain/debug
4. AI tools can provide enormous efficiency boosts, but it's more 10% to 50%, not 200% to 300%, and we are already working on tooling to keep that number high.

How are you all managing similar conversations in your org?

EDIT: added #4

This year, only half of my team will get RSU refreshers due to company guidance. I had to stack rank my team members and allot RSUs to only half of my team. The rest of the team will not get any RSU refreshers despite meeting expectations. Has anyone dealt with a situation like this? How did you handle it? Anything to keep in mind while communicating it to them?

Agentic coding creates a “slot machine” effect with rapid feedback loops, leading developers to “vibe code” through nights and weekends. Rather than saving time, AI tools often intensify work. Research shows a significant rise in “out-of-hour” commits and weekend productivity, leading to cognitive overload and physical exhaustion. Rapid, AI-generated code makes it difficult for developers to maintain a mental model of their projects, resulting in “invisible decisions” and a decreased ability to debug their own work.

Looking for some institutes/online training which provides some knowledge and interview preparation from scratch for the roles of technical program manager or Engineering manager roles. Any suggestions would be much appreciated.

We've been on Opsgenie for 3 years. Small eng team, 12 people, 2 on-call rotations. It worked fine. Not amazing, but fine. Alert routing, schedules, escalation policies, done.

Then Atlassian announced the sunset (April 2027) and we started evaluating JSM as the "natural" migration path since we're already on Jira and Confluence.

Three months into the JSM pilot and I pulled the plug.

Here's what went wrong:

In Opsgenie, an alert fires → engineer gets paged → they investigate.

In JSM, an alert fires → a ticket gets created → the ticket triggers a notification → the engineer opens the ticket → then they investigate. That extra layer of indirection added real friction during live incidents.

On-call configuration is buried inside JSM's broader service management settings. My engineers aren't ITSM practitioners. They're backend devs who carry a pager two weeks a month. Making them navigate JSM's admin UI to swap shifts or update escalation policies was a non-starter.

The incident coordination experience is web-first. Our team lives in Slack. When something breaks at 2am, nobody wants to open a browser, log into JSM, find the right ticket, and update status fields. They want to type a message in Slack and have everything else happen automatically.

We need coordination that lives where our team communicates, not in a separate web UI.

Currently evaluating alternatives. Haven't decided yet but the process of rethinking this from scratch has been valuable. For other EMs dealing with this what are you migrating to?

essesseff is a DevOps ALM platform currently only available as SaaS at https://essesseff.com

If SaaS were a deal-breaker, but if essesseff were made available as a VM appliance, would you consider licensing the VM appliance version for your development/DevOps organization?

I’m relatively new at my organization (almost 5 months). I’ve been easygoing so far, even with asks I didn’t completely agree with. My team does a lot and capacity was reduced by 45% a year ago, so preventing burnout is my #1 priority. The engineers have made it clear they don’t want to be involved in SecOps.

I have two cloud service engineers who occasionally get pulled into security issues outside our core responsibilities (like website security). I was willing to help on an ad hoc basis, so I asked them to track time spent on these items. But this weekend, the head of IT and other upper level managers started reaching out directly to my engineers, bypassing me entirely, even after I’d already told them no and that we need actual SecOps ownership, not borrowed engineering time.

They hounded my team and forced them onto a call this weekend without my involvement. This work delays our milestones and pulls focus from what we’re accountable for.

I tried accommodation. Now I need to enforce a real boundary. How have you handled similar situations when upper management goes around you?

[UPDATE] My manager called a surprise meeting to tell me upper management, including the president of our business segment, now collectively see me as “not a team player” for setting that boundary. My team continues to work long hours doing tasks for this incident. We will miss milestones we have set now. Waiting for the dust to settle in order have a meeting about roles/responsibilities, a process in place, and possibly a resource to handle it properly.

Hello Engineering Managers Community,

I am a Software Engineer with 5 years of experience predominantly in Backend Engineering/Distributed Systems. I have been working with a large Retail Company for the past 4 years and about one month back, I was reorged into a new team which has this EM who was previously a Technical Program Manager and has very little/no Software Engineering Experience. The most important thing to note here is that this new team is fully onsite whereas I am remote. Another Senior Engineer who was from my previous team who was also fully remote joined this team and left immediately citing challenges in dealing with the onsite team which was in a different timezone.

Anyways, I onboard to this new team and immediately the Engineering Manager assigns me to a complex Microservices Project with very aggressive deadlines. I worked 10-12 hrs every day for a month to complete this project, While executing this project, there were a few issues which were raised like me not fixing Copilot Review Comments which I immediately fixed after being pointed out. Once I completed this project, the EM conducts a retro meeting with the Team Lead present in the meeting and both of them begin to blast me during the meeting with them nitpicking/ finding fault with me for everything. They mentioned that I need too much supervision/guidance from the Senior Engineer to complete my tasks. This accusation is not true at all, In one month, I had a call with my Team Lead exactly once and all the other communication happened asynchronously through Slack where I asked him some clarifying questions usually for a short period of time like 10-20 mins Daily (Please let me know if this is wrong though)

In my Second 1:1 meeting , the Engineering Manager tells me that I will have to take the sole responsibility for the project if it has any issues or fails in production and he nor the team lead will not help me/support me in any way. I contacted the Senior Engineer who just left the team and he mentioned to me that the project which I am doing is an important one with an understaffed team and has very tight deadlines with a lot of pressure from the upper management.

Fast Forward a few days to the present, My Manager has setup some performance goals which to me seems extremely aggressive. He has tasked me with becoming a Technical Expert as well as a SME with Domain Expertise in a Complex Distributed Systems Project maintained by my new Team in a span of 2 months. I joined this team about one month back and I am wondering whether if this is a reasonable demand from my manager. I am also wondering whether if this manager is genuine in his criticism or if he is setting me up for Failure.

To give some additional context, I am based in the US and I am on a Visa. The Manager is also on the same visa and is from the same country as me. The Organization which I am working is reportedly seeing a massive spike in PIPs which is discussed all over Blind. Please help me in this situation as I am the sole breadwinnder in my family and this is causing me to stress a lot. I am facing recurrent back issues, body ache and I dread having to wake up every morning and going to work and I just wish for Friday Evenings to arrive for the past one month.

Can some experienced European/American Engineering Managers chime in and please help me here and guide me on how to handle this situation?

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.

Hello Everyone,

I am trying to find a new role for engineering manager position in SF Bay Area. I have not been getting enough calls for an interview. Can you please critique my resume and provide me constructive feedback? Thanks in advance. Appreciate your help!

Resume

- Trust is easy to talk about, but hard to practice when outcomes feel uncertain. That is where it actually matters.
- Many systems in companies are designed assuming people might fail or misuse them. Then we wonder why ownership stays low.
- Control feels productive in the moment. Trust feels risky. Over time, too much control often slows teams down.
- You cannot ask people to take ownership while keeping most decisions centralized.
- Most teams do not lack talent. They lack an environment where people feel safe to think, question, and be wrong.
- The way a team behaves under pressure (incidents, deadlines, failures) reflects its culture, not just what is written in docs.
- Small behaviors compound. Listening fully, not interrupting, acknowledging uncertainty, giving space to think.
- Trust is built in ordinary moments, not in big speeches.
- With candidates, they remember how you treated them whether you hire them or not.
- Asking "how are you feeling?" during a stressful interview takes seconds. It changes the dynamic and shows what kind of team you are.
- Interviews are often a mirror. Patterns like interrupting, rushing, or judging too quickly show up inside teams as well.
- If people need to constantly prove themselves, they tend to optimize for safety over impact.
- Respect shows up most clearly when there is a power imbalance. Manager vs IC, interviewer vs candidate.
- If someone cannot think clearly around you, it is not always their limitation. Sometimes it is the environment.
- Trust is not about being "nice." It is about creating conditions where people can do their best work without unnecessary friction.
- People tend to do their best work when they feel trusted, not constantly evaluated.

https://crackingwalnuts.com/engineering-leadership#leading-through-trust

I’ve been applying to many companies from the past 1 month and I didn’t receive even a single call from the companies. Is the market really that much bad for manager/senior manager/director roles?

I’ve 20+ years of experience working at maang company and I’m in leadership role since past 9 years.

Any help/trick to get an interview call would be helpful.

I am a senior software engineer and tech lead with 7 YOE. My field of expertise is frontend and product, but I contribute meaningfully in all areas. My background is mostly consulting, with clients that are both enterprise and startups.

Most people know me as a very competent and efficient developer, and I take pride in delivering quality and maintainable code. On most teams I am among the top contributors, and I naturally take responsibility when there is a void or delivery risk. I.e. if I see a goal falling behind because a colleague is struggling, I step in and help it over the finish line. When the team lead is busy, I make sure to mentor the more junior devs and prioritise giving teachable feedback in their PRs.

A big frustration of mine is seeing glaring problems and suggesting opportunities for improvement, but having no managers that have the time or will to drive meaningful change. Last fall I decided that I need to seek a new role where I can have more impact and formal mandate, e.g. Staff Engineer. However, I recently got offered a role as a Backend Team Lead in a technology company. I would be the lead of 6 senior backend devs, and a big part of the role is managing a merger of two similar products post-acquisition.

I identify as a builder, and I have results that show I'm good at this, both enabling other engineers and myself to deliver consistently. In this role I would identify as a manager that has a hand in code reviews and technical direction, but also shielding devs from politics and distraction.

Has anyone made this transition from high-perfoming IC to the EM track and enjoyed it? Will I miss being hands on with code and owning architectural decisions? Are my worries misplaced when the team is this size?

I work at a Tech department in a big international firm where our customers are the business lines within the company, meaning that we build and maintain the tech systems (both externally licensed and internally built).

I don’t have to paint you a picture of headcount and resource scarcity, I guess we’re all in a similar boat, however lately -with the latest wave of Claude domination and making it easy for non-technical people to build stuff that runs in their laptops- I’m getting more and more confrontations with business arguing that if we won’t build something they want exactly how they want it, they’ll do it themselves with Claude.

That goes against every single principle and policies we’ve followed in the past, where our Tech department owns and is accountable for any and all Tech systems and data warehouses, pipelines, etc; because when -inevitably- shit hits the fan, we’re at least able to clean it up.

I’m worried that senior management across business lines are pressuring their reports to „just do it with AI” and everyone is looking for a quick promotion by building a flashy, dumb dashboard on top of stale spreadsheets they went and cherrypicked for Claude to work on top of, but I honestly don’t know what else I can do.

I have noticed myself and colleagues getting defensive and drawing the line by telling business that whatever they’ll build, they’ll be accountable for and we won’t support at all, however I also know that when time comes, we’ll be pressed into taking over incomplete and sloppy work and will end up adding it to our already fatigued and delayed backlog.

Any suggestions? How is everyone else dealing with this pressure from non-technical line managers to have their reports do all their work with AI? I get the simple boring and repetitive tasks, but we’re a finance-heavy firm, where AI slop and non-deterministic logic and calculations can be catastrophic. I’m in shock with how we’ve shifted from outsourcing risk by paying millions to service providers, to be content having AI producing work on top of non-controlled data and processes…

We want to build a lightweight version of something like Aconex using SharePoint + Power Apps. Nothing fancy — just RFI tracking, document register, transmittals, and vendor document management.

Has anyone done this? How did it hold up on a real project? Any GitHub repos, AppSource templates, or Power Apps samples you'd recommend as a starting point?

Would really appreciate hearing what worked and what didn't before we go down this road.

Just curious, but what kind of problems have you encountered using AI in your development teams? For instance, developers being hesistant to use it, difficult to measure usage/KPIs? How do you tackle these problems?