Question of the Week: How much ambiguity does your team permit when assigning a task to a team member?

Wednesday, June 2nd, 2010 by Robert Cravotta

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?

If you would like to suggest questions for future posts, please contact me at Embedded Insights.

[Editor's Note: This was originally posted on the Embedded Master]

8 Responses to “Question of the Week: How much ambiguity does your team permit when assigning a task to a team member?”

  1. N. @EM says:

    Zero ambiguity!
    I practice your advice 15 years ago and found that it takes fare more time for the junior to come with the right conclusion. Unfortunately our small design team has to move fast. There is no time for plan B. Customers prefer our services as we move fast and for that reason cost less. If we trim ambiguity to zero at all levels project takes a lot less.

  2. B. @EM says:

    And then there is also the problem that some managers come back and make all your work obsolete since you did not design what they had in mind, simply because the parameters you were given were not sufficient to know what was required.

    Ingenuity for the design phase is desirable, but the requirements have to be well defined to come up with a meaningful solution.

  3. S.N. @LI says:

    Robert,
    I fully agree with you on two things one is leaving certain amount of uncertainty helps the junior engineers to evolve and with seniority our ability to absorb uncertainty should also increase.
    However we should carefully evaluate the degree of uncertainty an individual can handle. If a particular person is not capable you might end up either with a failed project or a mediocre delivery.

    Thanks
    S.

  4. R.A. @LI says:

    “If a particular person is not capable you might end up either with a failed project or a mediocre delivery”

    If the individual is not capable, fully specifying the task won’t help and you’ll still end up with a failed, or (at best) a mediocre product.

    OTOH if the individual is capable and you tie their hands; you pretty much guarantee that you will get a mediocre work product (because, in anything other than trivial cases, only the individual who actually does the work is really capable of putting together the optimal detailed design).

    Of course, the capable individuals occasionally ignore the over-specified design, and do what’s right anyway :-)

  5. forex robot says:

    Keep posting stuff like this i really like it

  6. I should probably clarify. I do not advocate injecting ambiguity into a project for the sake of developing a junior member’s growth. However, in any project that is performing something new or novel, there is necessarily some uncertainty in the specifications. It may not be practical for the project lead to resolve all of the ambiguities in the specification before assigning tasks to the other team members – it is this time constraint that provides the source of ambiguity that I refer to in my question.

    With that constraint in mind, I would expect that the project lead would assign those tasks with the most unresolved ambiguity to the senior members, and assign the tasks with the least unresolved ambiguities to the junior members. Those tasks assigned to junior members would be low risk and relatively straight forward to recover from by a senior member in the event of a poor outcome.

  7. R.A. @LI says:

    “With that constraint in mind, I would expect that the project lead would assign those tasks with the most unresolved ambiguity to the senior members, and assign the tasks with the least unresolved ambiguities to the junior members. Those tasks assigned to junior members would be low risk and relatively straight forward to recover from by a senior member in the event of a poor outcome. ”

    I would expect that the project lead would assign the appropriate task to the appropriate resource. I believe that pre-conceived notions regarding the inherent superiority of senior resources for any particular task are both illogical and ill-conceived.

  8. Ambiguity is basically a form of slack management. It leaves gaping holes in specifications and can lead to disastrous products. I believe in spending time up front in specifying a project as much as possible. There should be a requirement document that highlights all the architectural considerations along with all the interface standards. The document may be open for other engineers to define their modules/functions. Those functions would be added into the final document. In the ASIC world and the high speed fault-tolerant world there is no guessing!

Leave a Reply to Robert Cravotta