How to onboard a new hire without writing a wiki

Every company has the same problem with onboarding. Somewhere between "welcome to the team" and "here's your first ticket," there is a gap filled with scattered documents, half-remembered Slack threads, and a wiki that was last updated eight months ago. The person responsible for onboarding knows this. They also know they do not have the bandwidth to fix it, because they are busy doing the work that the wiki is supposed to describe.

This is the fundamental tension. The people who hold institutional knowledge are the same people who are too occupied to document it. Writing a wiki requires carving out days or weeks to capture processes, decisions, architectural reasoning, and tribal knowledge in a format that is clear enough for someone who has never seen any of it before. Then it requires maintaining that wiki as the organisation changes, which it does constantly. Most teams try this once, fall behind within a quarter, and quietly abandon the effort.

The result is predictable. New hires spend their first weeks piecing together context from old pull requests, outdated Confluence pages, and interrupting colleagues with questions that have been answered dozens of times. Research consistently shows that engineering onboarding takes three to six months at most companies, and a significant portion of that time is spent simply finding information rather than learning it. The cost is substantial, both in the new hire's ramp time and in the productivity lost by the people fielding their questions.

There is another way to approach this. Rather than asking humans to write and maintain onboarding documentation, you can let the documentation assemble itself from the knowledge your team has already created.

The problem with wikis as onboarding tools

Wikis were designed for a world where documentation was the bottleneck. The idea was sound: give everyone a place to write things down, and over time you build a comprehensive knowledge base. In practice, wikis become graveyards. Pages go stale. Nobody knows which version of a process document is current. Search is poor, so even when good documentation exists, new hires cannot find it.

The deeper issue is that wikis separate knowledge from its source. When an engineer explains a system's architecture in a design document, that explanation lives in Google Docs. When a product decision is debated and resolved, the reasoning lives in Slack. When a deployment process is refined, the latest steps live in a runbook that may or may not be linked from the wiki. The wiki becomes a layer of indirection that requires constant manual synchronisation with the places where knowledge is created and updated.

For onboarding specifically, this creates a painful cycle. Someone writes an onboarding guide. It works well for the next hire. By the third hire, parts of it are outdated. By the fifth hire, the guide is more misleading than helpful, and the team lead ends up walking through everything in person again.

Letting documentation write itself

Self-writing docs take a different approach. Instead of asking someone to sit down and author an onboarding guide from scratch, Fabric connects to the tools your team already uses, including Google Drive, Notion, Confluence, Slack, GitHub, and more than 50 other sources, and synthesises what it finds into structured documentation. The onboarding guide output type is built for exactly this purpose. It pulls from your existing design documents, decision logs, process descriptions, and conversation history to produce a guide that reflects how your team works right now, not how it worked when someone last had time to update the wiki.

This works because the underlying model, Exabase M-1, is designed to reason across large volumes of connected information. It does not simply copy and paste from your documents. It identifies the relevant context, resolves contradictions between older and newer sources, and produces documentation that reads as though a knowledgeable team member wrote it with care. When your processes change, the documentation can be regenerated to reflect the current state of affairs.

The difference from a traditional wiki is structural. The wiki asks humans to be the synchronisation layer between working knowledge and written knowledge. Self-writing docs remove that layer by going directly to the source material.

Making company knowledge searchable from day one

Even the best onboarding guide cannot anticipate every question a new hire will have. At some point, they will need to look something up, and the quality of that experience determines how quickly they become productive.

Most companies offer new hires a combination of search tools, none of which work well in isolation. Google Drive search finds documents but not Slack conversations. Slack search finds messages but not the Notion page that supersedes them. Confluence search is Confluence search. The new hire does not yet have the institutional vocabulary to construct effective queries in any of these tools, so they default to asking a colleague.

Fabric's semantic search works across all connected sources simultaneously. A new hire can type a natural-language question and get results from Google Docs, Slack, Notion, GitHub, and every other connected platform, ranked by relevance rather than by recency or keyword match. This matters because new hires do not know the right keywords. They do not know that the deployment process is documented in a page called "Release Runbook v3 (FINAL)" rather than something sensible. Semantic search bridges that gap by understanding what they mean, not just what they type.

Combined with Fabric's AI assistant, which provides answers with citations back to the original sources, new hires can get clear answers to specific questions without interrupting anyone. The citations are important. They let the new hire verify the answer against the source material, building their familiarity with where knowledge lives in the organisation. Over time, they learn the landscape of your documentation not by being handed a map, but by exploring it through their questions.

Fabric Tag: answering questions where they are asked

New hires ask questions in Slack. This is true regardless of what other tools you give them, because Slack is where they are already spending their time and where the social barrier to asking feels lowest. The problem is that answering questions in Slack creates ephemeral knowledge. The answer scrolls away, the next person with the same question cannot find it, and someone ends up answering it again.

Fabric Tag works inside Slack. When a new hire posts a question, Fabric Tag can respond with an answer drawn from all of your connected knowledge sources. It finds the relevant design document, the Slack thread where the decision was made, the Notion page with the current process, and synthesises them into a clear response. The new hire gets their answer quickly. The rest of the team does not get interrupted. And the answer is visible in the channel for the next person who has the same question.

This changes the economics of onboarding questions. When every question requires a human to context-switch, search their memory, and type out a response, teams naturally discourage questions, either explicitly or through the subtle friction of delayed responses. When questions are answered quickly and automatically from existing knowledge, new hires ask more freely, learn faster, and develop confidence sooner.

Scoped access for onboarding without security concerns

One reasonable concern with giving new hires access to an AI that can search across company knowledge is security. Not every new hire should have access to everything on day one, particularly contractors or employees in roles with limited scope.

Fabric handles this through its agent access model, which allows scoped, time-limited access to specific knowledge domains. You can configure what a new hire's onboarding assistant can see and for how long. An engineering hire might get access to technical documentation, codebase context, and engineering processes, but not to financial planning documents or HR records. A contractor might get access only to the project they are working on.

This extends to how external AI tools interact with your knowledge. Through MCP and agent access, you can allow new hires to access Fabric's knowledge base from within ChatGPT or Claude, the tools they may already be comfortable using. The access is controlled and auditable. Your knowledge stays in Fabric's secure context vault, and you decide exactly what is available to whom.

What this looks like in practice

Consider a new engineer joining your team on a Monday. Before they arrive, you connect Fabric to your Google Drive, Slack, GitHub, Notion, and Confluence. Fabric's self-writing docs generate an onboarding guide that covers your team's architecture, development workflow, deployment process, and key contacts, all drawn from your existing documentation and conversations.

On their first day, the new engineer receives access to this guide and to Fabric's search and assistant. When they want to understand why a particular service is structured the way it is, they search and find the original design document alongside the Slack discussion that led to a key trade-off. When they want to know how to set up their local development environment, they ask in Slack and Fabric Tag responds with the current steps, citing the latest runbook.

By the end of their first week, they have absorbed context that would normally take a month of interrupting colleagues to gather. They have not needed someone to sit with them and walk through everything. The senior engineers on the team have not lost days to answering repetitive questions. And the "onboarding documentation" did not require anyone to spend a week writing it.

The cost of not solving this

The real cost of engineering onboarding is not just the new hire's salary during their ramp period. It is the productivity drain on the existing team. Every question a new hire asks takes a senior engineer away from their work. Context-switching is expensive. A fifteen-minute interruption often costs an hour of productive time when you account for the time needed to regain focus.

Multiply this across every new hire, every quarter, and the numbers become significant. A team that hires four engineers a year might lose the equivalent of a full engineer's output to onboarding overhead. Reducing onboarding time is not just a nice-to-have. It is a meaningful improvement to team capacity.

Fabric's Teams plan is $125 per month with no per-seat pricing. For a team of any size, this is a fraction of what onboarding inefficiency costs in lost productivity. You connect your sources once, and every subsequent hire benefits from the accumulated knowledge without anyone needing to maintain a wiki.

Building a knowledge base that maintains itself

The shift here is from documentation as a project to documentation as a by-product. Your team is already creating knowledge every day. They write design documents, make decisions in Slack, update runbooks, and review code. The question is whether that knowledge is accessible to the people who need it, or whether it is scattered across tools and channels, invisible to anyone who was not present when it was created.

Fabric's approach is to create a shared knowledge base from these existing sources. You do not need to change how your team works. You do not need to convince anyone to write more documentation. You connect the tools you already use, and the knowledge becomes searchable, synthesisable, and available to new hires and existing team members alike.

This also addresses the problem of teams asking the same questions repeatedly. When knowledge is easy to find, people find it themselves. When it is not, they ask. The wiki was supposed to solve this, but it created its own maintenance burden. A knowledge base that draws from living sources and updates as those sources change does not have the same problem.

Frequently asked questions

Do I need to write any documentation at all for this to work?

No. Fabric's self-writing docs generate onboarding materials from the documentation, conversations, and files your team has already created across connected tools. If your team has been working and communicating through tools like Slack, Google Drive, Notion, or GitHub, there is enough source material for Fabric to produce a useful onboarding guide. That said, teams that have some foundational documents, such as architecture overviews or process descriptions, will see better results from the start.

How does Fabric Tag work in Slack?

Fabric Tag integrates directly into Slack. When someone asks a question, Fabric Tag searches across all connected knowledge sources and responds with an answer that includes citations. The response appears in the channel, so it is visible to others who might have the same question. It draws from Google Drive, Notion, Confluence, Slack history, GitHub, and any other connected source.

What if our knowledge is spread across many different tools?

This is the scenario Fabric is designed for. With more than 50 connections available, Fabric can pull from most of the tools teams use. The semantic search works across all connected sources simultaneously, so it does not matter whether the answer to a question lives in a Google Doc, a Slack thread, or a Notion page.

How do we control what new hires can access?

Fabric's agent access model lets you define scoped, time-limited permissions. You can restrict a new hire's access to specific knowledge domains, projects, or document collections. This works for both direct Fabric access and for access through external AI tools via MCP.

Can new hires use their preferred AI tools with Fabric's knowledge?

Yes. Through MCP and agent access, new hires can query Fabric's knowledge base from within ChatGPT, Claude, or other compatible AI tools. The access is scoped and controlled by your team's administrators. This means new hires can use tools they are already familiar with while still benefiting from your organisation's knowledge base.

How current is the information in Fabric's knowledge base?

Fabric connects to your tools and indexes content as it changes. When someone updates a runbook in Notion or makes a decision in a Slack thread, that information becomes available through Fabric's search and AI assistant. Self-writing docs can be regenerated to reflect the latest state of your documentation and conversations.

Is this only useful for engineering teams?

No. While engineering onboarding is a common use case because of the volume of technical knowledge involved, Fabric works for any team that creates and shares knowledge through digital tools. Sales teams, customer support teams, product teams, and operations teams all face similar challenges with scattered knowledge and onboarding overhead.

What does Fabric cost, and is there per-seat pricing?

Fabric Teams is $125 per month with no per-seat pricing. Your entire team can access the knowledge base without individual licence costs scaling with headcount. This makes it particularly cost-effective for growing teams where onboarding frequency is high.

How long does it take to set up Fabric for onboarding?

Connecting your sources takes minutes per tool. Once connected, Fabric begins indexing and can generate onboarding documentation shortly after. Most teams have a functional onboarding knowledge base within a day of connecting their primary tools.

Can I build a custom AI assistant for onboarding on our own data?

Yes. Fabric lets you build an AI assistant for your team that draws from your connected sources. You can configure it to focus on onboarding-specific content, and new hires can interact with it through Fabric's interface, through Slack via Fabric Tag, or through external AI tools via MCP.

Related pages

• Self-writing docs

• AI knowledge base for onboarding

• Fabric Tag

• Docs that write themselves

• How to stop your team asking the same questions

• How to create a shared knowledge base

• How to build an AI assistant for your team on your own data

• The real cost of engineering onboarding

• How to reduce engineering onboarding time