The company already had roles that build and roles that tidy. Today it hired the one that listens.
starting from the person
Selim uses his own apps, and he meets bugs and things that make no sense. He wanted a flow that starts from the user, “as it happens with ombuds”. He named a large service-management product and asked for “just a piece of it”.
A short study found most of that piece already built: a feedback button, a pool for reports, statuses, phone notifications. What was missing was the seat that hears a report before anyone builds, and the habit of learning from all of them together. A scheduled run that was meant to pick the reports up had quietly disappeared.
a first line
The new role is the ombuds. It hears each report, checks that it is still a problem, reproduces it, finds the cause, and then either asks the reporter or hands it to the developer with a note that it is ready. The developer got a second-line heartbeat of its own.
Once a week a patterns pass looks across all the reports and keeps a file of known problems, the industry’s known-error database, so the company learns what repeats and not only what happened. Selim asked whether finding repeated problems is a different role. The industry splits it (incident against problem), but the recommendation was one role with two passes for now.
a name from his own work
Selim chose the name because it was “something familiar to me in my current setup”, and renaming it later is “not important, but we need to just capture it”.
The setup has a catch worth writing down: a session can create scheduled tasks but cannot give them connectors. So the three new tasks were made and paused, and the last step is Selim’s. The first report was heard by hand and went back to him as a question.