There’s a moment in every complex technical initiative when you realize the technology isn’t the hard part. For me, that moment came three months into what would become one of the most challenging, and ultimately rewarding, projects of my career.
I was standing in a conference room, watching a backend engineer and a BI analyst argue past each other about a data field. They were both right. They were also both wrong. And the real problem was that they’d never actually talked to each other before that moment. Their managers had been “representing” them in weekly leadership syncs for months.
That’s when I understood: we didn’t have a technical problem. We had a collaboration problem dressed up as a technical one.
The Mandate Nobody Wanted
When I took over as Head of Engineering for the Banking & Matching domain, the company was at an inflection point. The company had successfully pivoted from a C2C lending model to B2C loan comparison, but the platform hadn’t caught up. We were running a validated business on architecture designed for a different company.
My mandate was deceptively simple on paper: introduce a new domain data schema, decompose our monolith into microservices, and migrate years of sensitive financial data, all while keeping the business running. In practice, this meant touching every function in the technology organization: Engineering, Data Science, BI, Product, Infrastructure, and our external banking partners.
The stakes were high enough that failure would have been measured in lost partnerships and regulatory scrutiny, not just missed deadlines.
The Leadership Sync Trap
I did what most leaders do when facing cross-functional complexity: I set up a weekly meeting with all the department heads. We’d exchange updates, flag dependencies, and leave feeling productive.
Except we weren’t.
Beneath the surface of those polished status reports, teams were interpreting our new data schema differently. Engineers were making assumptions that contradicted what analysts expected. Data scientists were building features on contracts that product managers didn’t recognize. Dependencies surfaced weeks after they should have, triggering painful rework cycles.
The irony wasn’t lost on me. I’d created a communication structure that actually prevented communication. By funneling everything through leadership, I’d turned department heads into translators, and something always got lost in translation.
Worse, when engineers disagreed with decisions their managers had made in those syncs, they had no outlet. The result was passive resistance, low trust, and a project that was slowly grinding to a halt.
Tearing Down the Walls
The fix required me to step back from the comfortable role of “leader who attends meetings” and become something messier: a facilitator who got his hands dirty.
With buy-in from department leads, I started organizing working sessions that put the actual practitioners in the same room. BI analysts sat with backend engineers and walked through data mappings line by line. Data scientists worked directly with my team to validate that the new schema would support their ML features. Infrastructure engineers coordinated with microservice developers on deployment patterns.
These sessions were often uncomfortable. People who’d been frustrated with each other for months suddenly had to work through their disagreements face-to-face. But something remarkable happened: when domain experts talked directly, the “misalignments” that had seemed intractable in leadership meetings often resolved themselves in minutes. Most conflicts weren’t actually about substance. They were about missing context.
For months, I became what I started calling a “cross-team amplifier.” My job was connecting dots, clarifying intent, and making sure no one stayed blocked for more than a few hours. It wasn’t glamorous work, but it was the work that mattered.
The Fear of Iteration
One of the hardest conversations was about how we’d actually execute the migration. Many stakeholders pushed for a big-bang release. Their logic was understandable: the systems were so intertwined that incremental changes seemed impossible. Better to rip off the bandage.
I disagreed, but I understood the fear behind the position. When you’re responsible for ML models that drive loan decisions, or partner integrations that affect millions in revenue, “let’s experiment” sounds reckless.
So I proposed a middle path: the Strangler Pattern. We’d build our new microservices and run them in shadow mode for months, processing the same traffic as the legacy monolith. We’d compare outputs obsessively, hunting for inconsistencies. Only after we’d demonstrated behavioral parity would we cut over.
This approach transformed the conversation. Instead of debating whether the new system would work, we could watch it working. Fear gave way to empirical confidence. Teams that had been defensive started collaborating on edge cases they’d discovered in the shadow comparisons.
Making Ownership Explicit
Much of the early conflict stemmed from ambiguous ownership. When everyone is responsible for data quality, no one is. When multiple teams can modify a contract, the contract means nothing.
I worked with stakeholders to define explicit boundaries. Engineering owned orchestration and the microservices themselves. Product owned feature interpretation. Data Science owned model training requirements. BI owned reporting transformation rules. Key Account owned partner-side expectations.
The shift was subtle but profound. Teams stopped arguing about who decides and started collaborating on how to implement. Clear ownership didn’t create silos. It created interfaces.
The Weekend That Wasn’t
After six months of microservice development, three months of cross-department alignment, and countless working sessions, we reached the final migration. The actual data cutover happened over a single weekend.
I’d recruited engineers from across departments to staff the execution. The next morning, teams across the company validated reports, ML models, partner integrations, and feature outputs.
The result: zero high-severity incidents. A new data model adopted consistently across every department. A microservice architecture that would support the next phase of growth. And perhaps most importantly, a new pattern of collaboration that outlasted the project itself.
What I Learned
Technical transformations fail for technical reasons far less often than we assume. They fail because smart people with good intentions end up working against each other. Not out of malice, but out of missing context and unclear ownership.
The leader’s job in these situations isn’t to be the smartest person in the room or to make all the decisions. It’s to create the conditions where the people closest to the work can actually work together. Sometimes that means tearing down the very communication structures you built. Sometimes it means spending months as a “dot connector” rather than a decision maker.
This project taught me that alignment isn’t a state you achieve in a kickoff meeting. It’s a practice you maintain through hundreds of small interventions, difficult conversations, and deliberate acts of bridge-building.
It also taught me something about myself: I’m at my best not when I’m directing from above, but when I’m in the middle of things, helping talented people find their way to shared understanding.
That conference room argument between the engineer and the analyst? By the end of the project, they were grabbing coffee together to troubleshoot edge cases. No meeting invite required.
This transformation became a reference project across the organization, but the real success wasn’t the migration itself. It was proving that even the most complex, high-stakes initiatives can be delivered through trust, transparency, and genuine collaboration.
This article draws on my experience leading engineering teams at German fintech companies, as detailed in my LinkedIn profile.
