I was working with a client team recently encouraging them to build a regular, weekly cadence of customer interviews to inform the release of their brand new B2C communications tool. The team was enthusiastic. The tool had met with a large number of downloads out of the gate and the quantitative feedback combined with inbound requests and complaints along with App Store reviews left them with a mountain of optimization options. “How do we prioritize?”, they asked me.
I, too, was enthusiastic. There was no better way to illustrate the power of continuous learning, low-risk experimentation and ultimately, agility, then digging into some first-hand user research. We wrote an interview guide, identified some customers to speak with and made a plan to get a round of interviews done in a week. And then nothing. A week went by and no interviews had been conducted. Two weeks later, still nothing. I was getting frustrated so I reached out to the team lead to see what was the hold up.
What he told me was familiar, sadly, and it made me realize that while we can teach the ceremonies of Scrum, assign teams objectives and key results, set up outcome-based roadmaps and brilliantly integrate the complementary practices of User Experience design and agile we’d still fail without psychological safety.
Psychological safety is defined as “being able to show and employ one’s self without fear of negative consequences of self-image, status or career.” It speaks to risk — the risk of sharing your thoughts, ideas and opinions regardless of how benign or controversial they may be without worrying about whether you’ll still be employed at the end of the day. The team lead, without using this exact phrase, shared with me that this is the primary challenge for his team. They knew the product had tremendous potential. They understood that they had to discover, continuously, how to prioritize bug fixes, enhancements and new features with the goal of delivering an ever-better customer experience. What the team lacked was the psychological safety to go and do product discovery. The mere act of talking to customers implied that the direction the team was given by upper management may not be correct. There was little tolerance for that. Besides, shouldn’t they be shipping features? Not interviewing customers.
What’s worse is that if they did do discovery work and their findings contradicted the direction they were given there was no safe forum in which to share those insights. This made the whole discovery process moot. When there’s no discovery, there’s no learning. And without learning, there’s no agility. It doesn’t matter how many best practices you layer on top of each other. If the goal is to “look good” in the eyes of management and looking good means following orders, well, that’s not agile.
Learning is at the core of agility
Professor of Leadership and Management Amy Edmondson put it succinctly,”Psychologically safe employees are more interested in learning, excellence, and genuinely connecting with others than in looking good.” Learning, excellence and connecting with others — customers in this case — are the raw materials of agility. We simply cannot predict what our customers will do with our products, regardless of what your job title may be. This was the foundation upon which the Agile Manifesto was written. The small course corrections we make based on continuous delivery of value and sensing of feedback are what make a team agile.
Leaders that believe they can dictate every action for their teams create an environment without psychological safety. Teams work to meet the requirements handed to them and any significant deviation from those requirements carries with it negative consequences.
Small wins to make big changes
So where did things end up with my team? We decided to start with two things:
- Begin with a small amount of regular customer discovery work — 3 user interviews per week in this case — and start collecting evidence. Each week, the team has used these interviews to ship a very short findings report along with any supporting material (video clips, photos, etc) they can add to their leaders. The goal here is simply to point out what “the market is saying.”
- At the same time, we engaged with the executive coach working with the leadership team to point out the contradictions between the demands to “do agile” but also “do what we say.” The goal here is to illustrate the lack of a safe space for employees to share not only their opinions but the market-based evidence their collecting — two things that are required if we’re to truly build an agile, learning organization.
If you’ve built a learning organization or have been lucky enough to work in one, what made that culture work? How did leadership encourage teams to learn more and build a psychologically safe place to work?