Functional Organization

When eight people share one room, nobody has to decide on a shape. Everyone knows who is working on what, and a decision takes one swivel of a chair. Past twenty people, that arrangement is the first thing to break.

What breaks first is consistency. If three designers are each attached to different work, the same product ends up with three kinds of buttons, and a new designer has nobody sitting nearby who can explain how this company has drawn things so far. Engineering has the same problem. With no one to ask about how code is meant to be written here, everyone writes it their own way, and six months later reading a colleague's work costs a day.

It surfaces in meetings like this. Someone asks who sets the design standard, the room goes quiet for a moment, and the answer comes back as "so far everyone has decided for themselves." The silence isn't about a missing person. It's about a missing seat.

A functional organization is the simplest way to create that seat. Put everyone who does the same work on one team, and the person who sets the standard sits next to the people who apply it. It is the oldest way of cutting up a company, and the shapes that came later exist to solve the problems this one creates once a company grows.

The company is cut along the kind of work people do. Engineers report into engineering, designers into design, marketers into marketing, and each group is led by someone who has done that job for a long time.

Four things follow from that cut.

1. Membership — people belong to the group that matches their craft. In a 45-person company that might be 18 in engineering, 6 in design, 5 in product, 6 in marketing, 7 in sales, and 3 in operations.
2. Reporting line — who reports to whom. Reviews, salary, and time-off approvals travel along this line. A designer's review is written by the head of design no matter which product they worked on, and because there is only one such line, nobody has to write down who decides what.
3. How work arrives — shipping one product feature means borrowing people from three groups in sequence. Product writes the plan, asks design for a slot, then takes the result to engineering and asks for another slot.
4. What it looks like — draw an org chart and you get boxes labeled by craft standing side by side under the founder, with people hanging below each. Information travels up and down those boxes easily and sideways badly.

The cost shows up in the third item. Pagedeck had this shape when it was twenty people, and shipping one feature took four meetings on average. Hunting for a day when all three groups had room on the calendar regularly pushed the start out by two weeks.

The shape fits best when the company is small and there is only one product to build. The cost of crossing sideways shrinks as the company shrinks, while the benefit of a shared standard stays the same at any size.

In practice it turns up in three places.

1. Companies under fifty people — with a single product, no group ever has to split its attention across several of them. At this size, lining up three calendars takes one meeting.
2. Disciplines where being correct decides the outcome — finance, legal, and people operations stay functional even in companies of several hundred, because getting a rule wrong puts the whole company at risk. No one runs three separate payroll teams, one per product.
3. Bringing a new craft into the company — if you have just hired your first two data analysts, keeping them together while they agree on tools and standards beats scattering them across products.

How many people each group may hire comes down as headcount, the budgeted number of seats a group is allowed to fill. In a functional organization that number is handed out by craft, so the argument over three engineering seats versus one design seat happens between disciplines.

"We're still a functional org, so you'll have to check that date with the engineering lead separately."

One person can't answer the question; each group has to be asked for its own dates.

"On design quality alone, things were better when we were functional."

The output was more consistent back when one place set the standard.

"Before anything else, this reorg has to decide whether we stay functional or cut by product."

A request to settle the shape of the company before moving on to details.

At Pagedeck the phrase came up most often in the reorg discussions around the time the company reached 45 people. Mia brought a record showing that three features had each slipped by two weeks last quarter, and that every one of those delays was time spent waiting on another group's schedule. Theo argued the other side: break engineering apart and there is no longer anyone holding the code standard, and a new engineer has nobody on their team to ask.

Grace didn't pick one of the two. She picked the dividing point instead — crafts attached to a product move to the products, while finance and legal stay where they are. Very few companies run one shape end to end, and the real decision is where to stop being functional.

The most common misreading is that this shape is simply outdated. Every story about a fast team seems to feature a product-based structure, so the conclusion comes easily. But the shape loses on one thing, speed, and wins on two, standards and growing people. Split a twenty-person company into three product teams and each one gets a single designer, who then decides alone and gets things wrong alone. Choosing a shape is not about good and bad. It's about which cost the company can carry right now.

The second misreading is that a functional organization can't collaborate across crafts. The chart is divided by discipline, so people assume the work is too. In practice, each piece of work pulls people from several groups into a cross-functional team — a group holding every craft needed to ship, assembled without changing anyone's reporting line, agreeing only on how much time each person gives. The catch is that such a team dissolves when the work ends, and the context it built dissolves with it. The problem isn't that collaboration fails; it's that it restarts from zero every time.