Every Startup Team Org We Tried (And Why They All Broke)
There's no perfect team structure, just different ways to be stuck.
Last month a founder asked us: "How should we organize our engineering team?"
We laughed. Not because it's a bad question. But because we've watched teams try every answer and they all break eventually.
We're 14 people at Norveon. Everyone's a generalist. Works for us. But we've worked with a client who went from 8 engineers to 32 in two years. Got to see every reorganization play out. Here's what actually happened.
Split by Tech Stack
Around 10 people, most teams split by technology. Frontend with frontend. Backend with backend. Mobile together.
This client did it in June 2023. 18 engineers total. React web app, Swift and Kotlin mobile apps, Node.js backend. Three teams.
Worked for three months.
Why It Broke
Every feature needed all three teams.
New onboarding flow? Backend builds APIs, frontend builds forms, mobile updates apps. You're coordinating three teams for one feature.
Frontend complained APIs weren't ready. Mobile complained APIs were built for web. Backend had no idea why they were building half these endpoints.
Nobody owned any part of the product. Everyone touched everything, so nobody really understood how anything worked.
By month four, every standup was "waiting on backend" or "blocked by API changes."
Squads (Like Spotify)
Next try: organize around product areas.
Squad A: user management. Squad B: core features. Squad C: billing. Each squad got frontend, backend, and mobile people.
Felt way better. Teams owned their area. Could ship without waiting on others.
Lasted a year.
What Killed Squads
Nobody worked on technical stuff.
React Router upgrade sat in backlog for eight months. Test suite went from 3 minutes to 55 minutes. Whose job was it to fix? Nobody's.
The iOS dev in Squad A had nobody to talk to about iOS problems. Squad B picked one state library, Squad C picked a different one.
Tech debt piled up. Every squad was measured on features, not code quality.
By month 11, three engineers were burned out.
Adding Chapters
So they added chapters. All frontend people in a Frontend Chapter. All backend in Backend Chapter.
Chapter leads pushed for 20% time on technical work. Framework updates, knowledge sharing, tech decisions.
First two months were great. Updates got done. Tech talks happened.
Then the fighting started.
The Chapter Problem
Product managers vs chapter leads. Every sprint.
"Why is Alice updating dependencies instead of building features?"
"Why did Bob skip sprint planning for a chapter meeting?"
They started tracking percentages. Alice: 23% chapter time. Bob: 11%. Everyone hated it.
Engineers got pulled two directions. Squad PM wants the feature Friday. Chapter lead wants you in a workshop. Pick one.
After six months, people started quitting.
Platform Team
Next: dedicated team for technical work.
Moved the backend lead plus two mobile engineers and one frontend engineer.
This left the product squads short. Squad A down to one backend engineer. Squad B lost half their mobile capacity.
But the fighting stopped. Platform team did tech work. Product squads built features.
Except.
New Problems
The backend lead never had time to help their old squad. Squad A fell behind. Their one backend dev was drowning.
Mobile engineers kept getting pulled back to product work. Clients complained about iOS and Android being out of sync.
The frontend engineer on the platform team wanted to quit after three months. Updating libraries isn't as fun as building features.
Worst part: other engineers stopped caring about code quality. "Platform team will fix it" became the excuse for messy code.
Platform team started adding more process. Created resentment between the "architects" and "people doing real work."
Temporary Project Teams
Killed the platform team. New plan: temporary teams for big projects.
Project Alpha: React upgrade. Three frontend people, two months.
Project Beta: rebuild APIs for mobile. Two backend, two mobile, two months.
Project Beta took four months instead of two. Wrong scope. Too late to cancel.
Project Alpha lost someone after one month. Added a replacement. Onboarding took three weeks. Project ran seven months instead of two.
The engineer who stayed all seven months burned out. Quit a month after it finished.
Project Beta got canceled at month three. Too complex.
Six months later they needed to change something from Project Alpha. Team was gone. Original engineer quit. Nobody knew how it worked.
Staff Engineers
Current setup: promoted two people to staff engineer. One backend, one frontend. They float around. Help where needed.
Brought back chapters. 20% time rule. But no tracking this time. Just trust.
Been running eight months.
Backend staff helped Squad A until they hired someone. Frontend staff led the React update.
Staff engineers run monthly "update days." Few people from each squad spend a day updating dependencies and adding tests.
Chapters meet every two weeks. Knowledge sharing. Tech decisions. No work assignments.
Not perfect. Staff engineers are stretched thin. Hiring them is hard.
What We Learned
Every structure breaks eventually.
Tech teams break from coordination overhead. Squads break when tech work gets ignored. Chapters create conflicts. Platform teams disconnect from reality. Project teams miss deadlines.
We're 14 people at Norveon. Everyone's a generalist. Works at our size. Wouldn't work at 50.
This client is at 32 engineers now. Already seeing cracks in the staff engineer model.
If You're Doing This
Don't copy Spotify. Don't copy Google. Their context isn't yours.
Fix what's broken now. Not what might break at 100 people.
If coordination is the problem, don't split by tech stack. If tech debt is piling up, don't use pure squads. If people are burning out, maybe skip the chapter model.
Try something. Give it six months. Watch for problems. Change when it's clearly broken.
Team structure isn't something you solve. Just different tradeoffs at different sizes.
Currently helping another client figure this out. Ask us in six months if it worked.
