Not every company needs to catch up

Some companies know what they need to improve and can buy the right tool, but do not have the team required to incorporate it.

It is not always a budget problem, nor a lack of will. Between the tool and the operation lies a distance filled with data that does not fit, applications built at different times, decisions no one has written down, exceptions known only to a few people and processes that work because someone knows where to look when something goes off track.

Monreal & Meadow works precisely in that space. We assemble a modular team around a specific outcome and bring together the business, operations and technology capabilities the company does not have in-house. We start with the systems already in place, build the connection to the new tool and prepare the organisation to govern the outcome.

The benefit is not adding people during a project. It means incorporating a capability now that does not yet exist within the company and retaining it when the team leaves, without hiring a complete technological structure from the start, replacing everything that works or ceding control to a supplier.

The usual response is that the company needs to catch up: migrate its systems, organise all the data, document the processes, hire a technology department and first build the foundations it never had. Then, once that transformation is complete, it can adopt the new tool.

The approach sounds reasonable. It can also turn the starting point into a sentence: because the company lacks the capacity to modernise, it must modernise before it can acquire that capacity.

Our approach changes the order. Instead of reproducing all the missing stages one by one, the company incorporates the capabilities necessary for a specific mission and moves forward from the point at which it is.

It is not a way of skipping the work. It is a different way of doing it.

India did not first need a fixed line for every mobile phone

The concept of leapfrogging is used to describe a leap between technological generations: adopting a new infrastructure without first extending, on the same scale, the previous generation. The International Telecommunications Union has precisely used the expansion of mobile phones compared to fixed lines as an example of this pattern: World Information Society Report 2007.

Telephony in India offers a particularly clear image. According to statistics from its Telecommunications Department, in 2001 the country had 3.58 million mobile subscriptions and 32.70 million fixed lines. In 2010, mobile subscriptions had reached 584.32 million, while fixed lines stood at 36.96 million. The big increase in subscriptions did not come after building an equivalent fixed network. It happened on mobile technology: Telecom Statistics India — 2025.

It would be a mistake to tell this story as if it were enough to hand out phones. India did not skip the need for infrastructure, investment, operation and rules. Its 1999 national telecommunications policy already linked the expansion of access to private participation, competition, tariff reductions, technological advances and new licence categories: New Telecom Policy, 1999.

Mobile technology made it possible to bypass one stage, but required the conditions for the next to be built.

There's the useful part of the analogy. Skipping does not mean ignoring what is missing. It means distinguishing which stages are no longer necessary and which capabilities are still essential.

Buying access is not adding capacity

The same difference appears within a company. Hiring a cloud platform, activating an artificial intelligence licence or purchasing a new management system gives access to technology. It does not guarantee that the organisation can use it to work in any other way.

To do so, the company must recognise what problem the technology can solve, connect it to reliable information, adapt it to its rules, decide who is accountable for the results and learn how to operate when an exception appears. In short, it must absorb an external capability and make it part of the operation.

Research on innovation in small businesses has been pointing out this difficulty for some time. A study based on more than 1,500 small business owners treated the ability to absorb and manage knowledge as a precondition for adopting innovations and growing: Open University — Absorptive capacity, knowledge management and innovation in entrepreneurial small firms.

The observation sounds abstract until a new tool arrives in a company where no one can assess it, integrate it or support those who will have to use it. The technology is available. The capability to incorporate it is not.

A modular team builds from both sides

A modular team serves to close that distance. It is not a bag of hours or a group of specialists that receives requirements, delivers software and disappears. It is formed around an outcome and combines only the capabilities necessary to achieve it: operational knowledge, process design, data, integration, software or adoption, depending on the problem.

The team must be able to work from both sides. From technology, it must know what is possible and build it with rigour. From operations, it must understand what information exists, which rules must be respected, where risk is concentrated and what would have to change for the new solution to be used in practice.

That dual perspective matters. If the team understands only the tool, it will try to make the company adapt to it. If it understands only the operation, it may simply digitise the current way of working, including its problems. The module must preserve what adds value and question what exists only through inertia.

The word modular does not mean that people are interchangeable. It means that the mission has an understandable boundary, that the relationship with the rest of the system is designed, and that the composition of the team can change as the problem changes.

Enter through one decision, not a total transformation

Imagine a company that takes too long to prepare quotations. Customer data sits in a simple CRM, rates live in the management system, some conditions depend on spreadsheets and technical feasibility requires operational judgement. No one designed the whole as a single flow, but the business has learnt to make it work.

A total transformation would attempt to replace several systems, unify all the data and standardise the entire process before producing the first quotation. A modular team can start differently: follow one quotation from start to finish, identify which decision causes the longest wait, connect only the necessary information and build a focused intervention around that point.

Perhaps the solution reads unstructured documentation, prepares a draft set of requirements and gathers the data operations needs for validation. It may simply expose an inconsistency before the quotation reaches the next team. Artificial intelligence may form part of the module, but it is not the reason the module exists. The reason is to change the flow without forcing the company to replace everything that already works.

If the intervention improves total time and reduces rework, it can be expanded. If it does not, the team must be able to withdraw it without jeopardising the core operation.

Modularity turns an abstract transformation into a delimited and reversible decision.

Skipping stages is not skipping work

Current tools allow you to build a demonstration with extraordinary speed. That speed can create a dangerous expectation: if the prototype appears in days, the company must also change in days.

This is not usually the case.

The slow part is figuring out why two departments call the same data differently, which customers need an exception, who decides when an automation is in doubt, what happens if an integration fails, how a result is verified, and what the internal team should learn before taking over.

This work requires you to review spreadsheets, observe decisions, reconstruct rules and accept that the process described does not always coincide with the real process. It also requires building trust between people who know the business but don't speak the language of technology and people who master the technology but don't yet understand all the nuances of the business.

It is difficult because you are doing something more important than installing a tool: you are translating an organisation.

The difficulty does not justify extending the project indefinitely. It does explain why progress cannot be measured solely by the speed of development. A module can be technically finished and still completely outside the company.

Transfer starts before delivery

The most obvious risk of incorporating an external team is replacing a lack with a dependency. The company gains a tool, but every change, error or doubt continues to need the same people who built it.

That is why the transfer cannot consist of delivering documentation at the end. It begins when people in the company participate in the decisions, understand the criteria, test the system, and learn what to do when the actual case does not match the expected one.

They don't need to become developers or master every piece of architecture. They need to be able to govern the capability: know what result it should produce, recognise when it deviates, decide what can be modified, and distinguish an ordinary case from an exception that requires help.

A modular team does not prove its value when it arrives. It proves it when it can leave.

If the team leaves and everything stops working, you have not built a module. You have built a dependency.

The test does not require the company to be self-sufficient in everything. It may still need specialised support, just as it uses tax advice, industrial maintenance or legal services. The difference lies in preserving its criteria and decision-making capability rather than delegating its understanding of the system as well.

The starting point does not have to decide the trajectory

Companies with limited technological resources are usually offered two equally impractical options. One is to buy a standard tool and hope the organisation adapts. The other is to undertake a complete transformation requiring time, money and specialists they do not have in the first place.

A modular team opens a third route. It allows the company to bring in, temporarily, a combination of capabilities it does not need—or cannot afford—to retain in full. The team comes in for a concrete outcome, works with the systems and people already there, builds the connection to the new technology and leaves the organisation with the criteria required to continue.

That is why, at Monreal & Meadow, we do not treat a modular team as a catalogue of specialists. It is a way of intervening in an organisation without pretending it starts from scratch and without turning its entire technological history into a debt that must be paid before progress can begin.

The case of India does not demonstrate how a company should modernise. It does leave us with a powerful idea: an inherited limitation does not always force an organisation to follow the conventional route. It can reach the next generation if it builds the conditions required to incorporate it.

Not all companies need to catch up.

Some need a team that enables them to leap ahead.

The leap is worth it when, upon completion, the company can already sustain it.

Evidence

Not every company needs to catch up. Some need to leap ahead.