Junior admin rant incoming. My senior is clearly experienced and has seen far more environments than I have, but he often uses very old-school methods without explaining the reasoning behind them. For example, I asked why we were manually checking the same read-only setting across multiple machines instead of scripting it. Rather than explaining a technical limitation, risk, or edge case, he simply said it was easier to do it himself and checked everything by hand.
I'm not claiming my approach is automatically better. I know production environments have constraints that a homelab doesn't, and I want to understand those tradeoffs. Maybe automation would take longer to write and test, introduce maintenance work, fail on unusual configurations, or require approvals. Any of those would be useful to know.
The frustrating part is that "I'll just do it myself" closes the task but doesn't teach me anything. How can I ask a senior colleague to explain the reasoning behind a process without making it sound like I'm challenging their experience?
4 Answers
There are several reasonable explanations: the task may be rare, quick to perform manually, full of one-off exceptions, or risky to automate. Writing, testing, documenting, and maintaining a script can cost more than a few manual checks. Sometimes the benefit is also not just speed—manual work may reveal discrepancies that an imperfect automation would miss.
The best approach is to build a small proof of concept, preferably read-only, and ask the senior to review it. Include logging, validation, clear error handling, and a way to compare the results with the manual process. Seniors often explain their concerns more readily when they have something concrete to react to.
Sometimes it really is just habit, resistance to change, lack of scripting experience, or a desire to stay busy. Experience doesn’t automatically mean someone is good at mentoring or open to new tools. Still, avoid assuming that’s the explanation before you test the idea.
Frame it around outcomes: “I put together a read-only version that checks these systems, records the results, and flags anything unusual. Would you review it with me?” That lets the process demonstrate its value without publicly implying that his method is wrong. If the workplace consistently rejects sensible improvements without giving technical or business reasons, that may be a culture problem rather than a problem with your question.
A script is not automatically safer just because it is consistent. It can have bad assumptions, mishandle an unusual configuration, produce misleading results, or become a maintenance burden for the whole team. Production work also has change controls, testing requirements, audit concerns, and ownership questions that a homelab usually doesn’t have.
That said, manual work has risks too, especially skipped steps and human error. A good automation proposal should explain how it will be tested, who will maintain it, what happens when it fails, how results are logged, and how a person verifies the output. The strongest argument is not “my way is faster”; it’s “here’s a controlled process that is repeatable, auditable, and easy to roll back.”
First learn the existing procedure manually and understand what counts as a correct result. A junior can easily automate the visible steps while missing the reason those steps exist. Once you can perform the task reliably, propose automation as a way to improve the process rather than replace someone’s judgment.
Try asking, “I know you have more experience with this environment—could you walk me through what risks or exceptions you’re checking for here?” That wording shows respect and makes it clear you’re trying to learn, not prove him wrong. You can then suggest a script that handles the routine cases while leaving unusual results for human review.
That makes sense. I’d be fine with an edge case, maintenance burden, approval issue, or previous automation failure—I mainly want to know which one it is. A small proof of concept gives him something specific to critique instead of making it sound like a vague suggestion.