Leading an engineering team comes with lots of decisions. Those concerning the structure of the team and the people in it are usually the most challenging: they concern people we care about, aren’t easy to undo, and can be costly. You might be spending too much time on these, looking for the right answer, or allowing yourself too much freedom to reinvent the wheel. Either way, I find that leaders benefit from having “defaults” that make sense without thinking about them too much. The key here is that you can always decide to do something differently, but then you need to have a good reason to do so. Let’s check them out.

New: Want to improve your focus even faster? We’re almost wrapping up 2024. Has your team improved as much as you had planned? Do you see quality improving? Are people becoming noticeably more senior? You and your management team can delegate more and trust people? Join my free live stream Cracking Productivity: Why Can’t Your Team Improve?

Full-Stack over Specialized Roles

Whenever possible, especially when aiming for smaller teams that grow organically, prefer people who aren’t limited to a specific type of work. It’s fine if they have a preference or an area where they shine. I’m more opposed to those who say, “Ew, I don’t do frontend.” Small teams require more flexibility and the ability to shift personnel to where it currently matters the most. Having your engineers fixed to certain types of tasks means they won’t be able to participate in some efforts.

Of course, as you grow, you might realize that there are teams with endless work in a certain area and can hire some specialists. Some areas realistically require hiring specialists (I used to work on teams where we did backend, frontend, and both native iOS and Android apps, however, those are extremely rare).

Less Responsibility Eliminating Roles

This might be controversial, but I recommend waiting before hiring special types of ‘specialists,’ if ever. These are those specialists who seem to take entire responsibilities from others and thus harm the team’s quality. For example, QA engineers should be reduced to a minimum, and when they are hired, they should not be considered those responsible for quality in the team. Similarly, DevOps engineers are not necessarily needed early on and also tend to shun others from touching parts of the platform.

A private case of this is avoiding any ‘architect’ like roles unless you can make a very good case for it. These architects, unless assimilated very well as part of regular teams, eventually make decisions from their ivory towers and limit the other engineers’ ownership and agency.

End-to-End Teams

Continuing with this thread of creating flexible and robust organizations, prefer teams that are cross-functional and capable of delivering work end-to-end as opposed to having dedicated frontend and backend teams. Groups that are responsible for business outcomes, like certain products or KPIs, will have the ability to move the needle faster and create fewer imbalances as the work shifts.

No Useless Abstractions

You know how when you were a junior engineer, you used to introduce all sorts of abstractions everywhere, even where it didn’t really make sense? We’ve all had to maintain systems that had an abstraction layer allowing us to theoretically switch out implementation, but knowing full well there will always only be a single one used. In those cases, the abstraction didn’t really add any flexibility but overhead.

The same happens when you decide to promote a single manager under you, creating a situation where you have a single direct report. Instead of doing so, get to a point where doing an ‘extract team’ refactor still leaves some people reporting to you or refrain from introducing that team. The same applies to all levels: You shouldn’t be a CTO with a single VPE reporting to you, a VPE with a single director, etc.

Teams, not Nano-Teams

As I describe in The Tech Executive Operating System, healthy teams need enough critical mass to warrant existing. Many startups make the mistake of spinning up several nano-teams that comprise a manager and an engineer or two. While that might make you feel important playing with all those titles on the org chart, you’re just playing pretend. Worse, you’re introducing a bunch of overhead for very little gain.

Teams should be spawned around four people as a healthy minimum. From there, teams can grow to around eight direct reports for a single manager (though that’s not recommended for inexperienced managers).

6-Core Core

A nice number for your initial team until you reach PMF and clarity is to have about six people in engineering. Remember that WhatsApp and Instagram were acquired with about a dozen engineers. Contrast that with nowadays when startups are without revenue and dozens of engineers. That’s unhealthy and rarely the right choice.

Your core team, especially if full-stack, as described earlier, should be able to iterate fast and act as a very lean and agile group. Then, once you have some clarity about the direction ahead, expanding the organization makes more sense.

New Teams are Profitable

Similarly, whenever you hire to create a new team, you should have a good reason to do so. Don’t automatically hire for a certain linear growth, as it creates teams that are disconnected from business value. Teams should have a viable business reason to exist.

The simplest example is when the company decides to invest in another product line and, therefore, hires people to support that. Another case would be when you realize that business growth is held back (or will be) by certain tech improvements. Lastly, I’m also a big supporter of increasing the organization to allow more experimentation. However, I object to teams that create projects that require them to grow linearly with the user base. Those are untenable products. For more, check out Profitable Engineering 101.

Shared Work Mediums

You can be remote. You can be colocated. You can have people working from the office X days a week. Whatever it is, I recommend starting with everyone working in the same mode. As hard as hybrid work is, it becomes much harder when there’s a single person who’s always remote. Make your hiring, onboarding, culture, and management all easier by keeping things to a single ‘medium’ of work as long as possible.

Again, remember that these are the defaults. You can change them, like many coders like to do. But you better have a damn good reason to do so.