Thought experiment5 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 business responsibility for an application used to handle product complaints. After the introduction, he knows its main functions and where to find the documentation. His first change request goes beyond operating the software, however: sales wants to remove a field it rarely uses from an input form. He needs to assess whether that would leave information missing elsewhere.
This constructed case helps explain which relationships a role handover should provide. The question is how the new owner moves from a request to the affected work, the responsible people and a reasoned assessment.
The request looks smaller than it is
The request concerns the “Failure description” field. For sales, removing one item from complaint entry would simplify the task. Quality assurance later uses that information to group similar reports and investigate recurring faults, however. A change to the form would therefore also affect analysis in another part of the business.
That downstream use may not be apparent from the form’s feature description. The new colleague therefore needs a route from the system to the complaints process and the responsible person in quality assurance. He can then establish whether the information is actually required and whether it already exists elsewhere. This is the relationship a useful handover of his role should make accessible.
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 handover note does not need to explain the entire application for this purpose. It can connect the new responsibility to a specific first task and show where to find the relevant basis. The following note is one possible excerpt: it identifies the reason for the review, the downstream use and the boundary of the decision the new owner is preparing.
With this orientation, the new colleague can first discuss the request with quality assurance. The field may now be unnecessary because the information is recorded reliably elsewhere. Alternatively, its low usage might explain gaps in the existing analysis. Both possibilities need investigation before the proposed simplification can be assessed.
The handover thus makes the next reasoned step visible instead of supplying ready-made approval. The colleague understands why another department needs to be involved and which assumption should be checked with it. That also helps with a later, similar request, even when the particular field and people affected differ.
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.