Department pages: a micro homepage for every team

One of the most frequently asked questions in a company is: "whose job is this?" An org chart shows who reports to whom but not what each team does. That gap is why department pages exist.

The org chart isn't enough

A chart is a map of hierarchy, not of responsibility. Seeing the names under the "Operations" box doesn't tell you whether the supplier contract goes through there or through procurement.

A department page answers that directly: what the team does, which topics come to it, who to contact. It is the kind of information nobody usually writes down and everybody needs.

What belongs on the page?

There's no need for elaborate structure; four sections cover most companies:

1. What we do — the team's area of responsibility, in a few sentences.
2. Who's here — the team list and availability.
3. What to come to us for — typical requests and questions, and who to go to in which case.
4. Resources — documents, forms and processes belonging to that team.

The third is the most valuable and the most often skipped. A sentence like "invoice disputes to Finance, payment plans to Accounting" prevents hundreds of misroutings a year.

The role in onboarding

For a new employee, department pages are a much faster orientation tool than the org chart. Learning "which door to knock on for what" in the first week is more useful than memorising who's who.

That's why adding "read your own department's page and the three you'll work with most" to the onboarding task list works. We cover the process in our onboarding article.

The natural foundation for targeting

The department structure isn't just a page; it's also the basis for content targeting. An announcement can go only to Finance, a document only to the field team, a training only to new managers.

Having that relationship in place raises the precision of the whole system: less content goes to everyone and read rates rise. We detail the logic in our announcements article.

Who writes it, who keeps it current?

Having HR write department pages is a common mistake; the result is generic text. The page should be written by the team itself — they know best what they do.

Responsibility for updates should sit with the department manager. A short review once a year, ideally during budget season, is enough for most companies; areas of responsibility change at about that rate.

The team list should be automatic

Maintaining the list of people on the page by hand is a guaranteed route to staleness. The list should be derived automatically from employee data: when someone's department changes, the page changes.

That is another example of why directory synchronisation is valuable — covered in our employee directory article.

What about matrix structures?

Where one person belongs to two teams or moves by project, a single department assignment falls short. Two practical approaches: record the person's primary department and build additional links through communities or projects.

Trying to bend the department structure to fit a matrix usually increases complexity and breaks targeting. The structure should stay simple; flexibility should come from other modules.

Department announcements

What keeps a page alive is the team's own announcements accumulating there. Finance's month-end closing reminder doesn't need to go to the whole company, but it makes sense on the Finance page.

That also reduces announcement inflation: information relevant to only a few teams leaves the general feed and goes where it belongs. The main feed stays limited to what genuinely concerns everyone.

Measurement

• Page completeness — how many departments have an actually written page?
• Views — which department pages get searched for and opened?
• Currency — the number of pages untouched for a year.

The second produces an interesting by-product: the most-viewed department page is usually the team that receives the most questions. That is a direct signal that its processes need explaining better — and it points at the next page to write in the knowledge base. We cover that side in our wiki article.