Core Competencies?

Time to Read 5 min

Core competencies, or rather their preservation and protection, are always an issue when companies work with external development service providers. "Core competencies" is very easy to say. However, I believe that the topic deserves some deeper thought:

What Actually are Core Competencies?

Core competencies are the skills, the operational knowledge, which distinguishes you from your competitors, which cannot be easily substituted. With these "distinctive" competencies you create value for your customers, you differentiate yourself and make yourself difficult to substitute for your customer.

Most companies can name their core competencies relatively quickly. But where are they located in an organization in the first place?

Where are the Core Competencies?

To see where the core competencies are found in an organization, it is important to remember that it is about action knowledge, i.e. how to do something, not only about theoretical knowledge per se.

So where are these competencies?

• With the key employees? The service department knows it?
• The boss knows it? The founder used to know it?
• In the source code of our software? In the electrical and electronic schematics?
• In the machinery, measurement equipment and tools?
• In our Sharepoint? In the inbox?

Or would they also need to be generated consciously?

• In up-to-date product architectures?
• In updated requirements specifications, technical architecture and design documents?
• In processes, checklists and templates? As "organizational knowledge"?

So there are tacit and explicit core competencies, personal and collective. Basically, four variants of core competencies, of knowledge, can be distinguished.

What are the Advantages and Disadvantages of these Variants?

• Personal knowledge: Someone knows
  • Advantages:
    • The knowledge can be tapped very easily, when you ask for it.
    • The knowledge is simply there, there is no additional effort to file or maintain the knowledge.
  • Disadvantages:
    • How do you find out who knows what?
    • What happens if this someone leaves the company?
• Organizational knowledge: In processes ("quality management system"), checklists and templates
  • Advantages:
    • The experiential knowledge is explicit, especially if you update the e.g. checklists every time a mistake has happened or other new knowledge arises.
  • Disadvantages:
    • The maintenance of the process documents ("quality handbook") must be ensured.
      • By the people concerned, not by the central quality department... Because otherwise not the practical experience but airy theory is documented.
• Architectures: in product architectures and technical architecture and design documents
  • Advantages:
    • The information about why something was done is explicitly available.
  • Disadvantages:
    • The documents have to be created and maintained, which is not always the first priority in the heat of the moment.
• Work results: In source code, in schematic and layout documents, in production and manufacturing documents
  • Advantages:
    • This data is generated anyway, so there is no additional effort to generate and store it.
  • Disadvantages:
    • Is the important information really in there? It says what was done, but usually not why. Without additional information, these records leave a lot of room for interpretation and need a lot of time for rework. I.e. if we want to change something or develop something new, how do we know which solutions are really important, and which were simply chosen because it did not matter?

Core Competencies and External Partners

What happens to your core competencies when you work with external partners? Is the way of having freelancers on the team really the best variant to secure core competences? Are you sure that they generate architectures and organizational knowledge, too? Or do only work results remain and on the last day the personal knowledge leaves the company together with the employee?

How are Core Competencies Preserved?

The problem of the lack of safeguard, of protection usually becomes apparent too late. E.g. when companies are sold and the important employees leave the company for "integration reasons": this means that all the knowledge is gone. Or if the one engineer retires who has determined the architecture of the whole product, then nobody knows anymore why the software works and why it must be coded in such a way and not differently.

The protection of stored knowledge and work results is usually driven by a risk management approach (lines of defence etc.). This is necessary, but in my opinion not sufficient, because very few organizations ask themselves in risk management whether everything that would be worth protecting is actually written down somewhere.

What would then be Meaningful Protection?

Disclaimer: such an approach is very tedious and therefore not suitable for every organization.

1. Identify core competencies
2. Find out where they are actually stored
   • Processes/ Templates/ Checklists: As long as these have a certain maturity, i.e. there are written processes, which are not only shown to ISO 9001 auditors, but are lived.
     This also gives a new perspective on process creation: the maturity should not be high where it is easy (for which there are e.g. templates on the Internet or standards from consultants), but where the core competence is. This is by definition distinctive, i.e. it cannot be mapped in the same way as in other organizations using the same templates or ERP-modules.
   • Enhancement: The process assets are further developed from the knowledge of those affected and from the knowledge from the projects.
   • Product Architecture: When it is documented in a meaningful way (with a certain maturity), i.e. there is a manageable number of readable and structured (according to processes) documents for each product group, not just a ticket pile or an opaque Wiki- or Sharepoint-repository where you can only find your way around thanks to the search function.
   • Maintenance: There is a meaningful maintenance of all documents ("Knowledge Management") over the product lifetime.
3. Prioritize the creation of process assets and architecture documents where they are still missing or only exist as personal knowledge in the heads.

This also closes the circle to the cooperation with external parties: Choose a partner who delivers the intellectual property also as detailed requirement specifications and structured architecture documents, and from whose experience you can benefit in checklists and templates.

Without lock-in, you can let an engineering firm also work on your core competencies. You then get all the knowledge, all the core competencies that have no legs, namely work results, architectures and even additional organizational knowledge. And if the engineering company has long-time employees, then even the access to the knowledge in the heads remains....

Andreas Stucki

Do you have additional questions? Do you have a different opinion? If so, email me  or comment your thoughts below!