Beware the Technical Administrator

December 18, 2005

Someone within an R&D organization has an idea and goes to the boss to seek approval. The boss is an expert in the field and can readily judge the merit of the subordinate’s idea. However, this is not always the case. Sometimes, the subordinate has more technical knowledge than the boss. Here, the boss is acting as what I call a “technical administrator” meaning being responsible for all decisions including decisions regarding technology but not possessing adequate technical expertise in the field. Thus, technical administrators manage the department while lacking certain technical knowledge [1]. Excluded from further discussion are those organizations where a technical administrator is a formal position, used to assist a technical leader.

A well known case of how things can go wrong in this situation is the Xerox example from the 70s, where researchers at PARC (Palo Alto Research Center) had invented much of what we know today as the PC. In this case, the CEO of Xerox, who had a law degree with experience in Sales not R&D, had to make a decision whether to commercialize the PARC research. He failed to make the correct decision [2].

Technical administrators are common in organizations. For example,

  • a VP of R&D reports to the president – the later is trained in business not science. In this case, the president is acting as a technical administrator for R&D
  • a VP of R&D for a medical diagnostic company, trained as a biochemist, manages all of R&D which includes an engineering and software effort as well as biochemical R&D. In this case the VP is acting as a technical administrator for the engineering and software groups.
  • a manager has no technical competence for the science performed by a group. There are many possible reasons why this person has achieved the position.

The third example above is pejorative, while the first two are not. Given that technical administrators exist in organizations, the question is what means can they employ to judge the merit of technical ideas. Of course, deciding to approve a new project is never limited to simply evaluating technical merit – there will always be financial and other considerations, and the financial considerations may be the most important part of the decision. However, it is likely that part of the decision to approve a project will require a technical assessment and for the purposes of this discussion, the quality of the technical assessment is the focus. Important decisions requiring technical judgment are not limited to new project approvals. Questions for existing projects include:

  • has feasibility been shown?
  • is an approach to solve a problem credible?
  • will the approach meet the schedule?
  • which new approach among several candidates should be chosen?

The technical administrator can use several methods to make a decision concerning a technology for which he or she is not qualified to judge.

  • They can avoid technical considerations altogether and make the decision based on other grounds such as relationships
  • They can leave the decision up to the lead scientist or engineer. This case can be considered the unsupervised approach.
  • They can convene one or more outside experts to advise on the decision.

Each of these cases is considered in more detail.

To be effective, technical managers rely on a combination of technical knowledge in their field and relationships skills. When technical knowledge is lacking, there can be too much reliance on relationships to aid decision making. These managers may go to their friends or colleagues in the company and ask for advice about the suitability of a new project. However, the people consulted may also lack expertise and be unqualified to answer these questions. Other managers can often detect this case by careful listening and by asking questions. By listening, it may be apparent that the reasons provided by a manager seem to come from someone else and one may confirm and that the manager lacks the detail or logic expected to provide a rationale to support the project. In other cases, a manager might decide on a technical solution proposed a subordinate based only on the relationship with that subordinate.

Leaving the decision to the lead scientist can at times create problems. There is inherently nothing wrong with a lower level scientist making a decision to approve a project. However, the technically competent manager can point out problems in a concept that is flawed or recognize an idea that will be a winner even if the subordinate is too hesitant. Consider a case where a manager has approved a new project by relying on a subordinate’s expertise. Perhaps the project was suggested by the subordinate. The manager must now meet with senior management to develop or finalize plans for this and other potential projects. What often happens, is that the manager attends the higher level meeting with the advice of the scientist but without the scientist (“thank you very much – I’ll take it from here”). The problem is that as the discussion unfolds at the higher level meeting, subtleties may occur that the manager does not properly deal with and the company ultimately follows the wrong path. A simple solution is of course to bring the subordinate to the higher level meeting. The danger (e.g., threat) in this for the manager is obvious if this occurs too many times, since one may ask, what value does the manager add to the equation.

The final strategy is the manager convenes one or more experts to provide advice. Using more than one expert is helpful since not all experts agree or will provide the best advice (e.g., they may have their own agenda). If setup properly, an important byproduct of an expert session is training, which provides the manager and others on staff with a better understanding of the technology. Many advances in science are the result of knowledge transfer [3] so the cost of the expert session will be easier to justify in those organizations that value training programs.

The expert session is recommended as the best way to help managers with decisions on whether to approve new projects when they lack the technical expertise, although in real situations, some combination of the above methods is likely. A factor that influences managers to follow one of the above courses is the culture of the organization. Most managers will go to great lengths to maintain their control and power and these managers view any activity as to its effect on their control [4]. Thus, the organization must provide a climate that encourages expert sessions when appropriate.

Finally, whatever process is used to arrive at a decision to evaluate technology, there is a need to keep track of why the decision was made. If one wishes to improve the quality of decision making, there should be a formal record of each decision’s justification and periodic review of decisions.


  1. Krouwer JS. Assay development and evaluation: A manufacturer’s perspective. Washington, DC. AACC Press, 2002, pp 45-46
  2. Smith DK and Alexander RC. Fumbling the future. How Xerox invented, then ignored, the first personal computer. New York. William Morrow and Company, Inc, 1988.
  3. Davenport H and Prusak L. Working knowledge: How organizations manage what they know. Cambridge, MA. Harvard business School Press, 1998.
  4. Block P. Flawless consulting: A guide to getting your expertise used, 2nd ed. New York: Jossey-Bass, 1999