The Prestige Trap: A Nine-Figure Lesson in Strategic Humility
(Voir ce lien pour la version française)
My introduction to our company's data platform came with a troubling response to an urgent ticket. Three days after opening the ticket and reaching out to multiple people, the team in Europe finally responded to the IT team on the other side of the planet: "It is on the list of things to fix, and will be delivered in 3 to 6 months."
So the first question we asked was logical: "Who prioritizes the backlog and how can it be delivered earlier?"
The answer was more than surprising: "The developers do."
How could the backlog of a multimillion-dollar platform be prioritized by developers when business operations around the globe depend on it? It was a thorny question, but entirely valid in the context of an international corporation where one team's delivery affects business worldwide. To understand why things operated this way, we had to dig up the corporate strategy story from seven years earlier.
In that moment, I realized I was looking at a symptom of a much deeper organizational dysfunction, one that would eventually cost the company over $100 million and countless missed opportunities.
Prestige Over Expertise: When Consulting Brands Trump Internal Knowledge
The whole data and analytics platform journey began with hiring a prestigious consulting firm to act as our oracle: "Tell us which path we should take!" From a technology perspective, many options existed. Each cloud provider offered a distinct solution that was viable, tested, and deployed in other international corporations. The options weren't scarce; the strategy primarily concerned the mission and vision of what the platform should achieve, whom it should serve, and what future it would create.
The consulting firm spent a few months investigating, as they typically do, and returned with a polished slide deck for the Director of Data and Analytics. They recommended building the data platform on one cloud provider and the analytics platform on another, arguing that each offered unique capabilities or cost advantages in specific areas. This approach would provide scalability without vendor lock-in, they claimed, and because similar-sized companies had succeeded with this architecture, they were confident it would work for us.
The director of data and analytics was from the Finance and ops control teams, one of the paths every "Grandes Écoles" member working in the company was offered to undertake, in due of becoming Director, VP, CEO later in their career. Soon after his appointment, the department was filled with fresh blood with "nom à particle," as we say it in French, becoming one of the departments with the highest number of French aristocracy members and elite school graduates. It was promising to deliver high-quality service to the business, thanks to the excellence supposedly brought in by France's top social class.
The Leadership Paradox: Managing What You Don't Understand
Manuel, whose resume and credentials matched neither aristocracy, elite schools, nor data platform experience, was appointed to get the data platform running. It was likely a miracle of networking and HR's push for diversity, one of those welcome anomalies. After a few months, he hired software engineers to implement the slide deck recommendations. Another person was assigned to develop and deliver the analytics platform. Two engineering teams worked side by side, physically, on two different clouds, with two different methodologies.
The data platform team consisted entirely of technically skilled developers (average age 27) with minimal exposure to the company's core business operations or P&L structure. Without established governance mechanisms, they operated with near-complete autonomy: determining feature priorities, technical architecture choices, and delivery timelines independent of market needs or revenue impact. The capabilities were developed with a headquarters-centric mindset and deployed locally first, expanding to international markets only upon specific request, creating a perpetual lag between market requirements and technology capabilities. Despite their technical aptitude, the team lacked the cross-industry perspective that comes from having implemented similar platforms across multiple enterprise environments, leading to innovation without context-appropriate application.
The Value of Applied Experience: When Process Outperforms Pedigree
The analytics team, by contrast, hired an external consulting company specialized in their chosen cloud technology. These consultants not only had knowledge and certification in the cloud services they were building but had delivered similar platforms for previous clients. This team also benefited from direct exposure to business needs. Since their reports were consumed by business stakeholders, when something wasn't working, they had their fingers in what I call "the boiling water": they could see, hear, and feel the pain caused by poor design, prioritization, or delivery. They employed a professional scrum master for the core team, formed squads as demands increased, and prioritized their backlog according to emergencies and business impact.
The technical leader of the analytics team was an atypical personage, fervent supporter of French far left values, trading cryptocurrencies and serial entrepreneur as a side hassle, with a perfect mastery of branding, marketing and communication. It was a fun "clash of clans" to watch, seeing French aristocracy work hands-in-hands with rich crypto boys of the far left, defending the working class. A mastery painting of George Orwell's "Animal Farm", and how paradoxes and dichotomies can live side-by-side, in a mini society within the corporation.
These contrasting organizational cultures revealed how leadership approach and team composition directly impact technical outcomes and, ultimately, business value.
The Hidden Costs of Technical Debt: Invisible Until Catastrophic
Beyond personality, education, social class, and team formation patterns, engineering approaches emerged as a stark differentiator between the teams. Having been trained in delivering engineering projects for production plants across various industries, I brought a methodical approach to engineering with standardization always in mind. IT engineering was an area where I could quickly spot anomalies, as many engineers lacked structured approaches to design and implementation.
In production plant design, bad engineering becomes visible to inspectors sooner or later. Sometimes, the evidence of poor design remains visible throughout the plant's life, like when French engineers designed a production facility for the Netherlands using French average height measurements. During startup, watching Dutch colleagues repeatedly hit their helmets on structures made the design flaws and resulting embarrassment palpable.
In IT, bad engineering can remain hidden for years. It's buried in code, and when everyone is accustomed to what appears "unstructured," nobody notices the problems. If you brought manufacturing or engineering employees to review IT work, they would immediately point out missing design reviews, design authority signatures, naming conventions, engineering templates, and documentation standards.
Engineering Excellence: The Competitive Advantage of Standardization
The data team employed a chaotic engineering approach with minimal documented best practices, standards, or templates. A routine task like adding a new data engineer to the platform could take days. Someone had to sift through hundreds of lines of access rights code to determine where to add the new engineer's name and which access rights to grant. Additionally, all data engineers worldwide required two interviews by the central team for approval.
The analytics platform team, staffed with more experienced consultants, took an entirely different approach. After delivering their first few projects, they documented processes in detail, established naming conventions from architecture deployment to service delivery, and created standardized templates covering pipelines and various engineering components. These templates incorporated best practices while allowing customization for complex scenarios. The team offered technical advisory services to engineers with complex designs or questions. They also standardized the hiring process with written quizzes containing practical questions, interviewing candidates globally, and providing an open-minded, development-oriented perspective for onboarding anyone with certifications and intermediate knowledge. This collaborative mindset had developed through years of working across different contexts, companies, and business lines, bringing valuable outsider insights.
The Bureaucracy Trap: When Security Becomes an Obstacle to Business
Another puzzling aspect of the data team's design stemmed from their limited understanding of business operations and systems. The security setup made little practical sense. Users who already had access to data within business applications - having gone through approval processes with various business and IT stakeholders- had to create multiple tickets to access the same data on the platform. These tickets required review by Manuel and others in central team and locally, before access was granted to data the users could already see in their business applications.
In reality, access control in business applications was customized per application rather than defined at the company level or role-based. Most systems used named access with business approval, IT approval, or both. This meant that when onboarded, employees had to gradually discover which systems they needed and request access to each one individually. Instead of adopting and extending the existing application access rights, the data team implemented an additional layer of access controls that hindered users. When this issue was raised in meetings, their only response was: "Following application security requires complex coordination, and we have decided not to pursue that approach."
The Wisdom of the Organization: The Untapped Strategic Resource
"Which one of you approved the data platform and analytics platform architecture and strategic direction?" I asked a group of IT architects during lunch, years after the platform had been established.
Their collective answer told the whole story: "None of us!"
One architect explained that multiple IT engineers, infrastructure specialists, and enterprise architects from around the globe had warned the Director of Data and Analytics that the consulting firm's design disregarded company history and was unsuitable for their operations. They had emphasized three critical points: using multiple cloud providers would create unnecessary complexity; finding resources globally for niche cloud skills would become increasingly difficult; and most presciently, they predicted users would find creative ways to bypass excessive validation requirements, leading to shadow IT proliferation.
The director's response was revealing of how decisions become locked in prematurely: "We have already shown the plan to the board, and we can't change it."
Later, I confirmed this pattern when hiring consultants with experience in banking and other data-intensive environments. Within their first weeks, they invariably observed that our dual-cloud approach was outdated in their industries, and crucial other services were missing. But when these concerns reached the central data team, Manuel's response in Q&A sessions said everything about the organizational culture: "Get yourself a lab account and test whichever service you'd like. We're keeping the architecture as-is."
Organizations rarely lack expertise. They lack mechanisms for that expertise to influence decisions before momentum makes them irreversible. The people who best understand your operational realities are often those who've navigated your systems for decades, not those with the most prestigious degrees or the glossiest slide decks.
The Inevitable Reckoning: When Strategy Corrections Become Unavoidable
The prophecy of our internal experts was finally acknowledged seven years later, but not through enlightenment, but through pain.
When increasing cloud infrastructure costs alarmed the board, more projects struggled to find skilled engineers with proven experience in specific cloud services, and users, frustrated with the bureaucratic steps imposed by headquarter, created their own data and analytics solutions. That's when we faced the difficult decision to discard the existing platforms and implement what the internal architects had suggested seven years earlier.
Despite the $65 million investment in the first-generation platform and delivery of numerous projects and enhancements, the board ultimately approved an additional $35 million to build the replacement platform and migrate everything from the old system. The new generation platform prioritized self-service accessibility to reduce the shadow IT expenditures that had emerged as business units sought workarounds to the bureaucratic centralized system.
The true cost of strategic missteps is measured in the compounding effects of operating with the wrong model for years, and then the painful correction required to get back on track. Seven years of organizational friction had created habits and workarounds that would take years to unwind.
The Organizational Imperative
Strategic technology governance requires the same rigor applied to capital allocation, M&A evaluation, or market expansion decisions. Technology architecture decisions are fundamentally business strategy decisions with long-term implications for organizational agility, market responsiveness, and operational excellence.
As enterprises increasingly compete on their ability to leverage data assets, the architecture supporting those assets cannot be delegated without clear accountability to business outcomes.
The defining characteristic of market-leading organizations is in developing governance structures that allow rapid detection and correction of misalignment between technology investments and strategic priorities.
Strategic Imperatives: Transforming Enterprise Technology Decisions
If you're planning a major data platform today, resist the impulse to simply promote a brilliant internal engineer or bring in a prestigious consulting firm to dictate your path. Instead, hire consultants who have actually built similar platforms for companies your size. The difference between theoretical knowledge and battle-tested experience becomes painfully apparent once you're deep into implementation.
Before writing a single line of code, take time to deeply understand your operational reality. Connect with business lines across all your geographies. Gather requirements from directors down to operational specialists who handle data daily. This approach reveals patterns that would otherwise remain invisible—the same pain points emerging independently across markets and functions.
Connect with IT architects with 10+ years at your company. These are the institutional memory bearers who can explain why certain approaches had failed in the past. They know the organizational patterns that would challenge any new initiative, and they understand the hidden connections between systems that no documentation has ever captured. Their knowledge isn't theoretical, it was earned through years of watching ideas succeed or fail in your specific context.
As I have emphasized in many editions of ITOLOGY™, doing your homework, speaking with IT and business stakeholders globally, is crucial for understanding what people truly need. This approach prevents building systems that you'll discard and rebuild years later, along with the massive costs your company will bear because someone without subject matter expertise hired an expensive consulting firm, presented recommendations to the board without adequate stakeholder input, and set off a costly cascade of consequences.
A strategy affects many people, and a representative sample of those impacted should participate in defining it. Strategic planning is not a one-person show!
Listening is essential when creating a new department, service, or capability for an international company. If you build something with fancy features that developers think necessary while delaying features the business needs, you're spending money in the wrong places. Remember: if you haven't spent enough time listening before launching a multi-million-dollar endeavor, you're following a recipe for failure.
Is everyone in your company globally dependent on a single team in HQ or India for a service they all use for business decisions? If so, you're paying the price of oversimplification, losing money due to centralization. Taking the easy route carries a significant cost. It might make that team feel important - kings of the world - while making everyone else frustrated, waiting for these "kings" to address their tickets, which are buried among hundreds of others, while the centralized team remains too distant to notice "the rising temperature on the thermostat."
The most successful enterprise platforms aren't designed by the most brilliant software engineers. They're designed by those who understand that technology serves the business, not the other way around.
For more content like this visit: https://www.globaldataandbi.com/resources
Disclaimer: Any resemblance to real persons, living or dead, or actual events, or actual organizations is purely coincidental.
#ITOLOGY #DigitalTransformation #ITStrategy #Leadership #TechnologyGovernance #EnterpriseArchitecture #StrategicBlindspots #TechDebt #ITGovernance #CorporateStrategy #CIO #CXO #DataLeadership #EnterpriseInsights #FutureOfIT #ChiefInformationOfficier #InsightCorporateStrategy
