• “Candidate must be comfortable working with ambiguity.”
• “Should be able to operate effectively amid ambiguity and rapid change.” 

These are bullets from two different job descriptions I saw for Instructional Designer (ID) positions over the last few months. They probably look familiar, whether you work in Learning & Development (L&D) or not. 

This comfort with ambiguity is not unique to L&D (I’ve seen it firsthand in software development organizations as well), but it does have fairly unique implications for L&D organizations; let’s build up to what those implications are. 

As a contractor, you can work with a client’s admission of ambiguity. Frankly, it remains one of the major benefits of contracting; if a project is too ambiguous, then it’s not possible for me to scope it, estimate my hours, create a project plan, or easily schedule anything else in my life. In other words, it’s hard to write a contract if the terms aren’t clear; I can’t say “yes” to your project (yet) because I can’t tell (yet) what I’m actually saying “yes” to. 

When you’re a contractor, it’s easy to go back to a potential client and say “I don’t know enough about this project yet to commit to it – can we talk more about A, B, and C?” And then they either make things clearer (they want to staff the project and deliver it, after all), or they don’t/can’t, and you can move on to something else. At this point, it’s not personal – the business world is full of half-formed ideas (and I’m fine forming the other half of the idea with you). But note what I’m saying here: despite the presence of ambiguity, you can work to reduce it. It’s not meant to be permanent, and both sides agree.

There’s a second–and less desirable–way that the “comfortable with ambiguity” bullet can be read: rather than it being a requirement of the candidate to be comfortable with it, it can instead signal a comfort level that the organization has in allowing it to persist. Getting–and staying–organized is hard work, and sometimes it’s easier to admit silent defeat, wave your hands in all directions at the inevitable ambiguity, put on a brave face, and hope you can deliver…something. Unfortunately, this creates a work culture where improvement can actually be considered wasteful. 

Most reasonable people are aware that not all decisions are made with perfect information. Some amount of ambiguity is inevitable, for many jobs, in many industries. It’s why people perform some jobs and not an algorithm. If you are going to the trouble of identifying “comfort with ambiguity” as unique to the job role in question, give some thought about why. “Candidate must be comfortable making decisions with less-than-complete information” is one thing; “we do little about our ambiguity” is another matter entirely. 

What does this have to do with L&D? Acceptance of ambiguity-as-culture can do serious damage to an L&D organization in particular because their own products & services are supposed to help others reduce ambiguity. That’s the whole point. How are employees supposed to act when they see expertise and knowledge being positioned as vital and mission-critical to paying clients, yet ignored and dismissed internally? Organizationally, you either embrace the ambiguity-reducing effects of knowledge, or you don’t. 

This intersection of ambiguity and L&D creates some strategy and communication problems for leadership. Left unaddressed, a commitment to ambiguity fertilizes at least four awkward leadership positions:

1.) “I do not need much information in order to lead” 

Declining information signals that you already know the answer, or already know how to get to one. It’s probably possible to lead by instinct and gut feel sometimes, but the odds that any particular leader can do it consistently are quite low, especially in the age of Big Data and increased complexity. A refusal of information is a refusal to learn, and it is hard for an L&D organization to recover if learning is obviously viewed as a low-value activity internally. 

There are ways to translate qualitative feedback into quantitative feedback (customer service can be very good at this). There are ways to create information pipelines resulting in data that can be passed up the chain of command appropriately. But declining information helps create an environment where opinion masquerades as fact, where instinct trumps experience, and where a state of ignorance isn’t viewed as a problem. “Ignorant” does not mean “stupid.” It means “doesn’t know,” and there’s no shame there. It can also mean “doesn’t know yet,” and L&D happens to be uniquely suited to help with that problem. Let it. 

2.) “Your input does not matter” 

Any employee worth their carbon will want to reduce ambiguity, and fast, even if only in their immediate workflow (though most problem-solvers think bigger than that by default). Accepting ambiguity encourages learned helplessness among employees, which positively destroys morale. If a company acts like ambiguity is inevitable no matter what, and there’s no reason for anyone to try to reduce any of it, then employees stop caring. 

Dan Pink’s book Drive was very clear about what creates motivation: Autonomy, Mastery, and Purpose. If you have no control over your work, if you can’t get good enough at anything to stabilize it and reduce ambiguity around it to make the experience more efficient and pleasant the next time you do it, and there’s little-to-no point to what you do in the end, then an organization can’t magically expect motivated employees. 

3.) “We listen to students, but not employees”

Some exciting things have happened in User-Centered Design and Human-Computer Interaction over the last twenty or so years, chiefly that companies have started to accept that “usability” is a concept defined by the customers rather than the company: if the user base says the application is hard to use, then it’s hard to use. Period. We don’t have the right to tell other people about their own experiences. But here’s the thing: we talk about internal customers all the time. And if your internal customers are using your own processes and services and finding them improvable in some way, then the same user experience philosophy holds: we don’t listen to customers selectively when it’s convenient. Customers may vote with their wallets, but employees vote with their attention and loyalty. Proceed with caution. 

4.) “Our Lessons Learned meetings are symbolic”

In L&D, if you are not making an effort to use Lessons Learned meetings to, you know, learn, then you are alerting your employees that formal settings for learning are not real. Projects are therefore about learning, not for learning. 

Reach the Lessons Learned meeting in the project timeline, gather stakeholders, attend the meeting with a smile, jot down the overly-sanitized feedback from everyone, format it, then file it away in the Cloud, never to be looked at again. Don’t do this. 

Before being so forthcoming with how you want or need employees comfortable with ambiguity, take a moment to figure out what you really mean by it. L&D professionals are pre-wired to reduce ambiguity, and organizations have to be very careful about sending the message that that desire is a liability rather than an asset. 

Failure to create a culture of learning in an L&D organization can be catastrophic. “Organize your workflows but not the work” makes no sense. “Make product but don’t be productive” also makes no sense. “We support you, but not if we have to do anything” doesn’t make any sense either. Without a genuine culture of learning, a genuine culture of continuous improvement, and a culture of mutual respect for knowledge in all its forms, there really can’t be any such thing as an engaged L&D employee, otherwise we’re squarely in “do as I say, not as I do” territory. 

Learning and development organizations have to learn and develop, and have to ensure they legitimately respect learning and development, otherwise they are in the awkward position of demanding that successful candidates can “operate effectively amid ambiguity and rapid change” while simultaneously being the source of that ambiguity.