Quite often, a pair of colleagues on a technical team have serious trouble working together. It’s as if they have completely opposing worldviews, and neither will grant the least bit of validity to the other’s perspective.
The things the say about each other, with intense emotion, sound like this:
- Joe is useless. He can’t get anything done unless every single question is answered down to the minutest detail. He seems immobilized unless all his questions are answered to his satisfaction.
- Jane is useless. Everything she produces is so vaguely defined, it’s unusable. She draws a few boxes and arrows on a diagram and thinks that’s a fully specified system that can be estimated and built.
If you have thought either of these things about one of your colleagues, there’s a good chance that your colleague has thought the other one about you. One thing you are likely to have in common is that you have dismissed the other as incompetent, obstinate or stupid. And the longer you work together, the more entrenched your judgments of each other become.
But another thing that you probably have in common is that you are both wrong about the other person.
Chances are that neither person is incompetent. The two of them just have very different degrees of tolerance for the ambiguity of technical work.
Reality is a messy thing. Every day, in any project or process, we are confronted by ambiguities and questions to which we don’t know the answers. Some are big, open-ended questions: What is the purpose of our organization, and what role should technology play in supporting that purpose? Who are our competitors, and what product features will give us an advantage in the marketplace? Others are narrower but still fundamental to our work: How should our department be organized? What business objectives are driving our technical project? What methodology should we use given the nature of the project, technical tools, stakeholders and team members? Who will play what role on the team? And some are detailed yet essential: What columns will be in each table? How will one process communicate with another? What data will be logged, and where will it be stored, and in what format? And for many, the most distressing ambiguity of all is not knowing what the relevant questions are that need to be asked and answered.
To be successful, most, if not all, of these types of questions need to be answered at some point to complete a project or optimize ongoing operations. Of course, it’s not possible to answer all these questions at once. Answers to some are contingent on answers to others. Often, figuring out which questions are important requires significant thought and research.
Here’s where the problem comes in. People have differing degrees of tolerance for unanswered questions. And the differing orientations, which you can think of as opposite ends of a spectrum, have both positive and negative effects on a team’s ability to succeed.
People with a high tolerance for ambiguity feel comfortable working at full speed, working with assumptions and knowing that they will need to clarify issues as they become relevant. They can speed up production, delivering while simultaneously identifying and resolving questions. But they can also end up wasting their own time and that of others if they race down technical paths that prove to be unworkable or ill-advised diversions that could have been avoided with more careful thinking before building.
People with a low tolerance for ambiguity feel significant discomfort, even anxiety, when asked to produce with limited knowledge or provisional assumptions. They sometimes seem immobilized, unable to produce anything until all questions are identified and answered. It’s also easy for them to get lost in the details, losing track of what’s truly important. At the same time, by driving issues into the open early and making decisions before building technology, they can improve the productivity of their whole team. Everyone benefits during implementation when there’s less need to stop to discuss and decide how things will really work.
Colleagues with these differing tolerances for ambiguity and the contrasting approaches they take to problem-solving often feel intense frustration with each other and certainty that their own approach is the only right way to work.
While it is difficult to bridge these differing orientations, teams can benefit substantially when these styles are blended. It becomes easier when:
- People with high ambiguity tolerance recognize that there is a real difference between a drive for clarity and rigidity. Your low-tolerance colleagues want answers, but that doesn’t mean that they demand that answers not change as things progress and teams learn.
- People with low ambiguity tolerance recognize that those with high tolerance are not necessarily sloppy thinkers, but good at subdividing problems into manageable chunks.
One of the best ways to work together is to arrive at a mutually agreeable breakdown of the entire problem into smaller, interconnected problems, and then to think comprehensively about how each sub-problem will be solved and how to ensure that the smaller solutions are mutually supportive and compatible.
The more you focus on problems and the less you focus on each other’s process, the more likely you are to leverage your collective strengths.
