Organizational Structure

An eight-person company gets along without a structure. Everyone sits in one room, so who is doing what is visible, and anyone who gets stuck turns around and asks. When a decision is needed the founder makes it on the spot. Draw that company as a picture and you get eight boxes in a row under one name, and the picture tells you nothing you didn't already know.

Past forty people the same questions come back every week. Who does this work, who decides this, and who answers for it if it goes badly. At ten people all three pointed at the same person. At forty the answers separate — and because nobody has written the separated answers down, people call a meeting and rediscover them from scratch each time.

At Pagedeck the first case that made this visible was a notification feature. When someone comments on a document, does the product send an email or only show a badge inside the app? Mia read it as a product call, since it shapes what users experience, and asked Noa for the screen. Noa already had three other requests queued and went looking for someone to order them. Theo read it as an engineering call, because sending mail in volume adds a fixed monthly cost. None of the three was wrong. There simply was no owner for that decision. The feature slipped three weeks, and when the delay was traced afterward, nobody had done anything incorrectly.

Once that happens a few times a month, a company picks one of two answers. The first is to send every ambiguous decision to the founder. That works until Grace's day is entirely meetings about other people's work. The second is to write down in advance where each kind of work belongs, and what gets written down is the organizational structure.

So the term describes wiring rather than seating. The People axis follows a person from the job opening to the exit and splits that path into nine branches, and this one sits at organization for the same reason. Hiring decides who comes in; this branch decides where they sit and how far their judgment reaches.

Nine terms sit under organizational structure, in five branches: what shape the whole is cut into (form), what lines connect people inside that shape (elements), how many people each line may carry (planning), how the result is drawn (representation), and what redrawing it is called (change).

Form covers what the company is cut by, and there are three options. The dividing question is whether you group people who do the same work or people who share the same goal.

1. Functional organization — engineers with engineers, designers with designers. Everyone in a team does the same craft, which makes standards easy to hold and new hires easy to train. The cost is that shipping one feature means collecting a schedule from three separate teams. Pagedeck looked like this at twenty people, and a single feature took four meetings on average to get out.
2. Product-oriented organization — cut by product or by goal instead. The team that owns document editing has product, design, and engineering inside it, so it can ship a feature end to end on its own. Speed improves, but each team drifts into its own way of working, and about six months in a button in team A's area no longer looks like a button in team B's.
3. Matrix organization — overlay both cuts. Noa belongs to a product team and does that team's work daily, while also connecting to whoever owns design across the company to keep quality consistent. It addresses both problems at once, at the price of two people directing one person. If nobody writes down which of the two decides what, the person in the middle stalls.

Elements cover the lines drawn inside that shape. Two are kinds of line and one sets how thick a line may get.

1. Reporting line — who reports to whom. This is the solid line, and reviews, salary, and time-off approvals all travel along it. Which is why the question of who can actually assign work is answered here.
2. Dotted line — a connection that exists because of the work rather than the hierarchy. Noa's link to the design lead in a matrix setup is this kind. A dotted-line partner can ask for standards and give input but does not write the review. Leave that difference unwritten and both sides assume they come first.
3. Span of control — how many people one manager directly carries. This number sets how many layers the structure has. At five reports each, a 45-person company needs nine managers plus two layers above them; at ten each, four managers cover it and a layer disappears. Fewer layers means decisions arrive faster and each manager is spread thinner. Twelve reports at a half-hour one-on-one every two weeks is twelve hours a month, and those hours usually come out of that manager's own hands-on work.

Planning covers how many people a line may carry, and it holds one term. Headcount is the number of people an organization is allowed to have, and it names budgeted positions rather than bodies currently at desks. Telling the engineering org it has three headcount means three engineers may be hired this year and a fourth needs approval. The number is set in advance because organizations size themselves by their own needs: ask any team lead and the answer is that more people are needed, so the count gets divided downward from what the company can carry in total payroll.

Representation covers drawing the decisions so far into something visible, and it holds one term. An org chart is the diagram of teams and reporting relationships in boxes and lines. It is the document new hires open most in their first week, and close to the only view of the structure visible from outside. The recurring failure is that the drawing lags the reality. Two months after a change at Pagedeck, a new hire read the chart and sent an approval request to the lead of a team that no longer existed — less because the chart was wrong than because nobody owned updating it.

Change covers redrawing what was drawn, and it holds one term. A reorganization rewrites team boundaries and reporting lines. It happens when the company has decided to do something next year that no current team is shaped to own, or when work piles on one person for structural reasons. It is expensive, so it is rare. Moving reporting lines changes who writes each person's review, and the unease that follows usually takes a quarter to settle. That is why a reorg announcement carries more than the new picture: the date it takes effect, and who reviews the people whose manager changed mid-cycle. Without those two lines, the following week's one-on-ones are consumed by that question.

The five branches form one chain. Form cuts the large pieces, elements draw the lines between them, planning sets how large each piece may grow, representation shows the result on one page, and change runs the whole loop again. Drop any one and the rest loosen. With no span of control, one lead carries three people and another carries fourteen. With no headcount, the loudest team grows. With no chart maintenance, a team that was dissolved three months ago still appears in the document new hires trust.

"In this reorg, design moves back into one functional team and connects to each product team on a dotted line."

Designers get grouped so quality standards hold, while their day-to-day work still comes from the product teams.

"Grace has eleven direct reports. That span of control is too wide."

The founder's one-on-one time has hit its ceiling, so a management layer should go in between.

"Nothing in the current structure says which team owns that feature."

The work falls between team boundaries, so nobody has picked it up.

Grace ran Pagedeck's second reorg the quarter the company reached 45 people. The first reorg had moved the company from functional to product-oriented, and shipping did get faster, but six months later a different problem surfaced. Button shapes and wording rules diverged team by team, and Noa alone could not review three teams' screens. Engineering hit the same thing twice, with two teams building the same capability separately.

The answer Grace chose was not to reverse the form but to add one line. Designers stayed in their product teams and gained a dotted line to the design lead, who owned screen standards and shared components and nothing else. What went out with the announcement was not a box diagram but three sentences: what the product team decides, what the lead decides, and who decides when those two disagree. The first reorg had shipped only the picture, and the same question had come back more than twenty times over the two months that followed.

The most common error is believing a correct structure exists somewhere. Copying the shape that fast-growing companies use feels safe, and stories about a company switching to product teams and doing well are easy to find. But every form comes with a matched pair of strengths and costs. Functional holds standards and moves slowly; product-oriented moves fast and drifts apart; matrix takes half of each and puts a person between two bosses. Choosing among them is a question of which pain is currently larger in this company, not which shape is best. Chase a correct answer and you import a successful company's shape — but that company adopted it to fix the pain it had at the time, and the pain, not the shape, is what it grew from.

The second error is expecting a structural change to solve the problem. When collaboration stalls and work slips, redrawing boxes and lines is one of the few moves a founder can make immediately, so the hand reaches for it first. More often, though, work slips because nobody owns priority, or because "finished" means something different on each team. Change the structure while leaving those causes in place and the same problem reappears along the new boundaries, and in the meantime people are working somewhere their manager changes every six months. An organization that has been through one reorg hears the next announcement and thinks first about who is leaving, not about what will improve.