Self-Efficacy When the Spec Was Wrong Before You Arrived

The handover email was polite, the architecture diagram was colour-coded, and the requirements document ran to forty-three pages. On day three, a warehouse supervisor asked why an order placed at 4:55pm shipped a day later than one placed at 4:45pm. The room went quiet. The answer lived in a batch cutoff someone had written into a spec eleven years earlier — and in a shift pattern that had stopped being true in 2019. Nobody in the meeting had written that spec. Several people in the meeting were now expected to deliver against it.

That gap is where this piece lives.

Self-efficacy is not imposter syndrome in a hard hat

Most articles about joining a difficult project reach for imposter syndrome within two paragraphs. Tempting framing: you feel out of your depth, so you must be doubting your abilities. The research draws a cleaner line.

Self-efficacy — Albert Bandura's term — is belief in your capability to organise and execute the actions needed for a particular situation human agency. It is task-specific. You can believe you are a competent analyst in general and still have near-zero efficacy for "rescuing this program without a sponsor" until you produce a result in that context.

The imposter phenomenon is a different construct: high achievers who struggle to internalise success and fear exposure as fraud despite objective evidence of competence imposter phenomenon. Studies consistently show an inverse relationship between imposter feelings and self-efficacy peer-reviewed studies workplace samples — but they are not the same problem wearing different hats. Imposter framing sends you toward belonging and attribution. Inherited-spec framing sends you toward agency on constraints you did not choose.

If the spec was wrong before you arrived, the honest question is not "do I belong here?" It is "can anything I do here still move the outcome?"

The spec is not your résumé. Treating it that way is how competent people lose a month to shame.

The inherited-spec efficacy trap

Wrong specs create a particular kind of efficacy leak — call it outcome coupling. Outcomes stay tied to decisions made before you joined: deadline compressions, vendor template assumptions, scope signed off while the business process underneath was already changing. When the build misses again, the failure reinforces a single story: nothing here is controllable.

Bandura's work on agency is useful precisely because it separates what you can influence directly from what requires proxy effort — persuading the person who owns the budget, the roadmap, or the executive summary human agency. On an inherited program, personal agency starts narrow. That is not a character flaw. It is the shape of the inheritance.

The exit from the trap is decoupling: one correction, mapping, or named constraint that would not have existed without you — and that the team can see. Not a heroic refactor. Not a slide deck calling the predecessor incompetent. A visible piece of truth that changes what gets built next.

Picture a CRM replacement eighteen months in. Adoption flatlines while the team ships sprint after sprint to requirements that describe a sales process the field abandoned two reorganisations ago. The failure is not mysterious. It is coupled: every demo "works" against the spec while the business quietly routes orders through a spreadsheet. Decoupling here is not a new architecture — it is a one-page map showing which clauses still match Tuesday's workflow and which ones describe a fiction. That page is small. It is also the first mastery experience a new analyst can own.

Benjamin Charity's turnaround writing calls the deeper layer "quiet constraints" — compliance rules, vendor lock-in, customer promises, teams that have stopped believing dates quiet constraints. They rarely appear in the requirements document's happy path. They are where inherited specs go to hide.

Four sources — but only two matter on month one

Bandura names four sources of self-efficacy: mastery experiences, vicarious experience, verbal persuasion, and how you interpret stress and arousal four sources. Workplace summaries repeat all four as if they were equally available on day one workplace reviews. They are not.

Mastery experiences — successful performance you can attribute to your own actions — are the strongest source. On an inherited wrong spec, mastery does not come from "shipping the roadmap." It comes from stabilising one recurring failure, documenting one mapping error between vendor reference data and production customisation, or proving that a requirement describes a process the business abandoned two reorganisations ago. Small, shippable, attributable.

Vicarious experience — watching a peer succeed at a similar task — helps once someone on the team has a recovery story in living memory. On a burned-out program, vicarious models are often missing. Too many dates have died on this program already.

Verbal persuasion — encouragement, praise — is the weakest source on its own. Telling a footing-level joiner "you've got this" does not rebuild efficacy when the spec keeps generating failure. Specific feedback tied to a task they actually performed works. Generic confidence theater does not.

Mastery first. Everything else is seasoning.

The team conditions matter separately. Google's Project Aristotle research ranked psychological safety — the belief that you can ask questions and admit mistakes without punishment — as the top dynamic among effective teams Project Aristotle. Edmondson's framing treats that safety as the foundation for learning, not execution performance for its own sake. Safety lets you say "I think this requirement describes a fiction" without betting your reputation on the first week.

Impact — seeing that your work connects to organisational goals — is a different dynamic on the same list. A team can be kind and still feel pointless if every correction gets absorbed into a roadmap nobody believes. Safety opens the conversation. Impact answers whether the conversation can change the plan.

A footing-level week

This is not a turnaround playbook. Charity and Hornby have written those — stabilise, make debt visible, protect sprint time, stop the bleeding turnaround practice struggling teams. This is the efficacy layer underneath: what to do when you are new and the spec is already wrong.

Days one and two — forensic, not refactor. Read the requirements as a historian, not a critic. Ask which user, which exception, which upstream delay each clause was written for. Talk to operations, support, and the person who has been on the program longest — not to assign blame, but to find where the document diverges from Tuesday afternoon reality. The DEV community's honest account of joining messy codebases applies here too: instant verdicts ("this spec is garbage") build distrust faster than they build truth joining messy codebases.

Days three to five — one decoupling win. Pick a single correction you can ship or document with evidence: a revised cutoff rule, a mapping table aligned to production, a one-page "what this requirement actually means in the warehouse." Present it as a learning finding. Frame the work as a question the organisation needed answered, which is Edmondson's learning-problem posture in practice psychological safety.

Sponsor language without performance. You do not need to sound certain about the date. You need to sound specific about the sequence: what is frozen, what is being validated, what would need to be true before a new commitment. Hornby's rule applies — do not promise a month of debt removal; promise protected time for one visible slice protected sprint time. Specificity reads as competence. Volume does not.

When agency is proxy, not personal

Some inherited programs are recoverable with honest diagnosis and a defended scope. Some have quietly entered the phase where everyone schedules meetings about meetings and the sponsor has stopped attending. Bandura's proxy agency — influencing those who hold resources — is the realistic footing-level path when you cannot rewrite the roadmap alone.

That influence works when you bring artifacts, not moods: the mapping gap, the adoption number, the constraint that explains why "just follow the spec" produces the wrong shipment. It fails when you bring contempt for the predecessor team. Competent people write wrong specs under deadline pressure, vendor templates, and reorganisations. The system failed. Prosecution shrinks the coalition you need.

If proxy agency repeatedly hits a closed door — findings acknowledged, nothing resequenced, dates re-announced without changed inputs — you are no longer in an efficacy problem. You are in a career diagnosis. Naming that boundary is itself an agency act, and it is outside this article's scope except to say: efficacy work has a shelf life. Do not spend a year earning mastery experiences on a program that will not let them count.

The fair objection to all of this is time: forensic work feels slow when the date is already red. That objection is right about the calendar. Where it errs is in what it counts — a week spent proving the spec wrong is visible and bounded; a quarter spent building to a fiction is invisible until adoption or revenue says otherwise.

Most stalled inherited work does not need a hero. It needs an honest diagnosis someone is willing to defend, a team safe enough to say the spec is wrong, and one small delivery that lets everyone believe in dates again.

Which inherited requirement in your current program quietly stopped being true — and what would it cost to prove that in one page? If you have decoupled a failure that way, I would value hearing how the recovery actually went.