The Management Abdication Hidden in the Word “Bridge”
“Bridging technology and management” — IT consulting and DX support services using this phrase have surged recently, even for SMEs. The case of “Re-Jume LLC” reported in the Sanyo Shimbun the other day is one such example. They position themselves as an “IT strategy/DX support partner bridging technology and management,” aiming to be the intermediary that technically realizes a leader’s vision.
At first glance, it seems like an ideal solution. For leaders lacking technical expertise, it appears a reliable partner has arrived. However, this is precisely where the most critical “pitfall” we executives must be wary of exists. It’s the risk that the very act of “bridging” justifies a fundamental “abdication of decision-making” regarding IT in management.
Many executives are merely sliding their dependency from a state of mental shutdown where “technology is left to the experts” to a state where “bridging technology and management is left to the experts.” Far from making IT function as a management decision-making apparatus, this only results in adding a new black box: the external partner.
The New Personalization and Integration Failure Caused by “Bridge-Builder” Dependency
So, what happens concretely if you continue to rely on “bridging tech and management” support? It’s the reproduction, in a more opaque form via external partners, of the “personalization of the IT department” or “IT fragmentation by business unit” that once existed internally.
For example, an executive presents a vague vision like “I want to increase sales.” The support partner hears this and proposes implementing the latest marketing automation tool or CRM. Post-implementation, the partner teaches how to operate the tool and read reports, but the essential understanding of “why that tool is optimal for our sales structure” or “how to leverage that data for management decisions” does not remain with the executive.
As a result, the “why” between management decisions and IT implementation accumulates as tacit knowledge within the external “bridge-builder” partner. This is an extremely dangerous state. If the partner changes, the logic behind past IT investments and the context of data are highly likely to be severed. Using multiple partners leads to a proliferation of different tools and data systems proposed by each, creating an unintegratable state of “IT warlordism.”
This is the worst-case scenario where the three IT classifications of “Operational IT,” “Management IT,” and “Administrative IT” are built separately by different external partners without a common purpose. If you entrust growth-oriented IT (Operational IT) to Company A, decision-making IT (Management IT) to Company B, and infrastructure (Administrative IT) to Company C, they will almost never work together.
How to Distinguish a Good Support Partner from a Bad One
So, am I saying not to use external support at all? Not at all. The key is the perspective of utilizing a partner as an “investment,” not a “dependency.” To do this, you must rigorously assess the following points when selecting a partner.
1. Do they force the process of verbalizing the “why”?
An excellent partner persistently asks the executive, before proposing any tool, “Why is this function needed?” and “How do you think it will change which business processes and what outcomes (KGIs) will it produce?” Their value lies not in providing “answers” but in supporting the executive to build their own logical pathway for holding “questions” and making “judgments.”
2. Are they serious about knowledge transfer?
Are they proactively trying to transfer knowledge that elevates the executive’s own IT literacy—such as “how to view data for decision-making,” “frameworks for investment decisions,” or “evaluation criteria for tool selection”—rather than just providing operational manuals? The key is whether they propose building a relationship with an eventual “graduation” in mind.
3. Do they commit to designing your company’s “IT decision-making flow”?
The most valuable support is not the introduction of a specific tool but helping to design the very flow of “how, by whom, and based on what criteria will our company make IT-related decisions going forward.” This is nothing less than redefining the relationship between management and IT.
How Executives Should Start Building “IT Decision-Making Capability” Now
Before choosing an external partner, or while working with a good one, there are concrete methods for executives to build their own “IT decision-making capability.” It’s not about grand study sessions; the accumulation of small, daily judgments is crucial.
First Step: Return “SaaS Contract Renewal Reviews” to Management Judgment
In many companies, SaaS contract renewals for tools like Asana, Slack, Salesforce, or Money Forward are handled almost automatically by the responsible department or IT. This is the perfect first training ground. At renewal time, the executive themselves should ask each department head the following three questions:
- “Who are the main users of this tool, which tasks did it replace, and which tasks did it create?” (Visualizing impact on business processes)
- “How have processing times or quality (error rates, etc.) for the relevant tasks changed before and after introduction? Please show numbers if possible.” (Attempting to quantify effects)
- “If this tool disappeared, what would be the biggest problem? What are the alternatives?” (Extracting the tool’s essential value)
This inquiry itself has a powerful effect of pulling the department’s IT use from “taken for granted” back to “a result of choice.”
Second Step: Design Small Automation Projects as “Management Experiments”
Small-scale RPA or AI utilization projects, like “automated invoice data reading” or “automated customer inquiry routing,” are perfect learning materials. Design these not as “tool introductions” but as “management experiments” with the following elements clarified:
- Hypothesis: “If we automate this task, employees can allocate time to high-value-added work like [X], resulting in an improvement in [Y].”
- Verification Metrics: Time (man-hours) reduced by automation, outcomes of the redirected work, changes in error rates, etc.
- Evaluation Criteria: What level of results relative to the investment (tool cost + implementation effort) constitutes “success”?
Create a habit of sharing the results of these experiments, however briefly, in management meetings. The goal, whether successful or not, is to turn that “decision-making process” into organizational knowledge.
What Should Lie Beyond “Bridging”: The Permeation of Management IT Literacy Throughout the Organization
The true “bridge between technology and management” should not be an external consultant or support partner, but the executive’s own IT literacy and the internal decision-making flow built upon it.
An ideal support partner acts as a “designer” or “coach” to help construct this “bridge” internally. They may temporarily undertake “bridging” work, but their essential value lies in transplanting the capability for the company to independently “bridge,” further “integrate,” and “create” in the future (=IT decision-making capability).
When seeking partners like those reported in the Sanyo Shimbun who tout “bridging tech and management,” discern whether they are mere “contractors” or true “capability transfer agents.” This discernment is the watershed between DX investment ending as a “dependency cost” or becoming an “investment in independence.”
What executives must learn from IT is not coding skills, but the core thinking framework of management itself: “defining objectives, selecting means, and verifying results.” That will become the sole, unchanging competitive advantage that remains long after any digital tool becomes obsolete.
Comments