Ask HN: What is the best structure for software development teams? | Hacker News Reader

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

5 pointssebrind8 comments

As a growing early stage startup, we are gradually reaching the size where splitting up into multiple teams will become necessary.

That has presented itself with a wide range of questions:

- how many members per team and which roles?

- what should each team focus on?

- should all teams have an engineering manager?

- is there a transitory “best structure”?

Would be great to get inputs on what you have seen work well - both at scale but also in early stage startups.

View on HN

> 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.

Thanks for responding. Some details about us:

- we are building open-source software (medusajs.com); our thinking around breaking into two teams is that team 0 works on core and team 1 works on plugins + tooling

- we are currently 7 in the engineering team (includes CEO and CTO; CEO will transition into more PM work than hands on development)

- we plan to hire 5 more engineers over the next 3-4 months

- teams would work autonomously with some guiding principles to follow

I think your inputs align well with our own thinking

At 10 practicing engineers, with pretty good autonomy, your CTO can probably do engineering management. If that doesn't work, seek a manager hire (an internal candidate if there's someone who wants to switch roles), to do some or all of the management. I wouldn't jump to two managers at that size, unless it becomes aparrent that it's needed.

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

Reply on news.ycombinator.com