Thought experiment4 min read
Onboarding starts with the first decision of your own
A new system owner is asked to assess a change. This hypothetical case shows which relationships a handover needs to explain—and where a conversation still matters.
In this article
A new colleague takes on business responsibility for an internal system. He knows the organisation chart, has completed the introduction and can open the documentation. Now his first request arrives: someone wants to change an input form. Can he agree?
For this thought experiment, consider an application used to handle product complaints. This is a constructed case, not a customer account. The colleague needs to assess whether a field that sales rarely uses can be removed.
The request looks smaller than it is
The request says to remove the “Failure description” field to simplify data entry. That sounds reasonable to sales. At the next stage, however, quality assurance uses the information to group similar complaints.
Looking only at the form reveals a field that is rarely completed. Looking at the process reveals information another team depends on. The new colleague should not have to guess that relationship. The role handover should lead him to where he can investigate it.
His first decision therefore needs more than a feature description: the affected process step, the downstream use of the information and someone who can judge whether an alternative would be sufficient.
A handover note that leads to useful work
The note does not provide ready-made approval. It makes the next useful step apparent: check with quality assurance how the information is used. The field might indeed be redundant because that information is now recorded reliably elsewhere. Or its low usage might explain a problem with the current process.
Either finding differs from “rarely used, therefore remove it”. Good context does not predetermine the decision. It exposes the assumption that needs to be examined first.
What documentation should leave room to discuss
An experienced colleague may explain why the field was introduced and why an earlier attempt to simplify it did not proceed. While that explanation exists only in conversation, it is a lead for the responsible people to check and, where useful, record. “We have always done it this way” is not sufficient evidence for keeping it.
GitLab offers a public example of documentation working alongside personal support: onboarding buddies are expected to point new colleagues to helpful Handbook pages and help them navigate. Backup support is arranged for absences. An extensive knowledge base does not make an available person redundant in that arrangement.
Source [2]Applied to our case, useful support would mean working through the first change request together. The new colleague leads the assessment; the experienced person helps identify unclear relationships. This reveals what the handover already explains and what it still needs.
The question improves the next handover
Suppose quality assurance confirms that it uses the field. The relationship between intake and analysis should then be recorded in the appropriate place. Another paragraph saying “Please be careful when making changes” would be too vague. The useful detail is who needs which information at which step.
AI could later help locate that maintained information or summarise the review request. A documented system-access relationship does not, however, authorise AI to change the application. Business agreement and technical execution remain separate responsibilities.
The next similar request offers a way to observe whether onboarding for this role has worked: can the colleague find the affected roles and relevant evidence independently? Does he ask a focused question instead of asking generally for help again? The number of pages read would not reveal that capability.
Once the use of a field or instruction has been established, someone also needs to own that relationship. Who maintains the relationship?
Sources & further reading
- Felix Drösel: Die nächste Stufe der KI braucht eine Unternehmenskarte
Foundation for connecting roles, processes, systems and knowledge; 15 August 2026. In German. The change request is our own thought experiment.
- GitLab Handbook: Onboarding Buddies
Publicly documented buddy responsibilities, including Handbook orientation and backup support. Accessed 9 September 2026; not a PULSE customer reference.