What is a cross functional team?

A cross functional team pulls people from different departments, such as engineering, marketing, sales, and support, to work toward one shared goal instead of each department working alone.

Members keep reporting to their usual managers while also answering to the team's shared objective. A full one page charter you can copy sits later in this piece.

What you need before you start

Before you pull people together, write down the actual goal in one sentence and name who owns the final call if the group cannot agree. Skipping this is a fast way to end up like most of the teams in a Stanford lecturer's analysis for Harvard Business Review, which found close to three in four cross functional teams underperform, and traced most of that back to unclear purpose and unclear decision rights rather than a lack of talent in the room.

If you are leading one for the first time, expect the hardest part to be authority, not scheduling: most of the people in the room do not report to you. If you run outbound sales, the same problem shows up the moment a sales engineer joins an SDR's first call to cover a technical question, since an SDR to account executive handoff only stays consistent when both sides agree on what happens next.

A small team of eight or ten people can often skip formal roles and assign responsibility out loud instead of writing it down. A larger organization usually needs the written version, because too many people will assume someone else owns the decision.

What actually makes a team cross functional

What happens: A cross functional team brings people from separate departments into one working group so a task that touches every one of those departments does not stall while it gets passed between them. The opposite of a cross functional team is a functional team, where everyone reports to the same manager and stays inside one department. Some project tracking tools shorten the whole concept to XFN in labels and filters, which is the same idea under a shorter name.

Here is how the three setups people mix up most often actually differ.

The functional team stays inside one department indefinitely, the cross functional team pulls several departments together for as long as the goal requires, and the task force forms around one narrow problem and disbands once that problem is closed.

Cross functional versus a task force

A task force is usually temporary and built to fix one specific problem. A cross functional team can be temporary too, but what defines it is the mix of functions in the room, not how long it lasts.

One example of a cross functional project team, a launch group pulling in product, engineering, and marketing for six months, is still cross functional even after it ends, while a task force investigating one outage is not cross functional if everyone on it comes from the same engineering group.

Done when: everyone in the room can name which department they represent and what decision they are there to make.

Who usually sits on a cross functional team

What happens: Membership follows the goal, not a fixed org chart. A product launch usually needs someone from product, engineering, marketing, and sales. A pricing change usually needs finance, sales, and legal in the room instead. Each cross functional team member keeps their normal job and adds this work on top of it, which is why the group rarely meets every day.

The strongest members are what recruiters sometimes call T shaped: deep in one discipline but able to hold a real conversation in the others.

A cross functional engineering team without anyone who can explain a decision to marketing in plain terms will spend more time translating than building, which is really a cross functional team communication gap in disguise.

Common cross functional team examples by goal:

• A cross functional product team pairs product management with engineering and design.

• A cross functional marketing team pairs campaign owners with sales and, on paid launches, finance.

• A cross functional sales team pairs an account executive with a sales engineer and, on named accounts, marketing, the same cross department mix that makes sales enablement work as a shared function across sales, marketing, and product rather than one department's job alone.

• A cross functional development team pairs backend and frontend engineers with a single product owner who prioritizes the list.

Done when: every function affected by the outcome has one named representative, not a rotating cast.

How the team gets structured

What happens: Most cross functional teams settle into a core group and an extended group, even when nobody calls it that. The core team meets regularly and includes one person per function who can commit real time. The extended team gets pulled in for a specific decision or a review, but does not sit in every meeting. Keeping that line explicit is what keeps a twelve person team from turning into a twenty person meeting that cannot agree on anything.

This sits inside a larger question of how the organization is built around the team. A pure functional structure keeps every person inside one department with one manager, and cross functional work happens informally, if it happens at all, which is exactly the setup that grows organizational silos.

A matrix structure, the approach behind what is often called matrix management, gives each person two managers, one functional and one for the project, and puts the cross functional relationship on paper. A dedicated cross functional organizational structure moves people, or their time, fully into the team for the length of the project. Account based marketing programs are a common example of the matrix version, since aligning sales and marketing around one target account list only works when both functions share real decision making power, not just a meeting invite.

Done when: you can point to who is in the core group and who is only in the extended one.

How big a cross functional team should be

What happens: There is no fixed number, but the pattern that shows up across fast moving companies is a small core group. Amazon's own executive materials describe its two pizza team approach, and put the ideal team at under 10 people. That number holds up for cross functional teams for a similar reason: past a certain size, coordination costs start to outweigh the extra hands, since every additional person adds one more line of communication that has to stay open.

A core group of five to eight people, each representing one function, tends to move faster than a core group of fifteen, even when the larger group has more total expertise in the room. The extended team described above can be as large as the work requires, since those people are not in every meeting.

Done when: the core group is small enough that everyone in it can commit to one recurring meeting time without a weekly scheduling conflict.

How decisions actually get made

What happens: The most common failure in a cross functional team is not lack of effort, it is an unclear decision right. Two frameworks show up again and again to fix this. A responsibility assignment matrix, usually called RACI, assigns each task one person who is responsible for doing the work, one person who is accountable for the outcome, stakeholders who are consulted before a decision, and people who are only informed after it is made. The accountable role should always be one person, not a group, or the same problem returns under a new name.

A newer framework called DACI splits the same idea slightly differently: a driver who owns the process of getting to a decision, an approver who has the final call, contributors who supply information, and people who are only informed. One writeup of the DACI framework describes the approver as the one person who holds final decision authority, which is the detail most cross functional teams skip and then argue about later.

Either framework works. What does not work is leaving the accountable or approver role blank, which is the single most common reason a cross functional team stalls on a decision it already has enough information to make.

Done when: every open decision on the team has exactly one name next to accountable or approver, not a department.

A one page charter to copy

Fill in each line of this team charter before the first meeting, then keep it visible during every one after that. A blank document works fine, no special software is required.

Goal (one sentence):
Functions represented:
Core team members and their function:
Extended team members and when they are pulled in:
Decision owner (accountable or approver) for each open question:
Meeting cadence and length:
How success will be measured:
Date this charter was last reviewed:

Done when: every line has an answer, not a placeholder, and the accountable name matches a real person in the room.

How you know it is working

What happens: A cross functional team is working when decisions that used to take three separate email threads now take one meeting, and when someone outside the group can explain what it is trying to do in one sentence. Teams that formalize this often borrow OKRs, objectives and key results, so the shared goal has a small number of measurable results attached to it instead of staying a vague mission statement.

Product Leadership co author Richard Banfield has described the shared trait among the highest performing teams he has studied as working across functions, sitting close together, and making calls without waiting on permission from outside the room.

A useful early warning is depth versus width: if the same three people are doing all the real work while the rest of the roster only shows up to meetings, the team has a smaller working size than the roster suggests. Watch the count of who actually replies with a decision, not who is on the invite.

Done when: you can point to one metric the team is accountable for that existed before the team did.

Common ways cross functional teams stall

Nobody owns the decision. The last cross functional group I sat on had six people from six different functions in the room, and it took three separate meetings across nine days to agree on who actually owned one pricing call. Every function contributed an opinion, nobody had the accountable role, and the group argued through the same choice each time it met. The fix is the one line item from the charter above: name a single accountable or approver person before the next meeting, not after it.

The team quietly turns into a status update. Meetings fill with updates instead of decisions because no one prepared a decision for the group to make ahead of time, which turns a working session into a status call with more attendees than it needs.

Remote members go quiet. On a distributed cross functional team, the people who are not in the room where the loudest conversation happens tend to drift out of decisions entirely. One long running discussion among engineers and managers about clarifying roles on a cross functional team points at the same root cause: without a shared, written understanding of who cares about what, even a well meaning team ends up talking past each other. The four most common warning signs are worth keeping somewhere visible.

Keep that checklist next to the charter, since catching one of these signs early costs less than rebuilding trust after the group has already stopped meeting on time.

FAQs: What is a cross functional team

What is the purpose of a cross functional team?

The purpose is to move a task or a goal forward without waiting for it to pass sequentially through separate departments. Instead of engineering finishing a build and then handing it to marketing weeks later, both functions work on the same timeline from the start.

Who leads a cross functional team?

Cross functional team leadership usually falls to one person named team lead, separate from anyone's regular manager, who owns the meeting cadence and the accountable decisions rather than any one department's priorities. The role works best when it goes to someone with credibility across functions, not necessarily the most senior title in the room.

What is a cross functional team in agile or scrum?

In agile and scrum, a cross functional team usually means one scrum team that includes every skill needed to ship a feature end to end, such as a developer, a tester, and a designer, without depending on people outside that team.

Is a cross functional team the same as a matrix team?

A cross functional team is not quite the same as a matrix team. A matrix team describes the reporting structure, where a person has both a functional manager and a project manager. A cross functional team describes the mix of people in the room. Most matrix organizations run their work through cross functional teams, but a company can run cross functional teams without a formal matrix structure.

What are the biggest challenges of a cross functional team?

The two that show up most often are unclear ownership of decisions and competing priorities, since each member still answers to a department goal that may not match the team's shared goal. Both are addressed directly in the charter and troubleshooting sections above.

Putting the charter to use

Copy the one page charter above into whatever document your team already uses, fill in the accountable name for every open decision, and bring it to the first meeting instead of writing it during the meeting.

Good cross functional team collaboration looks like fewer status meetings and more finished decisions, and a team that starts with a named goal and a named decision owner spends its first few weeks building the thing it exists to build instead of figuring out who is allowed to decide.