Before the Chief Information Officer (CIO) role existed as we know it today, the person who ran technology for a firm was called a Technology Infrastructure Manager or a Data Center Manager. The title tells you what the job actually was. You managed a room. You did not manage a strategy.

The architecture explains why. In that era, end users worked on Quotron terminals, dumb terminals with no processing power of their own, connected back to regional Distributed Network Controllers (DNCs) that did the real work. The intelligence lived in the vendor's equipment, not in the firm's people. Training an end user meant teaching them how to key in a request and read what came back. Data entry. Nothing more, and nothing more was needed, because nothing more sat inside our own walls. If something broke below the surface of that terminal, you called the vendor, because the vendor was the only one who understood the architecture underneath it.

That arrangement worked until the architecture changed.

When firms moved from dumb terminals and centralized DNCs to distributed architecture, the job changed with it. Hardware was no longer dumb. Connectivity was direct and faster. Applications sat closer to the user, and for the first time, keeping those applications running was not the vendor's daily problem. It was ours. Sustainment and maintenance became something our own people had to own, every day, not something you escalated to an outside contact and waited on service.

That is the moment workforce development stopped meaning "how to use the product" and started meaning something closer to what it means today: who understands which piece of this service, and who is accountable when it breaks. The knowledge had to move downstream, out of the vendor's hands and into ours, and there was no formal program built to make that happen. Much of it came through on-the-job training, learning the system by working inside it, often while it was still running. Vendor documentation existed for the products themselves, but it stopped at the product's edge. Everything past that edge, how the pieces fit together inside our own environment, we had to write ourselves.

That is where Standard Operating Procedures (SOPs) earned their place, long before anyone called them a governance requirement. An SOP is nothing more than the detailed process laid out in writing: the steps, the stakeholder responsibilities, the timeframes. We built them because the alternative was letting critical knowledge live inside one person's head, where it would walk out the door the day that person did.

Alongside SOPs, something like a RASCI model (Responsible, Accountable, Support, Consulted, Informed) was already operating in practice, even though nobody in the room would have called it that. Once operational knowledge moved from the vendor to us, someone had to be able to answer a simple question for every piece of the service: who is Responsible for doing the work, who is Accountable for the outcome, who provides Support, who needs to be Consulted before a change, and who simply needs to be Informed after the fact. We were assigning those roles before the framework had a name, because the end-to-end service would not hold together without it.

That is the real argument of this pillar. Training and workforce development is not a class someone attends once. It is the discipline of making sure knowledge that has moved into your organization stays usable after the person who first learned it has moved on, retired, or left for another firm. SOPs and RASCI are what make that knowledge transferable instead of personal. Without them, every architectural shift resets the organization back to the vendor-dependency problem: the people who understand the system are outside it, and everyone inside it is limited to data entry.

Training environments today are far more formal than anything we had in the Quotron era. Learning Management Systems, certification tracks, structured onboarding, all of it exists now in ways it did not then. But the underlying tools that make training actually stick to an organization have not changed. Artificial intelligence adoption is the current version of the same problem we faced when architecture moved from dumb terminals to distributed systems: the vendor, or the model, knows more about how it works than our own people do, and that gap will not close itself. Organizations investing in AI training platforms while skipping the SOP and RASCI foundation underneath are repeating the exact pattern we lived through then. Process without ownership clarity is not workforce development. It is a more expensive version of watching a terminal and waiting for the vendor to call back.

This is Pillar 8 of 8 in the IT Risk and Cybersecurity Governance Framework series. Read the full Framework at MVWConsultants.com/framework.