When designing the Competitive Intelligence Function, we need to make two distinct decisions: how to organise the modelling of intelligence needs -centrally or in a distributed way- and how to approach deployment -progressively through a Land & Expand strategy or simultaneously across the organisation-.
Should we have a corporate team managing the intelligence needs of the entire company? Is it better for each department or division to have the autonomy to model its own needs? Should we progressively bring new areas on board, or embark on a company-wide rollout from the outset?
Visit the Antara Academy – «How to implement the Intelligence Function in your company »
These questions address two different dimensions that should not be confused:
And there is still a third question that needs to be considered separately: who analyses the information and creates value from it.
Because centralising the leadership of the Function does not mean that we should also centralise analysis and knowledge creation.
Within a collaborative Competitive Intelligence Function, we can broadly distinguish between two main types of responsibility.
An analyst does not necessarily have to be someone who has that job title on their business card. It could be someone in R&D who understands a particular technology, a commercial manager who understands the implications of a competitor move, a regulatory specialist capable of interpreting a new regulation, or someone in Procurement with deep knowledge of a raw-materials market.
Some time ago, we used a metaphor to explain this evolution of Competitive Intelligence: the Intelligence manager is more like the conductor of an orchestra than the head of a large department of analysts. Each member of the orchestra knows their instrument better than the conductor; the conductor’s job is to ensure that they all perform in a coordinated way.
That principle remains valid when we design the deployment strategy.
At Antara, we recommend distributing analysis among as many relevant experts across the organisation as reasonably possible. They are the people with the knowledge required to correctly interpret what is happening in the external environment.
What we do need to decide is how far we also want to distribute the leadership and modelling of intelligence needs.
Imagine an organisation with several divisions — energy, civil engineering, waste management — or departments such as R&D, Marketing, Procurement, Regulatory Affairs and Business Development.
Each of them has different questions to answer and, therefore, different monitoring priorities.
R&D may want to track an emerging technology. Marketing may want to monitor launches by specific competitors. Regulatory Affairs may need to follow the development of new legislation. Procurement may be interested in new suppliers or supply-chain risks.
Read the article: Intelligence Directive: what should I monitor in my company?
Who should turn all these needs into an operational monitoring system?
There are two main alternatives.
In a centralised model, there is a corporate Intelligence leadership team that engages with the different departments and models their needs.
People in R&D, Marketing or Regulatory Affairs explain what they need to know through discussions with the Function’s leader or leaders. The central team translates those needs into monitoring priorities, configures the system, evolves the model as priorities change and assigns responsibilities.
The main advantage of this approach is that it reduces training requirements. Analysts in each division or department do not need specific training.
We do not need to train Intelligence managers in every division. A small group accumulates experience, maintains common criteria and can quickly gain a strong command of both the methodology and the platform.
It is also easier to maintain consistent governance.
However, there are two important limitations:
Someone in the corporate team may understand the Intelligence methodology perfectly, but they are unlikely to have the same depth of knowledge of the terminology, technologies, players, problems and priorities across every unit of a complex company.
A centralised model therefore works particularly well when the Function still has a limited scope, when we have only a few trained leaders, or when the needs of different departments share a substantial common base.
As the diversity of the business increases, the central team risks becoming both a bottleneck and an intermediary too far removed from the problem it is supposed to model.
The alternative is to distribute some of that responsibility.
In this model, each division, department or unit has one or more Intelligence managers trained to engage directly with their colleagues and model their needs.
R&D configures its technology-monitoring priorities. Marketing does the same with competitors, customers or trends. Regulatory Affairs maintains its own.
The corporate team does not disappear. Rather, it becomes smaller and its role changes: it ensures that everyone works according to common criteria, provides methodology and training, monitors metrics, identifies problems and best practices, and drives continuous improvement of the Function.
The advantage of the distributed model is that the person modelling the need understands its context and semantics far better. They do not need an intermediary to first learn how their market, project or technology works. If the intelligence priorities to be modelled are highly technical or require deep business knowledge, it will often make more sense to train a technical specialist in Intelligence than to train an Intelligence expert in every technology or business area covered by each division. It has often been said that it is much easier for an engineer to evolve into a salesperson than for a salesperson to evolve into an engineer.
But that autonomy and distribution of responsibility comes at a cost: we need to train more people and devote more effort to coordinating them. We may also find that one division makes excellent use of the Function while another achieves poorer results because its managers devote less attention to it or apply the methodology less effectively.
Distributing responsibility increases adaptability, but it also increases the need for governance.
This is worth making very clear.
Suppose a company chooses a completely centralised model for configuring and maintaining its intelligence needs.
That does not mean that a handful of people in the corporate team should have to read and interpret everything happening across the company’s competitive and technological environment.
We can have a small central team managing the system while, at the same time, dozens of analysts are distributed throughout the organisation.
Faced with the same signal:
This is one of the strengths of Collaborative Competitive Intelligence: the same piece of information becomes more valuable when it can be interpreted from different perspectives.
Visit the Antara Academy – ‘What is the Intelligence Cycle?’
So we should not confuse leading with analysing:
Intelligence is coordinated; knowledge is distributed.
Once we have decided how we want to organise leadership, we face another decision:
How quickly should we bring departments into the Function?
Here again, there are two main strategies.
Land & Expand means starting with one division, department or small group of them, getting the Function to operate effectively and then progressively replicating that best practice elsewhere in the company.
This approach fits naturally with the pilot we recommend when implementing an Intelligence Function for the first time.
Visit the Library – video ‘How to implement the intelligence software in the company’
Rather than running a ‘political’ pilot, involving one or two people from every department simply so that everyone is represented, it is usually better to concentrate efforts on one or two sufficiently motivated departments.
There we can learn:
Read the article ‘7 metrics for measuring the impact of Competitive Intelligence’
The aim is for this first initiative to become a best practice, giving us something far more convincing than a corporate presentation: an internal example that other departments can observe and want to adopt.
The main advantage of Land & Expand is therefore risk reduction. We learn before we scale.
Its drawback is that we will need more time to deploy across the entire organisation.
The objective is not to keep a pilot running indefinitely, but to learn enough from it to accelerate expansion afterwards.
The second alternative is to bring all — or a large proportion — of the planned divisions and departments on board from the outset.
Its main advantage is the speed of company-wide deployment.
It also avoids a problem that arises in some organisations: departments initially left out may interpret the new capability as something being built exclusively for the benefit of selected areas.
However, a simultaneous rollout requires greater preparation.
Design errors, adoption problems or methodological shortcomings that we would first discover in a limited environment under a Land & Expand approach may emerge simultaneously across many divisions.
If we have also chosen a distributed model, we will need to train a larger number of leaders from the outset and ensure that they all work in a coordinated way.
A company-wide rollout can be a perfectly valid option for an organisation that is mature and committed to the project. But faster does not necessarily mean easier.
At this point, we can cross the two decisions.
| Centralised modelling | Distributed modelling | |
|---|---|---|
| Land & Expand | The corporate team models the needs of the first areas and progressively brings new departments on board. | We begin with one or a few divisions, whose managers are trained to model their needs. We then progressively train and add managers from new areas. |
| Company-wide rollout | The corporate team simultaneously takes responsibility for engaging with and modelling the needs of all divisions. | From the outset, we train managers across multiple divisions, who model their needs locally under common corporate governance. |
There is no universally superior combination. Nor are we making an irreversible decision — although not everyone welcomes the idea of redesigning a project once it is under way.
We can guide the decision by asking ourselves a number of practical and relatively easy questions.
Serving R&D and Marketing is not the same as deploying the Function across twenty business units, countries or divisions.
The broader and more diverse the organisation, the harder it becomes for a small corporate team to understand and maintain all the different needs.
Two units working with similar technologies, markets and vocabularies can easily be managed by a common team.
But when the same organisation operates businesses with very different technologies, customers, regulatory frameworks and competitors, the value of having leaders close to the domain increases.
A distributed model requires us to identify and train the right people.
Giving someone permissions on a platform is not enough. The manager needs to understand the methodology, engage with internal clients and keep intelligence needs alive.
If we do not yet have those people, it will probably make sense to begin with a more centralised approach.
When we are still learning how to develop the Function, Land & Expand allows us to make mistakes on a small scale, learn from them and then turn that experience into a method.
If there is already previous experience, established processes and strong sponsorship from senior management, we may be able to consider a more ambitious rollout from the outset.
In many organisations, expansion depends on the initial results being strong enough to support an ‘internal sale’ of the Function.
In that case, it makes a great deal of sense to start where we can demonstrate a real impact on decisions most quickly.
See ‘Step 6. Launch the Competitive Intelligence pilot’ in the Antara Academy.
In other cases, the project originates directly from senior management and needs to provide a service to many divisions from the outset.
In that situation, it may make sense to accept the greater initial effort required by a company-wide rollout.
As guidance — rather than immutable rules — we can summarise the criteria as follows:
When a company starts deploying its Intelligence Function, it does not need to decide what its definitive organisational structure will look like five years from now. It is perfectly reasonable, for example, to begin with a centralised model and then evolve it.
For example:
Phase 1. Pilot
A small leadership team configures the system and works with a limited group of analysts.
Phase 2. Land & Expand
That team brings new departments on board and progressively expands the network of analysts.
Phase 3. Delegation
Some areas reach sufficient maturity to take local responsibility for modelling and maintaining their own needs.
Phase 4. Distributed Intelligence with corporate governance
Leaders in each area operate autonomously, but always within a shared methodology, platform and set of criteria. The corporate team coordinates the whole, monitors metrics and promotes continuous improvement.
This evolution is particularly natural in large companies: we centralise at the beginning what we still need to learn, and progressively distribute what we already know how to govern.
Those dreaded information silos in the company. Again?
A distributed organisation should not become a collection of departments developing their own Intelligence independently, each with its own tools, sources, criteria and repositories.
We would lose precisely one of the greatest opportunities offered by a corporate Function: creating synergies between knowledge held in different parts of the company.
As we explain when discussing how to implement the Intelligence Function, even in a distributed organisation it is advisable to maintain a common platform.
See ‘Step 8. Expand the pilot to the rest of your organisation’
Why?
Because one division may enrich the semantics of a particular area of the business — for example, M&A or startups — and the rest of the company’s analysts can benefit immediately and transparently. A signal initially identified for R&D may be important for Marketing. A regulatory development may affect Product. Information identified by one subsidiary may prove strategic for another. And we should not forget one of the major and unexpected effects of shared Intelligence: ‘educating’ the C-suite about the relevant R&D, marketing or business issues affecting each division.
Intelligence does not respect our organisational charts.
For that reason, even if we distribute responsibilities, we should retain at least a number of common elements:
The more distributed the Function becomes, the more important this common architecture becomes.
Since Antara was founded, we have had one objective: to make use of the knowledge of as many experts across the organisation as possible.
We do not believe that the best way to develop Intelligence is to create a large department to which everyone submits occasional, highly specialised requests that are needed ‘by tomorrow’.
The knowledge and capabilities required to interpret what is happening out there already exist within the company.
They are distributed among people in R&D, Product, Marketing, Sales, Procurement, Regulatory Affairs, Operations and Management. The challenge is to get the signals worth interpreting to each of them, and to ensure that their knowledge can be used by the rest of the organisation.
Read the article ‘Collaborative Competitive Intelligence: roles and workflow’
A different question is who should configure and maintain that machinery.
In a small organisation, or one that is just getting started, it will probably make sense for a central team to do so.
In a complex corporation with specialised divisions and sufficient maturity, it may make sense to distribute that responsibility progressively.
And the same logic applies to deployment pace. We should not choose a company-wide rollout merely because it appears more ambitious, nor adopt Land & Expand simply because it seems more cautious.
We should choose the model that reduces our risks while allowing us to learn quickly enough.
Centralising and distributing are not opposing concepts across the entire Intelligence Function.
We can maintain corporate governance, distribute the modelling of needs where appropriate and, at the same time, extend analysis and value creation across the organisation’s experts from day one.
That balance will evolve as the Function matures.
In a centralised model, a corporate team engages with departments and models their Intelligence needs. In a distributed model, managers within each division or department manage those needs directly, while a corporate team maintains coordination, metrics and continuous improvement.
Yes. This is the combination we recommend. A small team can coordinate and configure the Function, while a much larger network of experts analyses the signals relating to their areas of expertise.
It is a progressive deployment strategy. We begin in one or a few areas of the organisation, consolidate processes and best practices, and subsequently replicate the model in new departments or divisions while applying what has been learnt.
It reduces deployment risk because it allows us to learn and correct problems before extending the Function. The trade-off is that it takes longer to achieve full company-wide coverage.
It may be appropriate when there is sufficient methodological maturity, the resources required to deliver training across multiple areas, and strong corporate commitment to the project.
Not necessarily. It will depend on the diversity of needs, the size of the organisation and the maturity of the department or division. Some companies operate successfully with a corporate team; others need managers distributed by department, division, market or technological domain. And, of course, some organisations may delegate responsibilities to certain divisions but not to others.
Yes. In fact, this can be a natural evolution: start with a small central team, build up experience and progressively transfer responsibilities to other areas while maintaining common corporate governance.
The right structure depends on the nature of your organisation, the decisions you want to support, how many areas need Intelligence and which capabilities you already have available.
Discover how we can help you.
At Antara, we do more than simply get the software up and running. We help you design the rollout, train your team and evolve the Function as new areas begin to benefit from it.
If you are deciding how to organise and deploy your Intelligence Function, let’s talk.