Thoughts About Eng Leadership in 2026

Every conversation I have with a CEO, CTO, or VC seems to start with the same vibe of FOMO questions: “What do you see that’s changed in good eng orgs? What do you think is the right track?” I’ll try to answer here, in short, those and similar questions.

So, what’s actually changed?

If you look carefully, I’m saying that most core concepts of proper engineering leadership haven’t materially changed. The mechanical part of creating the code is different. Some things have accelerated: I’ve been clamoring for more product-oriented engineers; now that’s no longer just a preference but a must.

I find this reassuring. With everything that’s changing, the foundation great leaders have formed is holding out and will continue to be useful. Rely on it.

Do we need managers?

What people wonder: Now that engineers can achieve so much work using AI, do we really need all these managers? Do we need drastically fewer? Are hierarchies still helpful?

I’ve seen companies get rid of the directors, of team leads, and even of the VPE. I’ve yet to see one where this paid off solely due to AI. Often, it would’ve been a good call even 2-3 years ago given their structure. Similarly, nano teams never made sense to me, and my clients know how vehemently I pushed them away from these setups. At last, many are starting to realize that managerial overhead is real and needs to be managed.

Still, if you have more than ~35-40 engineers, you will likely benefit from having directors between the VPE and the managers. Don’t throw the baby out with the bath water.

Personally, I claim that now that we have a lot more “surface area” in contact with Product, we need a stable management foundation more than ever. The number of tasks, features, and initiatives at play in each period is much greater, and thus managing it all properly is even more important than it used to be. Just winging it has gotten almost impossible to do.

How big should teams be?

What people wonder: Should teams now become very big, because people are more autonomous? Or maybe become much smaller, because each team can achieve so much more?

The earlier reference against nano teams for managerial overhead still holds. So teams shouldn’t be tiny. That’s unhealthy because you have an extremely low bus factor, lack of diversity in approaches, and challenges in enabling genuine collaboration. Of course, if you’ve just started your company, you might have a small team, but that’s about it.

Teams that are too large also don’t make sense. In The Tech Executive Operating System, I called for teams to be around 6 people (plus the manager) for a healthy environment. Having seen some companies push the numbers all the way up to 15 or so recently, I still claim 6-8 is the sweet spot. More than that, and you will see implicit teams being formed anyway, just with lousy management and not enough managerial attention and coaching. That’s a software factory (which I’m not excited about) turned into a sweatshop.

Should we let people maximize output?

What people wonder: How much should people be “optimized” for output? Is any meeting a wasted hour where the agents weren’t getting instructions? Design reviews, code reviews, standup daily meetings all just useless?

This reminds me a bit of my years as a freelancer doing hourly billing. Every meeting felt painful. Some executives, managers, and even engineers seem to be afflicted with the same thinking nowadays, but to a greater extent.

I’ve seen this focus and “streamlining” result in more output in the short term. However, with time, it creates a team that’s not really a team. You’re moving from having teams be silos to teams being a collection of individual silos. “Losing” time to prioritize teamwork is worth it. So, remove useless meetings, but don’t decimate all processes and collaboration systems.

100% utilization was problematic before, and it remains that way now.

How many engineers do we need?

What people wonder: Do we need to hire as we were planning to? Do we now have too many? How many engineers at the founding of a startup?

I think that this one is very dependent on the company itself. Yet some general rules of thumb are useful. First, unless you have a good reason, the founding engineering team should usually be up to 3 engineers until things start getting traction, especially if the CTO/VPE is also involved in development at the start.

Regarding your hiring plans, I see fewer and fewer teams reaching out for the good ol’ “hyper-growth” or “scale-up” mode. Nevertheless, that doesn’t mean they’re not growing. Growth, for most now, is more organic, and that seems to make sense. You shouldn’t aim to 2x-3x the team every year unless there’s clear business benefit from it.

The tough question about whether your org is already too big is not something that an article on the web could answer without knowing your situation. I will say you should be able to clearly see the positive impact each member provides, or the negative impact of no longer having them be part of the team. If their work seems less important to the bottom line, consider whether they can work on something else (e.g., shipping an experiment around a new product) rather than axing them.

Should we hire juniors?

What people wonder: Are juniors still needed now? Are seniors needed, or can we just give juniors frontier models?

Look, if you can hire all the seniors that you need and have them be content with the work given to them, you’re in a good spot. That’s something most companies don’t manage to do, and therefore having some juniors is healthy all around.

I recommend waiting to hire juniors until the 2nd or 3rd “company generation.” At that point, they should be mentored and coached like we’ve always done, being given tasks of increasing complexity with guidance and review. Yes, those tasks will probably not be done by hand; that means new juniors would need to be asked more questions and given guidance around their design decisions and how those are communicated to agents.