Cognitive Architecture for Companies

The cognitive architecture is the structure of decision-making, in this case for a company. Typically, this is in a set of levels identified as:

• Governance: This is typically the responsibility of the board of directors and CEO.
• Top management: This is typically the so-called C-suite. The CEO and the executive management team.
• Middle management: This is all the levels of management between the C-suite and the individual contributors.
• Individual contributors: These are the people who on an individual basis execute the functions of the company.
• Mechanisms: These are the technological and other mechanisms of the company that support its cognitive and non-cognitive execution.

Each of these levels of operation have different time frames for getting and providing different information to different parties, making different decisions based on situation and information available, and undertaking different actions based on those decisions. Each benefits or suffers as a result of their activities in this regard. Here is an example of the top of the hierarchy for an early stage company in development:

Starting with this overarching structure, we may then develop the cognitive architecture by which the company operates, at these levels of the company.

Down the hierarchy

At the next level of the hierarchy, in this case the top executive level, we would have a similar architectural component for each of the identified Finance, Administration, Information Management, Technology, Business Development, and Operations/Solutions delivery officers / functions. Of course they have upward outbound reporting and inbound downward activities, so the structure would include a few additional elements. And the time frames for upward communications should match the timeframes of the ownership and board level, while their downward outbound actions would be the lower-level inbound requirements of the middle management layer, and so forth...

In order to achieve the timeframes from above, the time frames to below must be shorter to allow for feedback to adapt the lower levels to meet higher level requirements and expectations. The so-called OODA loop (Observe, Orient, Decide, Act) internally is dictated by requirements from above, while the lower-level OODA loop is set below in order to meet the requirements from this layer. Similarly, the objectives, quality, schedule, and budget is hierarchical so that lower level budgets, for example, must add up to not exceed the budget at each level.

How you make these decisions

As individuals we can try lots of different approaches to decision-making, but for a company, especially as it grows, these decision-making processes must be systematized in order to assure reliable processes across the enterprise. For example, liability often hinges on the decision-making, while risk (uncertainty) management must be able to analyze the situation through decision-making processes to provide reasonably controlled actual decisions in order to manage overall aggregated macro-risk from micro-level decisions and their associated micro-level risks.

• Decision criteria: Decision criteria drive decision-making processes and mechanisms. For example, a decision that has to be made in less than a second and every second of every day to control an operational technology process has to be fully automated or it will fail, but might have little or no secrecy requirement; whereas a strategic decision about mergers and acquisitions has a much longer time frame, definately involves people working in groups, and has very specific requirements for confidentiality.
• Determining decision methodology: Given that there are different methodologies for decision-making given different criteria, determining the acceptable methodologies for each level of the hiearchy and kind of decisions made becomes necessary in order to assure that decisions are made in a timely fashion and according to the rest of the criteria. Uniformity, or at least traceability, is important to limiting liability and having a predictable environment that upper levels can count on so as to be able to make macro-level decisions and not have to get invovled in micro-management.
• Building the decisions: Many if not most decisions can be largely standardized as to criteria, approach, and often even calculation method and data sources. For example, suppose we repeatedly hire new workers based on job title and description. We might set salary ranges, minimum experience levels, educational requirements, necessary certifications, and so forth. These limit the criteria for eligibility. On the other hand, we might also have softer requierments, such as getting along with the team, having positive recommendations, relocation expenses, when we need them to start work by, and so forth.
• Systematic decision-making: All of this combines together into systematic decision-making, both in terms of process requirements and in terms of metrics. For process requirements, extending the hiring example, we might require that they submit a resume, answer a standard set of questions, provide some number of recommendation letters, do at least 3 interviews including with a likely team member, manager, and executive, and so forth. For metrics, we might require that they have grades from their last educational experience if less than 5 years ago of at least 2.5 GPA, that they have at least 5 years of work experience in a similar job area, that they be at least 21 years of age, and so forth. Perhaps the standard approach is to get to 3 candidates that meet all the criteria, then allow a set of team members to vote on the one to hire by confidentially ranking them 1, 2, 3 and selecting a basis for the ranking from a list of pre-defined criteria.

All of this is of course documented, and where feasible, integrated with enterprise work flow systems and other at least semi-customized automation, with record-keeping and disposition requirements that are part of the information management function so that the administrative function can execute the hiring process (in the HR example), and approved by finance because of the financial implications, and so forth.

Turning architecture into implementation

In implementation, the architecture ultimately drives design, which puts actual time frames, budgets, and quality into realization, and which is adapted over time during execution. Unrealistic architecture is revealed by failure of the mechanism overall (at each level) to achieve the desired objectives.

Note that this is adapting at all levels, so that at the top level, in the decision time frames, based on the feedback required from below, adaptation is used to adjust. And the same is true at every level. It is ultimately the responsibility at each level to provide realistic expectations to above and below, to measure what is happening, seek improvements, recognize limitations and failures, and find a path forward to constrain the future to desired outcomes.

The actual situation at each level should also feed the model of the model-based situation anticipation and constraint analysis so as to adapt the parameters of the model to anticipate more accurately over time, identify potential problems that could move the situation outside of the desired future envelope before the outcomes become unavoidable, and try alternatives to adapt in internal OODA loop time frames soon enough to meet expectations from the higher level time frames. This is informed by models such as the sales sieves identified in other articles in this series.

A call to action

Want to meet folks who can help you get all of this figured out for your company? Sign up to our free ...

It's just a quick introduction to other folks like us. People you meet who you might end up working with for the rest of your life. And ideas that may lead you to the next fun thing.

In summary

A company can be viewed as a multi-layered cognitive system adapting over time to meet desired outcomes. By taking this approach, an understanding of the sources and consequences of success and failure may be modeled effectively and used to track and adapt performance..