Cross-functional Team

Companies used to be split by craft. There was a product team, a design team, an engineering team, a quality team, and every person belonged to the team that matched their job title. Grouping people that way looked sensible: you learn from the person next to you, and your manager actually understands your work well enough to evaluate it.

The trouble is that work doesn't travel along craft lines. Adding a single filter to a search result started in the product team, moved to design, passed through engineering, and ended in quality. At every handover the work turned into a document, and whoever received it put that document at the back of their own queue.

Planning meetings all sounded the same. Design would come back next week, engineering had it slotted for the cycle after that, and a task with ten days of actual work in it took two months on the calendar. The rest was waiting, and while everyone waited the original requirements aged.

A team that had committed to a two-week sprint could not move at all inside that structure, because three separate teams almost never line up inside two weeks. Cross-functional teams are what you get when you erase that queue by drawing the team boundary around a goal instead of around a craft.

Put everyone required to ship something on the same team from the start, and remove the stretch where work leaves the team and comes back. That's the whole mechanism: work that begins inside the team also ends inside it.

The mix depends on what the team owns, but it usually looks like this.

1. One product manager (PM) — decides what gets built and why, and sets the order.
2. One product designer — turns the problem into screens.
3. Three or four engineers — covering both the interface and the server. Leave one side out and the team ends up waiting on another team anyway.
4. One person on quality assurance (QA) — finishes the pre-release checks inside the team. Some teams share this work instead of staffing it.

Reporting lines are the part that matters, which is why seating people together isn't the same thing. If the designer still belongs to the design team and follows its priorities, then the day two urgent things collide, that designer works on the other team's item first. The queue comes straight back.

The same logic applies to decisions, not just to people. A team that has to escalate every scope change to a committee outside it is waiting on that committee, even though the roster looks complete. Giving the team the authority to cut a feature in half is part of the same design.

Teams usually land between five and nine people. Fewer and some role is missing; more and communication overhead rebuilds itself inside the team, which defeats the split.

There's one test for whether the structure actually holds. Take a piece of work the team owns, trace it end to end, and count how many times it stops for another team's approval or schedule. Zero means the team is cross-functional. One or more, and that stop is what sets the team's pace.

It sits underneath any organization that wants to ship repeatedly on a short cycle. Iterative development — passing over the same screen several times and improving it — only works if product thinking, design, and implementation all fit inside a single pass.

It comes up most often when the org chart is being redrawn. Converting craft teams into goal teams is exactly this move, and plenty of companies use the word squad for the result. Reorg documents phrase it as moving one designer onto the search squad.

The dividing line is usually a flow the user experiences. Search, document editing, and checkout each feel like one thing to the person using the product, so each gets a team. Splitting by interface and server instead means two teams touch every feature, and the queue returns.

It also shows up as a constraint when a new area gets funded. Before a company starts a payments effort, someone has to ask whether the new team can ship without borrowing an engineer from an existing one, and the answer decides the hiring plan.

Job postings carry the signal too. "You'll work on a cross-functional team" means the role isn't handed finished specs to implement — you're in the conversation about what to build from the beginning.

"Can we finish this inside the team, or do we have to file a request with another one?"

The moment work leaves the team the timeline slips by weeks, so that's the first thing to check.

"This is a cross-functional team in name only. The designer is splitting time across three teams."

One person spread across teams means the waiting never actually went away.

"To make checkout a cross-functional team we need one more backend engineer."

Finishing inside the team requires filling the missing role.

Pagedeck converted craft teams into goal teams shortly after its Series A. Mia, Noa and Theo ended up on one team owning the document editor, and work that would once have gone out as a design request now happens in a question Mia asks Noa directly. On the afternoon a screen gets reworked, Theo can say "that structure will make saving slower" and the plan changes on the spot.

Work outside the team is still slow, though. Checkout belongs to a different team, so anything touching payments puts Mia back in someone else's queue. How much to put inside one team is the only real design choice here.

The most common mistake is assuming that several roles in one meeting makes a cross-functional team. The room looks identical, so the confusion is fair. But the test is reporting lines and priorities, not attendance. A designer who still sits in the design team and follows its order will pick up the other team's work whenever two urgent things collide, no matter how many standups they attend. Six months after that kind of reorg, someone says the names changed and the waiting didn't.

The other misreading is that one person is supposed to cover every craft. "Cross-functional" sounds like a description of an individual, but it describes the makeup of a team. Designers still design and engineers still build — they just do it on the same team. Demand all of it from each person and you get people working broadly and shallowly, and the quality of the output drops with them.