While pondering about troubleshooting skills and systems, I decided to write out my thoughts on the structure of systems personnel.
Architect – Designs the environment, top to bottom. May not know every tiny detail, but usually pretty close. Knows how pieces integrate. Can anticipate problems, and design solutions before they occur.
Engineer – Deploys the environment, partially or completely. Knows most of the details, and most of the “why”. Creates solutions to problems. Can make changes to design specifications where necessary and practical.
Administrator – Manages the environment after it’s in use. Can fix ongoing problems. May have limited ability to change designs to work around operational issues.
Support/Helpdesk – Can help translate how and why. Can isolate problems. Can provide how-to and usage instructions. Can provide work-arounds. Can explain user expectations.
Operator – Performs daily maintenance and reporting tasks.
User – relies on the functions of the system. Can command system to perform functions. Can receive system outputs.
Interested Party – Knows about the system. Has influence on the system. May be a third party, or management. Little direct interaction with the system, if any. May be an external source or recipient of system input/output.
Generalities of this structure include:
* Higher level resources will have superior problem solving skills, and will engage lower level resources as a means to distribute operational workload.
* Lower level resources will have more familiarity with daily operations, quirks, etc., and will engage upper level resources for problem solving.
* Persons more than 2 levels separated may have communication or perception discrepancies that may be more time consuming to bridge.
* Higher level resources generally will not accept lower level roles for a long time.
* Lower level resources are often placed into higher level positions due to the difficulty in properly assessing and screening the skills required.
