Indika, a newly hired developer, submitted a pull request on her team's codebase and mentioned it to her manager Bill. Bill responded with disapproval, directing her to his team's internal developer guide—separate from the official company-wide guide she'd already read.

Bill's guide contained a strict edict: branching is prohibited. Merging is deemed wasteful and contrary to CI principles. The only permitted git operations are commit, push, and pull, apparently expecting all work to happen directly on the main branch.

When Indika asked a colleague, Elise, if this was genuine policy, Elise confirmed it was real—but revealed the team's workaround: everyone uses branches and pull requests routinely, they simply ensure Bill never finds out. The unspoken norm is to hide this standard development practice from management.

Indika eventually confronted Bill in the break room to understand his reasoning. Bill cited twenty years of experience and argued that branches create conflict points, allow code to become stale, and cause developers to fall behind teammates. He acknowledged that large open-source projects might benefit from branches but dismissed them as unnecessary "shiny toys" for a small internal team.

The situation reflects a disconnect between established software engineering practices and one manager's idiosyncratic philosophy, forcing the team to operate under an unofficial shadow process rather than follow stated policy.