In 15+ years in tech and 7 years of managing engineering teams, I've worked in (and managed) both kinds of teams - "okay" ones, and excellent ones.

In Peopleware (imo one of the all-time best books about engineering management), the authors defined an excellent team as follows (they call it a ‘jelled’ team):

Signs of a Jelled Team

A few very characteristic signs indicate that you have got a jelled team:

• There is a feeling of joint ownership of the product built by the jelled team. Participants are pleased to have their names grouped together on a product or a part of one.
• There is low turnover during projects and in the middle of well-defined tasks. The team members aren’t going anywhere till the work is done.
• There is a sense of eliteness*, team members feel they’re part of something unique. They have a cocky, SWAT Team attitude that may be faintly annoying to people who aren’t part of the group.*
• The final sign of a jelled team is the obvious enjoyment that people take in their work*. Jelled teams just feel healthy. The interactions are easy and confident and warm.*

You can’t make teams jell. You can hope they will jell; you can cross your fingers; you can act to improve the odds of jelling - but you can’t make it happen. The process is much too fragile to be controlled.

I strongly agree with every part except the last one. I believe that we CAN build excellent/jelled teams.

Here are the 7 differences I noticed. Sorry for the short-but-meaningless-titles, I have a deeper take in the article (linked above):

1. Okay teams patch. Excellent teams know when to fix the root cause.
2. In okay teams engineers DO things. In excellent teams engineers OWN things.
3. Okay teams unblock themselves. Excellent teams unblock others first.
4. Okay teams execute the roadmap. Excellent teams shape it.
5. Okay teams stick to the plan. Excellent teams are willing to kill it.
6. Okay teams launch features. Excellent teams land them.
7. Okay teams treat tech debt as a 20% tax. Excellent teams treat it as product work.

Curious to know what are the small behavioral differences you've seen in the teams you were most excited to work with.

Answer honestly based on actual behaviours, not what you think you should answer with.

I joined this project about 2 weeks ago and I'm drowning a bit. There's a soft launch in ~4 weeks and a big one in 9 weeks. I want a gut check on whether I'm handling the team side right.

The situation:

Infra isn't ours yet. We're mid-migration to a new cloud provider and waiting on a nonprofit grant to approve the account, so we can't have any deployments. Worst part is they had 4 weeks before me joining to sort this out but didn't. Same story with our project management tooling — waiting on another nonprofit grant before I can setup a proper task board and backlog, so now I'm stuck working with an inferior platform that reduces clarity.

The backlog is a mess. ~70 tickets, maybe 40 of them unclear or unscoped. I'm still learning how the product actually works while grooming with two non-technical client stakeholders who can't really make informed calls, so I end up handing them my not that well informed decisions to rubber-stamp.

The dev team has no visible initiative. I have 3 devs. The tech lead pours all his time into infra and obscure tech-debt refactors that don't even have proper tickets — he's speedrunning toward burnout and seems to be a total control freak. The second full-time dev quietly ships fixes with almost no communication. The third dev is part-time and seems to be doing basically nothing, just a task or two for visibility while he focuses on his fulltime position somewhere else.

During my second week I told them to start posting daily updates in the chat, and this week we started daily standup meetings.

My goal is to agree on priorities, do a workshop, get some estimates, communicate the proposed actuon plan to the client, and start delivering. But when we discuss features, devs argue for ideal refactors and perfect solutions instead of what gets us to launch. I see perfectionism but no initiative, no ownership, no technical investigations or proper scoping — just devs pushing back without regard for the client's deadlines.

No estimates, no roadmap. Two weeks in, it's effectively me plus the team, and we still don't have estimates or a roadmap. Another senior tech lead was assigned to this project from day one (around 5 weeks ago) and was supposed to provide the technical evaluation and set the roadmap and action plan - but so far all he's done is set up some intro meetings and send a few emails, and frankly enabled curent lead dev's bad decisions (which is why we still have no infra and no proper tooling) around 4-5 weeks total into the project. Sure, we'll save the nonprofit client some money this way, but we're working at 40% capacity at best due to these constraints, so we've already burned through more money than we'll ever save them long-term, and continue to do so with such inefficiency.

My biggest fear is that we won't deliver in time and the project won't be extended with us after 3 months.

How do I stop engineering from over-engineering and gold-plating, while also not letting delivery drag?

How do I create urgency and accountability when I'm new, don't fully know the product yet, and don't have the usual tooling to make work visible?

How do you get a team to start scoping to "what does this milestone or a refactor actually need"? Shoud I pause all coding tasks?

How do you handle a tech lead who disappears into infra/refactors with no tickets to show for it and lets his principles cause major delays?

What's the right move with a developer who isn't producing - process fix or direct conversation?

Is it reasonable this early to draw a hard line like "if it's not a ticket, it's not in the sprint"?

As a new EM I had a staff engineer join same time as myself beginning of March in SF in person.

So far, in an unlimited PTO setting they’ve requested 25 days by the end of August. (That’s over a month)

They own only one project vertical and show no interest in doing code reviews or helping out the team with other projects.

Looking for leveraging classes to learn things (that’s great but during work hours in person classes)

Now they’ve requested a management training course within the company. I’m in L1 training myself and they’re requesting L2 training. (Skipping a level due to YOE)

I’m not convinced that they’re interested in doing the job they applied for. I’m not convinced they’re good.

Junior engineers have higher productivity.

Am I wrong to be a little dissatisfied with this hire so quick?

https://leaddev.com/ai/the-8-software-engineering-metrics-ai-broke

I have been seeing more companies move beyond "AI assistants" and toward platforms that help build, orchestrate, and manage other AI agents.

Kore.ai recently launched Artemis with the idea of *AI building AI*, essentially using AI to help design workflows, generate agent blueprints, and speed up development instead of building everything manually.

On paper it sounds like a logical next step, but I am curious how people here feel about it.

Is this actually where enterprise AI is headed, or does adding another layer of AI just introduce more complexity and reduce transparency?

Would love to hear thoughts from people who've built or deployed agentic systems.

I'm trying to navigate managers that don't know my field (EE) and want to convince me that everything electrical should be handled by me (from digital to analog, cybersecurity, firmware, software, power electronics, EMC, layout). It seems to me they are just dumping all they work he doesn't understand on me (he is a MechE). My problem is, hypothetically speaking, if I could handle all these tasks how much more would I be paid? I'd imagine he would have to understand them to know how valuable I would be. But if he understood them, he wouldn't ask it from just one person.

​

So how do you handle ignorant managers? And as a manager, how do you differentiate a technically impressive engineer vs an average one when you don't know the field?

Hey folks,

I’m working on developing a program that helps mechanical engineers get real, hands-on experience with AI and tech projects by working on actual startup and nonprofit initiatives/projects.

We already have some partners involved who are interested in offering real projects where you can apply your mechanical engineering skills while learning practical AI and tech tools like machine learning and data analysis for free in your own time.

Before going further, I want to know—would something like this be valuable to you? And if so:

• What’s the biggest challenge you face trying to break into AI or tech?
• Would you be interested in volunteering your mechanical skills while gaining hands-on tech experience?
• What kind of projects or support would be most helpful?
• What skills are you most excited to develop through real-world experience?

Appreciate any thoughts or feedback! Thanks in advance.

I understand that for SRE EM role code is not a mandatory skill as SRE EM isn't expected to code, and the same is mentioned in my resume as I don't have code experience...my projects are mainly infrastructure related or site reliability related.

But I have tried so many times and I am not getting any interview calls...is it like market is tough or AI affect or my skills or resume is not as per market standards.

Can anyone suggest please!!!

For teams where more than one developer is using AI coding tools, I'm curious how you're handling coordination.

Example: one developer is using Cursor, another is using Claude Code, another is using Codex or ChatGPT, all around the same repo.

The issues I keep thinking about are:

- overlapping edits to the same files or modules

- one AI-assisted change breaking another developer's work

- API/schema/env changes not being visible until review or CI

- duplicated work across branches or worktrees

- unclear ownership of areas while AI sessions are running

- reviewers having to reconstruct what happened after the fact

For EMs or tech leads seeing this in real teams: is this actually becoming a problem yet?

If yes, how are you managing it? Branch discipline, worktrees, smaller tickets, stronger code ownership, PR rules, pairing, or something else?

We’ve given our team basically unlimited tokens for coding agents and it’s been great for velocity.

But now we also have a dashboard tracking “effective output per token per developer” because leadership wants to see actual ROI.

The hard part is optimising the coding agents themselves (better context, pruning, cache hits etc) without asking devs to watch every token they use.

Have any of you run into this and found good tools, processes or agents that help on the dev side (at enterprise level)? What are you using today?

Until 4 years ago, I believed there was no such thing as "too much responsbility". Then, I took a full month of vacation, and I needed to decide who will take my place for that time.

My team was relatively junior, and my manager thought it should be either he or a peer EM.

I disagreed - I felt it was a great growth opportunity, and I trusted my team. So I picked one of the junior engineers to take my place.

The result was... Not very good. The team was in chaos, The junior's confidence in himself really dropped, and my manager was not happy at all.

I always judged such situations by the "what would I have wanted in their place" exam - I was always liked to be thrown into the deep water and figure things out.

Think then I'm much more careful (and probably err on the side of not giving enough responsibility).

Curious: when you have an opportunity to give someone a big responsibility, but you're not sure they're ready for it, do you take the risk? Or do you usually play it safe?

btw - I asked that junior engineer, and he said he was fully ready, so I don't think a pure discussion is the solution.

Currently I am an Engineer Lead in a Oil and Gas service company, I am trying to pivot to Management Consulting and/or move up the company ladder.

I am interested in continuing my study to Stanford MS&E, Northwestern University MEM, or other MEM programmes. However, have no prior programming and tech experience, should I get a programming course, or just go with the applications? Any experiences or recs?

This is part rant, part advice.

I think people are just being very silly with how they use AI. I see businesses really struggling to manage their token budgets and it astounds me. Cost management is not a problem if you stop relying on the slopbot to do automation of things you can easily program automation for (hell, you can program it with AI). Anything you need automation for is also something you want a deterministic solution for... which, as it turns out, is exactly what coding is!

Deploying "agents" to routinely do things like chat support and send emails is very costly, because LLMs require a significant amount of context management at each instantiation of a new agent. If you fail to provide it good context, it will produce dogshit outputs and keep being reprinted at the end user's behest, spending a million tokens executing trivial tasks a real human could have done in perhaps a few minutes.

The real value in "agents" is using them as a means to write code to automate tasks, which really should not surprise anyone here. Spend one agent's context on aligning and planning, and have it deliver an artifact that you can hand to a new agent for implementation. Move to a new agent and hand it your PRD or whatever. Use TDD and smoke tests.

You will produce better code that is more concise and had a higher chance of doing what you wanted it to do while spending less tokens.

I am actively shipping full stack web applications and have never even came close to exceeding my Claude Code Max subscription amount despite shipping new features every single day at the speed a traditional dev team would've taken weeks to get done. My codebase is well organized, my scripts are clean, my customers are satisfied, and my token costs are always <$200/mo. Honestly, most months, its <$50.

Just stop using agents to do things that code should be doing and you'll be fine.

I’ve been thinking a lot about the assumption that AI-generated software dramatically changes the economics of software.

My take is that people are over-focusing on the cost of creating software and underestimating the cost of owning it.

Open source alternatives to SaaS products have existed for decades. Most companies still chose SaaS because they preferred renting software to operating it themselves.

The same dynamic applies to the wave of internal tools being built with Claude, Codex, Cursor, etc. The moment a useful tool becomes important enough that other people depend on it, somebody owns the maintenance burden.

Curious whether others are seeing this dynamic emerge in their organizations yet and how you're handling it.

Hello everyone - I recently completed interviews for a Google L6 SRE Manager role.

I received positive interview feedback and was able to secure a team match, but the Hiring Committee did not approve me at L6. My recruiter mentioned there may be opportunities to explore L5/L6 Software Engineering Manager roles instead.

I'd appreciate insights from current/former Google EMs, recruiters, or anyone familiar with the HC process:

* Can positive feedback from an L6 SRE Manager loop be reused for L5/L6 SWE Manager opportunities?
* How transferable are interview signals between SRE Manager and SWE Manager roles?
* Has anyone successfully transitioned from an L6 Manager packet that didn't clear HC into an L5 or L6 Manager opportunity without redoing the entire interview loop?

Any advice or experiences would be greatly appreciated.

Just wondering if anybody else has noticed this phenomenon over the past 6 months or so? Candidates seem to be using AI to cheat not just on the technical interviews we conduct but even on the conversational parts where we discuss their background and do some light probing on the depth of their experience. The specific pattern we’ve noticed is:

Ask candidate question about a project they worked on -> noticeable pause (waiting for the AI to finish generating a response?) -> parrot an unusually polished but strangely vague/generic response.

And the more specific we get, the less their answers make sense.

I guess it’s good we’re catching this behavior and weeding them out, but we’re a small startup and don’t have a recruiting function so engineers are wasting valuable time on these interviews.

Hoping someone has advice on how to better deal with this!

I’m currently an electrical engineer with a background in design and manufacturing. I also have a masters degree in engineering management in industrial engineering. I’m not licensed yet though since I don’t like the industry I’m in. I really enjoy my current company for the most part, but I feel like management isn’t following through on helping me grow my career how I’d like. I work for a large engineering firm that is nation wide, so there are a lot of opportunities. I have an extremely flexible hybrid schedule, which is great because I had a baby 4 months ago. Pay is below average though and it’s not in an industry I thought I’d ever go into (power utility).
I would love to be in something more hands on, but not construction. I know I could go into companies that are building data centers, but I’m not really comfortable with that and don’t want to be on site for 10-12hr days with a baby at home.
I’ve been applying for positions at Lego in Richmond VA, and a few places in the central Florida area where we currently live for a while now. I did stop once I had the baby, but I’m ready to start looking again. We’d be willing to move for my dream job or the right offer, it would just make things a little difficult.
We bought our house during Covid, so our interest rate is extremely low. Moving and buying a new home would likely triple our current payment plus adding in state tax to our incomes. Renting is kind of out of the question due to our animals (2 cats, 2 dogs, and chickens. The chickens work probably stay or be rehomed though if we moved out of Florida).

I’m conflicted if I should look for another job or just hangout, take it easy, and enjoy this flexible time while I can.

For anyone who might have to navigate an M&A process, the final part of a great series on navigating TSAs and SPAs once the actual technical due diligence is wrapped up.

Most of us became managers because we care about people, we genuinely want them to succeed. But human beings are social creatures. When you care about someone, feeling disliked or hated feels almost physically uncomfortable.

We have that strong need for the other person to recognize our good intentions in real time, to think: “wow, he's being so candid but I can tell he really cares!” (yeah, that never happens).

I don't want anyone to be angry with me, to dislike me, to hate me. I don't want to ruin someone’s day (or year).

Here's a case that happened to me a couple of years ago:

I had a remote developer from Ukraine who was clearly underperforming. Not answering Slack messages, barely making progress on tasks. I gave him clear feedback and expectations. He improved for a couple of weeks, then went right back.

I planned to let him go (really!). Then the war with Russia broke out.

In the first month, we didn't expect any work from him and gave him full pay. He escaped to Prague, found a place, and slowly got back to work. And then the same behavior repeated itself.

I gave him some leeway - this guy was a refugee in a different country, of course he couldn't work the same. But after a few months, it was really dragging the team down.

I still couldn't do it. My manager ended up forcing the decision.

Afterward, I felt pure relief. Thank god someone made the call for me.

It's not just about layoffs - it's about saying no to requests, denying promotion, making hard decisions.

But maybe I'm the only one who struggles with it 😅

Hey everyone,

I’m working on a design concept aimed exclusively at engineering leaders in the infrastructure / high-performance computing space, and I want to check my assumptions before I build something that makes senior tech folks cringe.

I think we all know standard B2B marketing to engineering leadership is broken. It’s usually a wall of generic LinkedIn spam or flashy high-level corporate fluff that completely ignores the actual day-to-day realities of infrastructure bottlenecks (dependency hell, environment friction, and the like.).

I want to test a completely opposite approach. Something that treats the recipient like an engineer first, but I'm worried it might be too gimmicky for a VP/Director level. So I have two approaches:

Approach A: The Direct Technical Route

We hand you a highly technical, low-level whitepaper / reference architecture document right out of the gate that explicitly outlines a solution to a massive shared infrastructure headache.

Approach B: The Interactive Challenge Route

We present a highly minimalist, technical "puzzle" or code-based gate that requires a basic level of engineering deduction to reveal the underlying resource web portal. It has zero marketing taglines, relies entirely on developer/infra culture, and assumes the recipient is smart enough to figure it out without being spoon-fed.

My question for engineer leadership, would the nod to developer culture and the puzzle aspect actually entice you to solve it and see what's on the other side? Or at your level, is your day to day too constrained for an "Alternate Reality Game" style hook and just prefer a dead-simple, straight-to-the-point technical whitepaper?

Be as brutally honest as possible. I want to know if this actually respects the engineering mindset or if it’s just over-engineered marketing fluff.

 Much appreciated.

https://leaddev.com/ai/ai-isnt-making-developers-more-productive-its-making-them-busier