Stop teaching employees and fix their work

You hire someone to move the project faster. For the first few weeks you explain the work in detail. Then you review the result, find mistakes, fix them. Explain again. Fix again.

After a while you have a new employee, but less free time than before.

What wears a manager out is not the conversation with the newcomer. Explaining how the project works is usually easy. The hard part is knowing that the explanation will be followed by more work: noticing where the person didn’t understand, containing the consequences, and redoing the task for them.

How a manager takes the work back

You became a manager because of your experience. So you spot a weak decision faster, you know the right person to ask, you remember a similar task. Fixing it yourself feels easier than waiting for the employee to figure it out.

That’s how part of their work slowly returns to you. They bring a question, you find the answer. They bring a mistake, you fix it. They bring an unfinished thought, you finish it.

The employee gets used to receiving the next step from the manager. The manager gets used to the fact that work stops without them. The new person has to be brought into the same routine.

Another introductory meeting won’t lift this load. What has to change is what the employee brings to the manager, and what they must do on their own before the conversation.

Give people a chance to figure it out

Independence starts with access to working context.

A new employee should be able to see what the team has already done, which decisions it discussed, why it chose a particular option, and which constraints it ran into.

Completed tasks with discussions, materials and results are useful for this. In them you can find a similar case, see who took part, and ask the person who actually dealt with the problem.

But a “to do — done” card teaches nothing. If the reasoning behind each decision lives only in the manager’s head, the newcomer will inevitably come to the manager for it.

So the course of the work has to be saved while the work is happening. You discussed options, found a constraint, changed the decision — leave a clear trail. Then the next employee can learn from the team’s experience.

The project board as a textbook of “who said what”

In Branzy that trail stays on its own if you work in the board. Every task has its own chat and attachments: the discussion doesn’t get smeared across a general stream but sits next to the result. The task description keeps a version history and a change log, so you can see who changed what and when. And the “Information” section holds the context that has to be passed on: agreements, links, requirements.

It is enough to give the newcomer access to the project, and they can walk through closed tasks themselves.

Example. Say a new customer account manager has joined the team and is asked to agree a launch date postponement with a client. Instead of asking “how do we usually do this?”, she opens the “Done” column and uses search to find two similar tasks. Search understands the meaning of a query, so it also finds a task that doesn’t contain the word “postponement” in its title.

In the first task’s chat she sees that the client was first offered a reduced scope and refused. In the second, the dates only moved after the project lead showed in advance exactly what was blocking the work. The description shows who phrased the terms and how, and the version history shows how the agreements changed. It’s also clear which colleague to ask a follow-up question: participants’ names are next to every message.

This is the detailed picture: not “that’s how it’s done,” but “here is what was said, by whom, and why it turned out that way.”

Let AI take the repetitive questions

Opening the project history to a person is a useful first step. Making sense of hundreds of tasks can still be hard. The board shows details, but not the overview.

An AI that has access to the working context can help find related materials, assemble an explanation and show its sources. Connecting through MCP lets you give such access to a compatible external or corporate agent.

MCP: seeing the project as a whole

Branzy has an MCP server with OAuth 2.1 authorization. The newcomer connects their AI client to it, confirms access, and can ask questions not about a single task but about the whole project at once. The assistant sees only what the employee themselves can see, so nobody gets extra permissions.

Continuing the example. Our account manager asks the agent: “How have we handled postponements on client projects before, which objections came up, and what helped?” The agent assembles an answer from dozens of tasks and discussions and points to the ones it relies on. From there she jumps to the relevant cards and reads the details in the original.

A newcomer can ask as much as they need: why it was done this way, what was tried before, how similar tasks differ, where mistakes occurred. This doesn’t replace the board, it complements it:

• The board answers “what exactly did the person say, and in what context”;
• MCP answers “what has happened on this topic overall, and how does it all connect.”

The agent’s answer must be checked against the source materials. Outdated decisions can remain in the history, and a convincing explanation can be wrong. The useful outcome of such a conversation is understanding grounded in specific tasks and discussions.

After that, the question to the manager sounds different: “I found two similar cases. I propose this option because of this constraint here. Do I understand correctly?”

That conversation already contains the employee’s own work.

Check independence before hiring

This approach needs a person who can figure things out, not just one who promises to learn.

You can test it in the interview: give a small example task and a few materials, then ask the candidate to explain the solution they propose. See what questions they ask, whether they notice contradictions, whether they can separate what is known from assumptions.

The ability to learn matters most where tasks keep changing. Even so, the professional knowledge required must still match the role.

The manager sets the direction

The manager’s job is to define the goal, the constraints and the criteria for the result. The employee’s job is to study the available context, propose a solution, do the work and fix their own mistakes.

The manager remains responsible for organizing the work and reviews important decisions. But the employee is also responsible for their part: a question shouldn’t automatically turn into an instruction for the manager to figure it out instead.

Work history and AI make this kind of independence possible. They reduce dependence on memory and on one person’s constant availability.

Summary

Build training around a simple agreement: “Figure it out, verify, bring options. I’ll help you choose the direction.”

Then a new hire can, over time, free up the manager’s time for developing the project.

To try it: invite the newcomer to a project, ask them to start with closed tasks, then connect an AI client through MCP.