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.
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.
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.
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.
Most importantly, get regular feedback from the teams about what’s working, what’s not, and what they want to see changed.
The Mythical Man Month explains it best