I shared a story a few years back about how when I was a junior member of the technical staff. I learned the value of explicitly allowing some uncertainty in assignments to members of the team. An excerpt from that story illustrates the key point:
The instructions for my lab partner and me were to characterize the camera system and to make sure the automatic-gain-control algorithm appropriately adjusted the camera’s sensitivity. How to test the system remained unspecified. The system engineer had not expected us to try to simulate a single pixel signal. Because we were not influenced by his assumptions about the camera system, we uncovered an anomalous condition in the lab that would have caused the vision system to fail when it was deployed [in low-gravity space].
… A key defining element of engineering is to be able to create systems that can deliver consistent, repeatable, and reliable behavior despite uncertainty and variability over some range of environmental conditions. Dealing with uncertainty is fundamental to being an engineer, and there is usually a positive correlation between the seniority of an engineer and the amount of uncertainty he needs to deal with in his job. It is important to allow some uncertainty to exist in assignments for even the most junior engineers, as it can be a source of growth for them—and it might save a project from failure.
This personal experience made me realize how important it is to provide wiggle room in an assignment, especially to junior members of the team, because it provides a mechanism for them to practice dealing with uncertainty and making guesses. It enables them to practice dealing with increasingly larger amounts of uncertainty as their skill and experience increases. It also helps prepare them for the very real uncertainty that senior members have to deal with when directing new and path-finding projects.
Do you, or does your team lead, allow or make room for ambiguity when assigning a task to a member of your team? Does your team use other methods of encouraging the members to think “outside of the box”? How does your team grow and mentor your junior members?
[Editor's Note: This was originally posted on the Embedded Master]