Every day, I work with teams to sharpen how they collaborate, create real value, and adapt to whatever comes next. And I do it with confidence and conviction. Yet, at times, the mind behind the confident smile wavers. Factually, I *should* feel confident. I have the years of experience, the certifications, and the feedback from peers and managers that says I’m “doing a great job.” Yet, some days, the doubts slip in, whispering, “*Are you really good enough?*” In Agile, where success isn’t a finished product but an ever-evolving process, those results are rarely clear-cut. I am sometimes left wondering, “*Did I really make an impact…or was I just there?*” Hello impostor syndrome, my old friend. I’ve come to talk with you again.
Agile and Scrum roles are soaked in this feeling. We lead without authority. We measure success in shifts of mood and flow rather than in units produced. We’re expected to be fluent in theory and practical on the ground, calm in conflict and patient with resistance. The conditions are custom-made for self-doubt. And the people who take these roles seriously tend to be exactly the kind who internalize that doubt hardest.
The quiet psychology of feeling like a fraud
Impostor syndrome was first named in 1978 by psychologists Pauline Clance and Suzanne Imes, who noticed high-achieving women systematically discounting their accomplishments. The pattern is common. It’s not even new. What makes it tenacious is that external validation doesn’t seem to fix it. You can be told you’re doing good work and still, quietly, wait to be found out.
High achievers internalize success poorly. A promotion bebecomes, “They needed someone,nd I was available.” A good retrospective becomes “they would have figured it out without me.” Over time, this self-talk erodes the ability to notice progress at all. In Agile, where progress shows up in interactions and adaptations rather than in shipped products, the erosion is faster.
It hits harder for those from modest backgrounds, first-generation professionals, and people without conventional educational markers of “achievement.” Scrum mastery and agile coaching are trades learned mostly through experience (and mostly through failure), not through formal degrees. Without the paper credentials that signal belonging in boardrooms, some of us carry an extra layer of “Am I even supposed to be in this room?”
Why the Scrum Master chair breeds doubt
The accountability is ambiguous by design. The 2020 Scrum Guide positions the Scrum Master as a “true leader who serves the Scrum Team and the larger organization.” The earlier “servant leader” framing was reworded in 2020 to emphasize true leadership rather than subservience, and the guide now names the Scrum Master accountable for the team’s effectiveness. You are accountable for the effectiveness of the team, but you have no hierarchy to enforce anything. That vacuum of formal authority is where impostor syndrome pitches its tent.
Success is also challenging to see from the outside. A team that ships reliably, argues productively, and notices its own patterns is the product of quiet structural work, but from above it can look like “nothing is happening.” DORA’s four capability metrics (deployment frequency, lead time for changes, change failure rate, and time to restore service) give engineering leaders something concrete to point at. DORA metrics offer measurable outcomes where the Scrum artifacts alone often don’t, which is part of why a Scrum Master’s contribution is harder to render on a dashboard. The Scrum Master’s contribution rarely lands cleanly on any dashboard of its own.
Then there’s the change work. Every suggestion to try something different meets resistance, and resistance is easy to interpret as “I’m not good enough at this role yet.” Underneath all of that, the field itself keeps moving. New frameworks, new post-agile approaches, and new criticisms of what “real” agile means. The pressure to stay current is relentless, and the gap between what you know and what you feel you ought to know never quite closes.
What actually helps (and what doesn’t)
The first thing that helps is naming the thought as a thought. “I don’t know enough” is a feeling, not a fact. Getting even a small distance from it, noticing it rather than obeying it, is the beginning of any useful response.
Counter-evidence helps. Keep a running list of the actual impact you’ve had. The team you coached out of a toxic dynamic. The Sprint Review is where a product manager finally got honest feedback. The conflict you facilitated turned into a better agreement. Write the specifics down, because impostor syndrome’s main trick is to make you forget them.
Comparison helps almost nobody. Agile roles are too varied for it to be fair. One coach’s strength is systems thinking, another’s is conflict facilitation, and another’s is pattern recognition across teams. Comparing outward is a way of refusing to look at your own actual shape.
Stop over-preparing. Perfectionism as a defence against feeling like fraud is a trap because Agile explicitly values adaptability over polish. If you are spending three hours preparing a one-hour retrospective, the problem is not that you need more preparation. The problem is the anxiety the preparation is meant to soothe.
Talk about it. This moment is where psychological safety stops being a slogan and starts being structural. Psychological safety is the shared belief that the team is safe for interpersonal risk-taking; it is what makes it possible to say “I feel like a fraud” out loud at work without it becoming a performance review. If your Scrum community, your peers, or your coaching circle can’t hold that conversation, that itself is a signal that the environment needs work.
Where the organisation comes in
Most literature on impostor syndrome puts the repair work on the individual. Recognize it, reframe it, and journal it. That’s fine, as far as it goes. But the conditions that create it are environmental as much as they are personal.
A culture that rewards polish over progress will breed fraud feelings. A culture that treats every failed experiment as a personal indictment will, eventually, produce people who stop experimenting. A culture that defines success so vaguely that nobody ever feels they’ve achieved it will always have a supply of anxious high-achievers (look around your office; this is probably happening somewhere nearby).
Ron Westrum’s typology is useful here. In his ‘Organizational Typology’ (2004), pathological cultures suppress information, bureaucratic ones allow it grudgingly, and generative ones actively seek it; impostor syndrome thrives in the first two and recedes in the third. In a generative culture, information flows, failure is treated as data, and people can say “I don’t know yet” without losing status. That environment doesn’t eliminate self-doubt, but it stops amplifying it.
Organizations that want to do this work should clarify what Scrum Masters and Agile Coaches are actually accountable for (the 2020 Scrum Guide is a starting point, not an ending one); fund continuous learning without making it a status test; treat failed experiments as information rather than evidence of personal failing; and connect newer coaches to people who have already lived through their fraud seasons.
Living with it, not beating it
I’ve stopped trying to beat impostor syndrome. Every framing of “how to defeat impostor syndrome once and for all” subtly reinforces the idea that the doubt is the enemy. It isn’t. The doubt is a signal that you care about doing the work well and that you haven’t yet internalized the distance between what you’re actually doing and what you fear you’re not.
What I’ve learned is closer to resilience than to certainty. Some days the voice is quiet. Some days it’s loud. The point is not silence. The point is that it doesn’t get to steer.
I’m not going to stop doubting. But I am going to stop calling doubt a disqualification. That, to me, is what leading in Agile with both doubt and determination actually looks like. Not the absence of the question, but the willingness to keep showing up inside it.