Ask HN: What is the best structure for software development teams?

> Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. — Melvin E. Conway

Design your organization to mirror your system and you'll have the easiest time.

Your questions are hard to answer without details about your company. We don't know what you do, how you do it, how many people you have, what their experience is, etc.

The most important thing, IMHO, is autonomy. Small autonomous teams can make a lot of progress in a small amount of time, because they can focus on getting things done rather than coordinating (most teams of one don't need any team internal coordination, only external coordination). But not all projects can be broken into small, autonomous teams. And not all people have the experience and know how to work autonomously. As you grow, it's hard to hire only seniors ready to work autonomously; you'll need to train juniors as well, but the right juniors pick up autonominity quickly with help.

If you've got teams of one, maybe two people, an engineering manager per team is silly. Otoh, a team with ten engineers probably needs one. Depends on the team and manager(s). One manager can manage a few small teams too.

One front end per platform (i.e. if you have web, Android, iOS, you have three FE devs). Two back end. One PM.

That's one team. If you have enough resources for two teams like this, add another. If not, don't.

Then an experienced designer, team lead, engineering manager, business manager. Usually with a lean team, the CTO is all the managers too, and some FE person is the designer.

I'd have a dedicated designer if at all possible. Designers are probably some of the best ROI from a business perspective. Outsource if you have to.

If you have multiple teams, then they should have ownership over their own territory. One way we've split it is that Team A works on core functionality (deeper), Team B works around core functionality (broader), Team C does experimental shit with experimental technology and new partners and no users nor deadlines.

The costs of having a process for two people work on the same block of code is very high, sometimes over double having one person. If you're building to scale to a hundred engineers, you lose the benefits of being a startup.

Sometimes there's a burst of work. You can add more hands and hire contractors. But I don't recommend changing the process unless you need to. Add code review as a process once you have 3 people on the same code base.

There is no best without a defined context, and even then probably no singular best. A good book that goes into this topic and othres is The Psychology of Computer Programming by Weinberg. The "best" is impossible to provide you.

Should you have 1 person in each major role? Shared responsibilities? Should people "own" some modules or should it be community/team owned? Who knows, ask yourself and your people. Be deliberate in your setup, and reconsider it as time goes on. Always remain flexible, setting a team structure in stone and never budging even when it doesn't work is a great example of insanity (to be kind) or stupidity (to be unkind) in action.

https://leanpub.com/thepsychologyofcomputerprogramming

I would ask your team what they want. But as a starting point, I’d suggest each team be completely self sufficient (ie not dependent on any other team), and whatever size that allows, do it. As a general rule it’s a manager and a few engineers. Some teams may need a designer, or a project manager, etc. Or for a time, teams may need to share a single designer or PM.

Most importantly, get regular feedback from the teams about what’s working, what’s not, and what they want to see changed.

Are you familiar with Amazons “two pizza team”? I’ve not run teams that way specifically, but it does jive with my experience of well run teams.

Divide into squads, assign each squad a tech lead who is a hands-on contributor

The Mythical Man Month explains it best