A failed test is not undesirable
Summary
If you only design your team’s collaboration and communication processes assuming high psychological safety, you’ll create blindspots for yourself. Instead be open to the idea of a “failing test”, that tells you when things go wrong. In this post, I explore the idea of anonymity as one such failing test.
The other day I was speaking to a colleague after an all-hands meeting. They lamented the number of anonymous questions that came up at that event. In an ‘open culture’, shouldn’t people identify themselves when interacting with leaders? Should there even be an option to be anonymous? When a few people interact anonymously, can it lead to a contagion of anonymity? You know, where some people who’d have otherwise identified themselves, now feel like they must shroud their identity?
I found the perspective interesting. Indeed, my colleague made one implicit point that I agree with.
“When everyone can identify themselves in a reflective discussion or debate, it reflects a high level of safety in that group.”
But of course, I’ve made the point earlier, that anonymity is an ally to open discussion. So where do I disagree with this colleague of mine? Let me explain with an analogy.
On agile teams, it’s common to test drive your code. You write a failing test. You then write the code to pass that test. Repeat and refactor. A failing test is the starting point of the development process. For those uninitiated to this development style, it may seem odd to begin with failure. But then, the failure is a signal to write just enough code that passes the failing test.
Indeed, we consider a codebase with a high test coverage, to be robust. Many months after you’ve built some functionality, when a test fails, it’s easy to pinpoint where the fix may lie. If you inadvertently break the build with a recent commit, your tests tell you what you did wrong. Failing tests are feedback signals. In an ideal world, you only want success. But the world is always far from ideal. Tests give you a safety net, so you can fix things that are wrong or will inevitably go wrong.
Let’s extend this analogy to the question of anonymity. Ideally, you’d like everyone to identify themselves when interacting with each other. Power, status and seniority shouldn’t hinder safety. If everyone interacts while revealing their identity; great! Your test passed! But if your test failed, and some people choose to be anonymous, then you’ve got yourself a feedback loop. You know people don’t feel safe. As a leader, you must do what it takes to improve psychological safety in your sphere of influence.
Consider the flip-side. If you don’t test-drive your code, you may not encounter a failing test, even if one of your recent commits broke some functionality. You’ll face the illusion that all’s well when it isn’t. Similarly, you could disable anonymity on your Google Docs, your Mural and Miro boards or your Zoom webinars. You could get rid of the test. Everyone will have to identify themselves. But will they? It’s more likely that people who feel unsafe will go silent. You’ll have broken functionality, but you’ll be none the wiser.
“We plan to succeed, but we’re also prepared for failure.”
Individuals, teams and companies don’t exist in some freaky utopian vacuum. Just as we embrace the good times when things seem too good to be true, we must prepare for the times when we won’t be at our best. Or when luck won’t go our way. Just as we write tests to make our code robust, we must have tests to make our communication and collaboration robust. The option to be anonymous is one such test.
Let me leave you with a few other examples of failing tests that can help you improve communication and collaboration.
What if you made your mandatory team meetings optional? Tell everyone that they can skip these meetings if they don’t see value. If most people stay away, the failing test will tell you something.
What if you devolve decision making to the lowest level possible? Instead of full-team consensus on every decision, consider leaving reversible decisions to individuals or pairs. If a reversible decision backfires, you’ll have a failing test. Weigh these failing tests against your decision velocity to figure out your equilibrium.
Track your retrospective actions on your team’s task board. If you don’t see progress on some actions, that’s a failing test. It means that the problem may not be important enough to fix. It could also mean that the team doesn’t have the time or agency to fix the problem. Either way, you have some feedback.
When making a proposal or thinking of an idea, write things up and share your rough drafts with colleagues as early as possible. If they like where you’re headed, great. If they share critical comments in the document, you’ll have your failing tests. Being wrong at speed, will also help you be right sooner than you’d imagine.
What other collaboration tests do you employ in your team? I’d love to know.