There are times when a difficulty requires further investigation. Reviewing a query, checking a source, testing a hypothesis. These are part of the work and the professional autonomy expected of any professional.
But there are also times when continuing to investigate no longer brings us closer to an answer. Not because of a lack of effort, but because the information needed to move forward lies outside the problem we are examining.
The question is not how long we have spent trying to solve something. It is what we are achieving with that time.
When autonomy starts working against us
Imagine an analyst who identifies discrepancies between two indicators that should match. They review data extractions, filters, transformations and queries. Everything appears technically correct, yet the figures still do not reconcile.
The discrepancy may lie elsewhere: each business area uses a different definition of the same indicator. No amount of additional code checking will resolve that difference on its own. The meaning of the data needs to be checked with someone who understands how it is used.
Individual investigation was necessary to narrow down the problem. Continuing to repeat it, once reasonable technical hypotheses have been exhausted, no longer reduces uncertainty.
The hours that appear productive
Not all activity produces progress. A series of checks can generate more detail while leaving the question that matters unanswered. The risk is ending up with a robust solution built on an unvalidated assumption.
Research by Sambasivan and colleagues on data cascades describes how problems in data work can spread to later stages. It does not demonstrate that seeking input early will always prevent them, but it helps explain why untested assumptions should be identified before they influence further work.
That is why a useful question is not “Have I investigated enough?”, but:
What specific uncertainty has been resolved through this investigation?
A question can be a sign of quality
Making a question visible at the right time allows us to test what has not yet been confirmed.
Amy Edmondson’s research on hospital teams highlighted the importance of distinguishing between errors that occur and errors that are reported. It provides a reference for communication and learning within teams, rather than direct evidence that consulting a colleague improves every deliverable.
In projects where technical, functional and business knowledge coexist, recognising the limits of the information available to us can be just as important as mastering the tools we use.
Not every difficulty justifies interrupting someone
Asking for input also has costs. An interruption without context can disrupt another person’s concentration. Passing on a difficulty without first analysing it shifts the work rather than resolving it. And seeking consensus on every issue can slow down decisions that belong to the person carrying out the task.
The aim, therefore, is not to ask more questions. It is to ask better ones: when there is a relevant uncertainty that cannot be resolved with the information available, and when we can clearly explain what needs to be checked.
Before asking for input, it is worth considering three questions:
- Am I moving towards an answer, or repeating checks without reducing uncertainty?
- Do I have the information needed to resolve this?
- What specific point do I need to validate?
The answers help determine whether to continue investigating, raise a specific question or escalate a difference in interpretation. They also allow us to approach another person with context, rather than an unprepared task.
Quality is also built before delivery
At Cognodata, different specialisms and perspectives coexist, alongside systems and accumulated knowledge that are not always documented in one place.
In this environment, working with professional autonomy means recognising what can be checked independently and what requires technical, functional or business validation.
Validating an assumption does not mean transferring responsibility for the deliverable. The person carrying out the work remains responsible for incorporating the response, checking its implications and deciding how to proceed.
Knowing when to ask is also part of the job
The distinction is not between professionals who ask questions and those who do not. It is between those who recognise when their work is reducing uncertainty and when they are simply exploring an assumption that still needs validation.
Because part of the quality of a deliverable is determined long before anyone reviews it: at the moment we choose whether to continue investigating alone or bring in the expertise we need at the right time.
Frequently Asked Questions About Professional Autonomy and Problem-Solving
What does professional autonomy mean?
Professional autonomy means taking responsibility for your work, investigating difficulties and making decisions within the scope of the information and knowledge available. It also involves recognising when a question requires information or expertise from others to be resolved correctly.
When should you stop investigating and ask someone else?
When additional checks no longer reduce uncertainty and the answer depends on information that is not available to you. Before asking, it is useful to identify what has already been checked and which specific point requires validation.
Does asking for help reduce professional autonomy?
Not necessarily. Seeking input on an assumption that requires technical, functional or business knowledge can be part of working autonomously. Responsibility for incorporating the response and completing the deliverable remains with the person doing the work.
How can professionals avoid wasting time on checks that do not lead to progress?
By periodically reviewing which hypotheses have been ruled out, what new information has been obtained and which uncertainties remain. If checks are being repeated without providing relevant evidence, the original assumption may need to be validated with someone else.
